Contact
Line : comsiam
Contact
Line : comsiam

Gemini API Error 400, 403 และ 404 เป็น Error ที่พบได้บ่อยเมื่อเริ่มเชื่อม Gemini API เข้ากับ Python, JavaScript, PHP หรือ Backend Application แต่ทั้งสาม Code มีความหมายต่างกันอย่างชัดเจน
จำง่าย ๆ คือ
400
=
Request ที่ส่งไปมีปัญหา
403
=
มี Credential แต่ไม่มีสิทธิ์ทำสิ่งนั้น
404
=
Resource หรือ Model ที่เรียกหาไม่มีอยู่
สำหรับ Interactions API ปัจจุบัน Google แยก Error เหล่านี้ออกเป็น Machine-readable Code เช่น
invalid_request
failed_precondition
parameter_unknown
permission_denied
not_found
model_not_found
ดังนั้นอย่าดูเพียงเลข HTTP Status ควรอ่านทั้ง
HTTP status
+
error.code
+
error.message
พร้อมกัน เพราะ Error 400 เช่นเดียวกันอาจเกิดจากคนละสาเหตุและต้องแก้คนละวิธี
HTTP Status
400 Bad Request
หมายความว่า Server รับ Request ได้ แต่ Request นั้นไม่สามารถประมวลผลตามรูปแบบหรือเงื่อนไขที่ API ต้องการ
ใน Interactions API ปัจจุบัน Error 400 ที่สำคัญมีอย่างน้อย
invalid_request
failed_precondition
parameter_unknown
ดังนั้น Error 400 ไม่ได้หมายความเพียงว่า JSON Syntax ผิดเท่านั้น
invalid_request คืออะไรGoogle ระบุว่า invalid_request หมายถึง
Request payload malformed
หรือ
มี parameter ไม่ถูกต้อง
ตัวอย่างเช่น
ตัวอย่าง Error ลักษณะหนึ่ง
{
"error": {
"code": "invalid_request",
"message": "..."
}
}
วิธีแก้คือเทียบ Request กับ API Reference ปัจจุบัน
parameter_unknown คืออะไรError นี้เกิดเมื่อ Request มี Parameter ที่ API ไม่รู้จัก
ตัวอย่าง Tutorial เก่าใช้
old_parameter
แต่ API รุ่นใหม่เปลี่ยนเป็น
new_parameter
Request จึงอาจได้
400
parameter_unknown
วิธีแก้คือ ลบ Parameter ที่ไม่รองรับหรือเปลี่ยนเป็นชื่อปัจจุบัน
นี่เป็นปัญหาที่พบได้บ่อยมากกับ Gemini API เพราะ API และ SDK มีการพัฒนาอย่างต่อเนื่อง
สมมติ Copy Code จาก Tutorial เก่า
client.interactions.create(
model="...",
input="...",
old_config="..."
)
แต่ Interactions API ปัจจุบันไม่มี
old_config
ผลคือ Request อาจถูกปฏิเสธก่อน Model เริ่มทำงาน
ดังนั้นเมื่อเจอ 400 หลัง Copy Code ควรตรวจ
SDK version
API interface
parameter names
model ID
ก่อนอย่างอื่น
failed_precondition คืออะไรGoogle ระบุว่า Error นี้เกิดเมื่อ Request ไม่สามารถทำต่อได้เพราะ เงื่อนไขที่จำเป็นยังไม่พร้อม
ตัวอย่างที่ Google ยกคือ
Billing disabled
สถานการณ์อื่นอาจเกี่ยวข้องกับ Project หรือ Account Prerequisite ที่ Request นั้นต้องใช้
วิธีแก้คืออ่าน message ให้ละเอียด แล้วตรวจ Prerequisite ที่ระบบระบุ
ได้
นี่เป็นจุดที่ Developer มักสับสน
หลายคนคิดว่า Billing Problem ต้องเป็น 403 เสมอ แต่ Interactions API ปัจจุบันสามารถคืน
400
failed_precondition
หาก Prerequisite เช่น Billing ยังไม่พร้อมสำหรับ Request นั้น
ดังนั้นถ้า Error Message พูดถึง
billing
paid tier
credit
project requirement
ให้ตรวจ AI Studio และ Billing ก่อนแก้ JSON
Interactions API รองรับ
previous_interaction_id
สำหรับ Conversation ต่อเนื่อง
แต่ Google ระบุว่า หาก Interaction ก่อนหน้ายังอยู่
in_progress
แล้วพยายาม Chain Interaction ใหม่ทันที
สามารถได้
400 Bad Request
วิธีแก้คือรอ Interaction ก่อนหน้าเป็น
completed
ก่อนเริ่ม Turn ต่อไป
ไม่ควร
Interaction A
status = in_progress
↓
สร้าง Interaction B
โดยอ้าง previous_interaction_id=A
ควรเป็น
Interaction A
↓
completed
↓
Interaction B
โดยเฉพาะ Background Execution หรือ Managed Agent Workflow
Structured Output สามารถเกิด 400 เมื่อ
generateContent กับ Interactions APIตัวอย่าง Interactions API ใช้
response_format
แต่ Tutorial ของ GenerateContent อาจใช้
response_mime_type
response_schema
ถ้านำ Format ผิด API มาปนกัน Request อาจล้มเหลว
ตรวจ
tools
function name
description
parameters
tool_choice
หาก Tool Type ไม่รองรับหรือ Function Declaration ผิด Structure สามารถได้ invalid_request
ควรลด Request ให้เหลือ Tool เดียวก่อน
1 prompt
+
1 function
+
simple parameters
เมื่อผ่านแล้วค่อยเพิ่ม Complexity
สำหรับ Model ปัจจุบันใช้
{
"type": "google_search"
}
Tutorial รุ่นเก่าอาจใช้ Tool Name อื่น
หากส่ง Tool Type ที่ API ปัจจุบันไม่รองรับ สามารถเกิด 400
ดังนั้น Tool Integration เป็นจุดแรก ๆ ที่ควรตรวจเมื่อ Text Request ปกติทำงาน แต่ Request ที่เปิด Tool ล้มเหลว
หาก Request มี File ให้ตรวจ
ตัวอย่าง Video ที่ยังอยู่
PROCESSING
อาจยังไม่พร้อมใช้งาน
หรือ Inline PDF ใหญ่เกิน Limit ก็สามารถสร้าง Request Error ได้
ลด Request ให้เล็กที่สุด
จาก
Long Prompt
+
Files
+
Search
+
Functions
+
Structured Output
+
Streaming
ให้เหลือ
1 Model
+
1 Prompt
ถ้าผ่าน
เพิ่มทีละอย่าง
File
↓
Structured Output
↓
Search
↓
Function
เมื่อ Error กลับมา จะรู้ว่าปัญหาอยู่ Feature ไหน
from google import genai
client = genai.Client()
interaction = client.interactions.create(
model="gemini-3.7-flash",
input="ตอบคำว่า OK",
)
print(interaction.output_text)
หาก Code นี้ผ่าน แต่ Application จริง 400
ปัญหามักอยู่ใน
Request Configuration
มากกว่า API Key หรือ Project
import { GoogleGenAI } from "@google/genai";
const ai = new GoogleGenAI({});
const interaction =
await ai.interactions.create({
model: "gemini-3.7-flash",
input: "ตอบคำว่า OK",
});
console.log(interaction.output_text);
ใช้เป็น Baseline ก่อนเพิ่ม Tools หรือ Schema
เก็บ
timestamp
model
error.code
error.message
request feature flags
เช่น
search_enabled = true
structured_output = false
file_input = true
ไม่ควร Log
API Key
เด็ดขาด
HTTP Status
403 Forbidden
ใน Interactions API ปัจจุบันใช้ Error Code
permission_denied
Google อธิบายว่า
API key ไม่มี Permission
สำหรับ Resource นั้น
แต่ในทางปฏิบัติต้องตรวจหลายระดับ ได้แก่
มักหมายถึง
Credential ไม่มี
Credential ไม่ถูก
Credential หมดอายุ
หมายถึง
ระบบรู้ว่า Credential/Project คือใคร
แต่ไม่มีสิทธิ์ทำ Action นี้
จำง่าย
401
=
คุณคือใคร?
403
=
รู้ว่าคุณคือใคร แต่ทำไม่ได้
ถ้า Error เป็น
permission_denied
ให้ตรวจว่า Key อยู่ Project ถูกหรือไม่
โดยเฉพาะผู้ที่มี
Dev Project
Staging Project
Production Project
พร้อมกัน
อาจเกิดกรณี
Application ใช้ Key ของ Project A
แต่ Resource อยู่ Project B
Google ปัจจุบันมีระบบ Restrict Key สำหรับ Gemini API
ถ้าใช้ Standard Key เก่า ต้องตรวจว่า Restriction ถูกต้อง
Key ที่
Unrestricted
อาจถูก Block ตามมาตรการใหม่ของ Google
และ Google เริ่ม Block Standard Unrestricted Key ที่ไม่ได้ใช้งานเป็นเวลานานตั้งแต่เดือนพฤษภาคม 2026
ดังนั้นอย่าใช้ Credential รุ่นเก่าแบบไม่มี Restriction ต่อโดยไม่ตรวจ AI Studio
Google AI Studio ระบุว่า
403 Access Restricted
สามารถเกิดได้หากใช้งานจาก Region ที่ไม่รองรับ
ดังนั้นถ้า
แต่ทั้ง AI Studio และ API มี Access Problem
ให้ตรวจ Supported Region ด้วย
โดยเฉพาะ Server ที่ Deploy อยู่คนละประเทศกับ Developer
Google ระบุว่า Access Check อาจต้องผ่าน
หาก Account ยังไม่ได้ยอมรับข้อกำหนดที่จำเป็น การเข้าถึง Feature บางอย่างอาจถูกปฏิเสธ
จึงควรเข้า AI Studio ด้วย Account เดียวกับ Project แล้วตรวจ Banner หรือ Prompt ที่ระบบแสดง
Google AI Studio ยังทำ Automated Security Checks
ดังนั้น 403 สามารถเกี่ยวข้องกับ
security checks
ไม่จำเป็นต้องเป็น IAM อย่างเดียว
Project ที่ถูก Flag ด้าน Abuse หรือ Trust & Safety สามารถถูกจำกัด Access ได้
ให้ตรวจ
AI Studio Projects
Billing
Account email
Error banner
Appeal / support instructions
ถ้าข้อความระบุชัด เช่น
Your project has been denied access
การสร้าง API Key ใหม่ใน Project เดิมอาจไม่แก้
เพราะ Root Cause อยู่ที่ Project หรือ Account Status
หากเป็น Permission Problem
Key A
→ 403
สร้าง Key B
→ 403
สร้าง Key C
→ 403
ไม่ได้พิสูจน์ว่า SDK เสีย
ต้องตรวจ
Project
IAM
Account
Region
Terms
Policy
แทน
ไม่เสมอ
บาง Access Issue อาจเกี่ยวกับ Account Standing หรือ Project Status ซึ่ง Billing เพียงอย่างเดียวไม่ได้รับประกันว่าจะปลดล็อก
ให้ทำตามข้อความ Error และคำแนะนำใน AI Studio เป็นหลัก
อย่าเปิด Billing เพียงเพราะต้องการสุ่มแก้ Error
AI Studio มี Permission แยกสำหรับงานต่าง ๆ เช่น
ถ้าใช้ Organization/Workspace Project และ Role ของ User จำกัด
บางหน้าอาจดูไม่ได้หรือ Action บางอย่างทำไม่ได้
Admin ต้องให้ Permission ที่เหมาะสมตาม Least Privilege
error.messageอย่าดูเพียง 403
Key มาจาก Project ไหน
มี Banner หรือไม่
ถ้า Minimal Request ก็ยัง 403 ปัญหามักไม่ใช่ Prompt
HTTP Status
404 Not Found
Interactions API ปัจจุบันมี Error Code สำคัญ
not_found
model_not_found
ดังนั้น Error 404 อาจหมายถึง
Resource ไม่พบ
หรือ
Model ไม่พบ
ต้องอ่าน error.code
not_found คืออะไรหมายถึง Resource ที่ Request ขอไม่มีอยู่
เช่น
Google แนะนำให้ตรวจ Resource Path และ Parameters
model_not_found คืออะไรหมายถึง Model ID ที่ระบุไม่มีอยู่หรือไม่สามารถเรียกได้ผ่าน API/Endpoint นั้น
ตัวอย่าง
model="gemini-something-made-up"
จะไม่ทำงาน
หรือ Tutorial เก่าใช้ Model ที่ถูก Shutdown แล้ว
ก็สามารถเกิด 404 ได้
Gemini มี Model Lifecycle
Preview
Stable
Deprecated
Shutdown
ดังนั้น Code ที่ทำงานเมื่อหลายเดือนก่อนอาจเกิด 404 หลัง Model ถูกปิด
อย่า Hard-code Model แล้วลืมตรวจ Model Lifecycle
ตัวอย่าง
gemini-3.7-flash
หาก Stable Model ปัจจุบันทำงาน แต่ Model เก่า 404
Root Cause ชัดว่าอยู่ที่
Model ID / Lifecycle
ไม่ใช่ API Key
แทน
model="gemini-old-model"
กระจายทั่ว Codebase
ใช้
GEMINI_MODEL=gemini-3.7-flash
แล้วอ่านจาก Configuration
ช่วย Migration ง่ายขึ้น
previous_interaction_idStateful Conversation อ้าง
previous_interaction_id
ผิดหรือ Resource ไม่สามารถหาได้
ก็อาจได้รับ
not_found
ตัวอย่าง
previous_interaction_id =
interactions/WRONG_ID
วิธีแก้คือเก็บ Interaction ID จาก Response จริง
ไม่สร้างเอง
Files API เก็บไฟล์ชั่วคราวตาม Lifecycle ของบริการ
ถ้า Application เก็บ File URI เก่าไว้นาน แล้ว Resource หมดอายุหรือถูกลบ
Request ต่อมาอาจหา File ไม่พบ
วิธีแก้
Upload ใหม่
↓
รับ Resource ใหม่
↓
Update Database
ไม่ควรใช้ Temporary File URI เป็น Permanent ID
ถ้า Admin หรือ Cleanup Job ลบ
File
Cache
Resource
แต่ Database ของ Application ยังเก็บ ID เดิม
จะเกิด Dangling Reference
เช่น
Database:
file_id = files/abc
แต่ Gemini:
files/abc ไม่มีแล้ว
ควรมี Resource Lifecycle Management
บาง Resource หรือ Model อาจรองรับใน API Version หนึ่ง แต่ไม่รองรับอีก Version
เช่น
v1
vs
v1beta
SDK ปัจจุบันมี Default Version ตาม Interface
อย่าเปลี่ยน API Version โดยไม่ตรวจ Feature Compatibility
เมื่อใช้ Google Search แล้ว Source URL 404 เป็นคนละเรื่องกับ
Gemini API HTTP 404
API 404 หมายถึง Resource ที่ Gemini API Endpoint กำลังเรียกไม่มี
ไม่ใช่ Search Result Website 404
ต้องแยก Layer ให้ถูก
แนวคิดคืออย่าจับ
except Exception:
แล้วตอบเหมือนกันทุกกรณี
ควรอ่าน Error Code/Status และแยก Logic
ตัวอย่างแนวคิด
try:
interaction = client.interactions.create(
model="gemini-3.7-flash",
input="สวัสดี",
)
except Exception as error:
print(error)
จากนั้นใน Production ใช้ Exception Type ของ SDK รุ่นปัจจุบันและอ่าน Code/Status จาก Error Object
เป้าหมายคือแยก
400
403
404
429
ออกจากกัน
ไม่ควร
try {
await ai.interactions.create(...);
} catch {
return "Gemini ใช้งานไม่ได้";
}
เพราะ User/Developer จะไม่รู้ Root Cause
ควร Log
HTTP status
error code
message
และแสดงข้อความที่เหมาะสมตามประเภท Error
สำหรับ Standard HTTP Request จะมีโครงสร้างแนวนี้
{
"error": {
"code": "invalid_request",
"message": "..."
}
}
ดังนั้น Application ไม่ควร Parse เพียง
HTTP 400
แต่ควรใช้
error.code
ในการเขียน Logic
เมื่อใช้
stream: true
Error สามารถถูกส่งผ่าน SSE Stream
Event จะมี
event_type = error
พร้อม
error.code
error.message
ดังนั้น Streaming Client ต้องมี Error Event Handler
ไม่ใช่ดูเพียง HTTP Response ตอนเปิด Connection
Structure อาจเป็น
{
"event_type": "error",
"error": {
"code": "not_found",
"message": "..."
}
}
ดังนั้น Event Router ควรมี
interaction.created
step.delta
interaction.completed
error
ครบ
นี่เป็นความผิดพลาดที่สำคัญ
มักเหมาะกับ
wait
+
exponential backoff
ต้องแก้ Request
ต้องแก้ Permission/Account
ต้องแก้ Resource/Model
ถ้าเขียน Retry Policy แบบ
ทุก Error
→ Retry 10 ครั้ง
จะเสียทั้งเวลาและ API Traffic
| Error | Retry ทันทีไหม | วิธีหลัก |
|---|---|---|
| 400 | ไม่ | แก้ Request |
| 403 | ไม่ | แก้ Permission/Access |
| 404 | ไม่ | แก้ Resource/Model |
| 429 | รอแล้ว Retry | Backoff |
| 5xx | อาจ Retry | Backoff ตามกรณี |
ต้องดู Error Code ย่อยและ Use Case ประกอบเสมอ
ตรวจ
Key
Project
Permission
Region
Terms
ตรวจ
Tool Schema
Parameter
Model Support
ตรวจ
Model ID
Deprecation
Availability
ตรวจ
Model Lifecycle
Resource Expiration
ตรวจ
Project/Account Access
มากกว่า Prompt
เมื่อ Error ซับซ้อน ให้สร้างไฟล์ใหม่
test_gemini.py
มีเพียง
from google import genai
client = genai.Client()
response = client.interactions.create(
model="gemini-3.7-flash",
input="ตอบ OK",
)
print(response.output_text)
ถ้า Minimal Code ผ่าน
แสดงว่า
API
Key
Project
Model
พื้นฐานทำงาน
ค่อยกลับไปตรวจ Application Layer
ลำดับที่ดี
Text
↓
Structured Output
↓
File
↓
Search
↓
Function Calling
↓
Streaming
ไม่ควรเปิดทุกอย่างพร้อมกันใน Test แรก
ช่วยรู้ว่า Feature ใดเป็น Trigger ของ Error
Python
pip show google-genai
JavaScript
npm list @google/genai
ถ้าใช้ SDK เก่ามาก อาจมี Method หรือ Schema ไม่ตรงกับ Documentation ปัจจุบัน
ก่อน Debug หลายชั่วโมงควร Update Dependency ก่อน
Python รุ่นเก่า
google-generativeai
เป็น Legacy/Deprecated Direction
สำหรับ Code ปัจจุบันควรใช้
google-genai
และ JavaScript
@google/genai
ตาม SDK รุ่นปัจจุบัน
ช่วยลดปัญหาจาก Tutorial เก่า
หากใช้
GEMINI_API_KEY
ให้ตรวจว่า Runtime ที่ Deploy เห็นค่าจริง
ปัญหาที่พบได้คือ
Local
→ Key A
Production
→ Key B เก่า
หรือ
CI/CD
→ ไม่มี Key
แต่ถ้า Credential ไม่มี/ผิดโดยตรงมักเป็น 401 มากกว่า 403
จึงต้องอ่าน Status ให้ถูก
ใช้
Dev Project
Staging Project
Production Project
ช่วย Debug ง่ายขึ้น
ถ้า Production 403 แต่ Dev ผ่าน
จะรู้ว่าปัญหาเกี่ยวกับ Project/Permission มากกว่า Code
ระบบของ comsiam หากนำ Gemini API ไปใช้จริงควรแยก Credential และ Project ระหว่าง Development กับ Production เพื่อไม่ให้การทดสอบ Permission หรือ Billing กระทบระบบที่ผู้ใช้กำลังใช้งาน
Production ควรนับ
400_count
401_count
403_count
404_count
429_count
5xx_count
พร้อม
model
endpoint
feature
ตัวอย่าง Dashboard
404 เพิ่มขึ้นทันทีหลัง Deploy
อาจบอกว่า Model ID หรือ Resource Path ใหม่ผิด
400 บางส่วนอาจเกิดจาก User Input
แต่ถ้า
403 rate
จาก 0%
→ 100%
หลัง Deploy
ควร Alert ทันที
อาจเกิดจาก
เช่นเดียวกับ 404 ที่พุ่งเมื่อ Model ถูกเปลี่ยน
| HTTP | Code ที่พบบ่อย | ความหมาย | สิ่งแรกที่ตรวจ |
|---|---|---|---|
| 400 | invalid_request | Request ผิด | Payload |
| 400 | parameter_unknown | Parameter ไม่รู้จัก | API Reference |
| 400 | failed_precondition | เงื่อนไขไม่พร้อม | Billing/Prerequisite |
| 403 | permission_denied | ไม่มีสิทธิ์ | Key/Project/IAM |
| 404 | not_found | Resource ไม่พบ | Resource ID |
| 404 | model_not_found | Model ไม่พบ | Model ID/Lifecycle |
ตารางนี้ใช้เป็น Shortcut ก่อนลงรายละเอียดได้ดีมาก
Request เดิมยังผิด
Permission ไม่เกี่ยวกับ Prompt ส่วนใหญ่
ถ้า Model ไม่มี Key ใหม่ก็ไม่ช่วย
ควรตรวจ Model ปัจจุบัน
Interactions กับ GenerateContent ต่างกัน
หา Root Cause ยาก
Exception แล้วซ่อน ErrorDebug ไม่ได้
สร้าง Security Incident
เพิ่ม Exposure
อาจเป็น Region, IAM หรือ Policy
ส่วนใหญ่เกี่ยวกับ Resource/Model
ภายหลังหา Resource ไม่พบ
in_progressอาจได้ 400
error.codeเสียข้อมูลสำคัญ
ควรใช้เฉพาะ Error ที่เหมาะ
error.codeerror.messagefailed_preconditionหาก Minimal Request ใช้ได้ จะหา Root Cause ง่ายมาก
permission_deniedอย่าสร้าง Project หรือ Key จำนวนมากเพื่อพยายามหลบ Access Restriction
error.codeเป็น not_found หรือ model_not_found
เมื่อพบ Resource ใหม่ที่ถูกต้อง
Checklist นี้ช่วยลด Error ที่เกิดจาก Configuration หลัง Deploy
ได้รับ
400
invalid_request
และ Message บอกว่า Tool Type ไม่รองรับ
วิธีแก้คือ
ตรวจ tools[0]
↓
แก้ type
↓
Retry
ไม่เกี่ยวกับ API Key
ได้รับ
403
permission_denied
ทุก Model
Minimal Text Request ก็ไม่ผ่าน
ให้ตรวจ
Project
Account
Region
IAM
AI Studio Banner
ก่อน Code
เพราะถ้า Request ทุกแบบถูกปฏิเสธ ปัญหาอาจอยู่ระดับ Access
ได้รับ
404
model_not_found
Model เก่า
แต่
gemini-3.7-flash
ผ่าน
สรุปได้ว่า Application ต้อง Migration Model
ไม่จำเป็นต้อง Rotate API Key
เมื่อวาน Upload File และเก็บ URI
หลายวันต่อมานำ URI เดิมกลับมาใช้แล้ว 404
ให้ตรวจ File Lifecycle
หาก Resource หมดอายุ
Upload ใหม่
↓
รับ Resource ใหม่
แทน Retry URI เดิม
Backend อาจ Log
permission_denied
project ...
resource ...
แต่ Frontend สามารถแสดงข้อความที่ปลอดภัย เช่น
ระบบไม่สามารถเข้าถึงบริการ AI ได้ในขณะนี้
ไม่จำเป็นต้องเปิด
ให้ User ทั่วไปเห็น
ละเอียด
HTTP 404
code=model_not_found
model=...
request_id=...
สั้น
โมเดล AI ที่ระบบใช้ไม่พร้อมใช้งาน กรุณาลองใหม่ภายหลัง
ช่วยทั้ง Security และ User Experience
สมมติ Deploy Version ใหม่
ก่อน Deploy
400 rate = 0.1%
หลัง Deploy
400 rate = 30%
มีโอกาสสูงว่า
Request Schema
ใน Version ใหม่ผิด
ถ้า
404 rate = 100%
หลังเปลี่ยน Model
ให้ตรวจ Model ID ก่อน
ถ้า Application ใช้ Model ที่มี Lifecycle เปลี่ยนได้ สามารถมี Configuration
PRIMARY_MODEL
FALLBACK_MODEL
แต่ไม่ควร Fallback ทุก 404 แบบไม่ตรวจ
ถ้า Resource 404 เกิดจาก File ไม่พบ การเปลี่ยน Model ก็ไม่ช่วย
ต้องดู
model_not_found
vs
not_found
ก่อน
อย่าเขียน Logic โดย Search Keyword ใน Message อย่างเดียว
ไม่ควร
if "model" in error_message:
ควรใช้
error.code == "model_not_found"
เมื่อ SDK/Response เปิดให้เข้าถึง
เพราะ Message สำหรับมนุษย์สามารถเปลี่ยนข้อความได้
Machine-readable Code ถูกออกแบบมาเพื่อ Application Logic โดยตรง
หมายถึง Request ไม่สามารถประมวลผลได้ โดย Interactions API ปัจจุบันมีสาเหตุสำคัญ เช่น invalid_request, parameter_unknown และ failed_precondition ต้องอ่าน Error Code และ Message เพื่อรู้ว่าต้องแก้ Payload, Parameter หรือ Prerequisite
โดยทั่วไปคือ permission_denied หมายถึง Credential หรือ Project ไม่มีสิทธิ์เข้าถึง Resource หรือ Feature นั้น และยังอาจเกี่ยวข้องกับ IAM, Region, Terms, Security Checks หรือ Project Status
อาจเป็น not_found เมื่อ Resource ไม่มีอยู่ หรือ model_not_found เมื่อ Model ID ไม่ถูกต้อง ถูกถอดออก หรือไม่พร้อมผ่าน API ที่กำลังใช้
โดยทั่วไปไม่ช่วยหาก Root Cause คือ Model หรือ Resource ไม่มีอยู่ ควรตรวจ Model ID, Resource Path และ Lifecycle ก่อน
โดยทั่วไปไม่ควร Retry Payload เดิมทันที เพราะ Request ยังผิด ต้องแก้ Request หรือ Prerequisite ก่อน แล้วจึงส่งใหม่
Interactions API แบบ Streaming ส่ง Error ผ่าน SSE Event ที่มี event_type: "error" และภายในมี error.code กับ error.message ดังนั้น Streaming Client ต้อง Handle Error Event โดยตรง
Gemini API Error 400, 403 และ 404 มีสาเหตุแตกต่างกันและไม่ควรใช้วิธีแก้แบบเดียวกัน
Error 400 Bad Request หมายถึง Request หรือ Prerequisite มีปัญหา โดย Interactions API รุ่นปัจจุบันมี Code เช่น invalid_request, parameter_unknown และ failed_precondition วิธีแก้หลักคืออ่าน Message ตรวจ Payload, Parameter, Tool, Schema, File และ Billing/Prerequisite ที่เกี่ยวข้อง
Error 403 Forbidden ใช้ Code permission_denied หมายถึง Project หรือ Credential ไม่มีสิทธิ์เข้าถึง Resource นั้น ต้องตรวจ API Key, Project, Restriction, IAM, Supported Region, Terms of Service, Security Checks และ Project/Account Status ใน AI Studio
Error 404 Not Found แยกเป็น not_found สำหรับ Resource ที่ไม่พบ และ model_not_found สำหรับ Model ที่ไม่มีหรือไม่พร้อมใช้งาน ควรตรวจ Model ID, Model Lifecycle, Interaction ID, File URI, Resource Expiration และ API Version
สิ่งสำคัญคืออย่าดูเพียง HTTP Status ต้องใช้ทั้ง error.code และ error.message ในการ Debug และเขียน Application Logic เพราะ 400 เดียวกันอาจมี Root Cause ต่างกันอย่างสิ้นเชิง
และอย่า Retry 400, 403 หรือ 404 แบบเดียวกับ Error 429 เพราะ 429 เหมาะกับการรอและ Exponential Backoff ขณะที่ 400 ต้องแก้ Request, 403 ต้องแก้ Access และ 404 ต้องแก้ Resource หรือ Model
สำหรับ comsiam แนวทางที่เหมาะคือมี Minimal Gemini Request สำหรับ Health Check แยกจาก Feature จริง พร้อม Error Dashboard ที่แยก invalid_request, permission_denied, not_found, model_not_found และ 429 ออกจากกัน
เมื่อมีระบบ Monitoring แบบนี้ comsiam จะสามารถรู้ได้รวดเร็วว่า Error หลัง Deploy มาจาก Code, Credential, Project หรือ Model Lifecycle โดยไม่ต้องสุ่มเปลี่ยน API Key หรือ Retry Request เดิมซ้ำจนเพิ่มปัญหา