Điều tra bất ổn kết nối Action của GPT — 2026-03-31

Mục tiêu

Tự điều tra vì sao có phiên GPT truy cập Agent Data actions được, có phiên không, dù đã xử lý 2 lần.

Căn cứ đã đọc

• knowledge/dev/reports/gpt-agent-data-stability-diagnosis-2026-03-23.md
• knowledge/current-state/reports/session-stability-close-report-2026-03-23
• knowledge/dev/ssot/connections/connection-dashboard
• knowledge/current-state/agent-connections.md (deprecated, chỉ đọc lịch sử)
• knowledge/current-state/reports/agent-data-connectivity-check-gpt-2026-03-31.md

Kiểm tra trực tiếp lúc điều tra

1) healthCheck()

• overall: degraded
• qdrant: degraded, latency ~753ms, last_error="Connection error."
• postgres: ok
• openai: ok
• data_integrity.sync_status: ok

2) searchKnowledge()

• gọi thành công
• nhưng retrieval quality không ổn định, có lúc trả secondary references / inferred path

Kết luận điều tra

Kết luận 1 — Không phải lỗi "kho Agent Data chết"

Backend không có dấu hiệu sập toàn phần:

• Postgres vẫn OK
• OpenAI vẫn OK
• sync_status vẫn OK
• Tôi vẫn gọi được searchKnowledge, getDocument, createDocument

=> Đây không giống lỗi mất dữ liệu hoặc agent-data backend chết hẳn.

Kết luận 2 — PR #322 chỉ giải quyết được session-start, chưa khóa được runtime instability

Báo cáo close issue ngày 2026-03-23 ghi rất rõ:

• patch chỉ thêm /session-ready
• chỉ gate lúc bắt đầu session
• KHÔNG gate runtime routes (/chat, /mcp, MCP tool-call)

=> Nếu lỗi hiện tại xảy ra theo kiểu:

• mở phiên OK
• nhưng khi gọi action thật thì fail/timeout/502 thì PR #322 không xử lý tận gốc.

Kết luận 3 — Hiện có bằng chứng thực tế cho thấy tầng vector/retrieval đang chập chờn

Ngay lúc điều tra:

• healthCheck() = degraded
• qdrant báo Connection error
• latency qdrant cao bất thường

=> Điều này phù hợp với triệu chứng “lúc được lúc không”, đặc biệt với các action thiên về search/retrieval. Không phải mọi tool đều chết, nhưng lớp retrieval có thể kéo tụt một phần request hoặc làm gateway/session tưởng là action lỗi.

Kết luận 4 — Nguyên nhân gốc khả dĩ nhất là 2 lớp lỗi chồng nhau

Lớp A — session/binding/gateway theo phiên

Đã có bằng chứng lịch sử về:

• session_binding_failed
• tool_route_down
• 502/transient

PR #322 giảm rủi ro ở đầu phiên, nhưng không kiểm soát runtime route.

Lớp B — runtime dependency degradation (đặc biệt là qdrant/search)

Phiên nào đi vào đường search/retrieval đúng lúc qdrant chậm/lỗi thì dễ fail hơn.

=> Nói ngắn: đây không phải 1 lỗi đơn độc. Nó giống mô hình: session-ready có thể PASS nhưng runtime action vẫn fail vì gateway/tool-route hoặc vì dependency qdrant degraded.

Vì sao đã fix 2 lần mà vẫn tái diễn?

Vì các lần fix trước chủ yếu nhắm vào:

1. cấu hình/kết nối endpoint
2. readiness đầu phiên

Nhưng chưa đóng gói thành 1 cơ chế đầy đủ cho runtime:

• chưa gate /chat / /mcp / tool-call runtime
• chưa phân loại lỗi runtime theo dependency (qdrant vs postgres vs tool route)
• chưa có circuit-breaker/retry riêng cho truy vấn search khi qdrant chập chờn
• chưa có incident log chuẩn cho từng lần action fail ở phía GPT session

Chẩn đoán cuối cùng

Nguyên nhân khả dĩ nhất hiện tại:

1. Fix cũ chỉ chặn lỗi đầu phiên, không chặn lỗi lúc gọi action thật
2. Qdrant/retrieval đang degraded thật ở thời điểm hiện tại
3. GPT Action qua OpenAPI/HTTP phụ thuộc session binding + tool route + backend dependency, nên chỉ cần 1 tầng chập chờn là người dùng cảm nhận thành “phiên này được, phiên kia không”

Khuyến nghị sửa đúng gốc

Mức bắt buộc

1. Mở rộng readiness gate từ session-start sang runtime route health

   • không chỉ /session-ready
   • phải có sentinel cho đường action thật (/chat hoặc route tool-call thật)

2. Tách health thành 2 lớp rõ ràng

   • service health: postgres/openai/qdrant
   • action health: searchKnowledge/getDocument/createDocument thực sự gọi được hay không

3. Khi qdrant degraded, search route phải trả trạng thái phân loại rõ

   • ví dụ: dependency_degraded:qdrant
   • không nên để client chỉ thấy generic fail / no route / 502

4. Retry/backoff cho runtime action, không chỉ đầu phiên

   • hiện fix cũ mới nói backoff cho session-start
   • cần áp cho action runtime thất bại do transient gateway/dependency

Mức nên làm ngay

5. Ghi incident chuẩn cho mọi lần GPT action fail

   • timestamp
   • session id nếu có
   • route
   • loại lỗi: backend_down / tool_route_down / session_binding_failed / dependency_degraded:qdrant

6. Thêm monitor riêng cho qdrant-backed search

   • không chỉ healthCheck chung
   • phải có sentinel search query + latency threshold + alert

7. Định nghĩa degraded mode

   • qdrant lỗi nhưng postgres/doc read còn sống → vẫn cho getDocument/listDocuments hoạt động, chỉ gắn cờ search degraded
   • như vậy người dùng không cảm thấy “toàn bộ action chết”

Phán quyết

Tôi không thấy bằng chứng rằng vấn đề nằm ở dữ liệu Agent Data. Tôi thấy bằng chứng khá mạnh rằng vấn đề nằm ở: runtime action path chưa được gate đầy đủ + qdrant/retrieval đang degraded thật.

=> Nếu muốn hết hẳn kiểu “phiên được, phiên không”, cần sửa từ “session readiness” thành end-to-end action readiness + dependency-aware runtime handling.