Phân tích nguyên nhân kết nối Agent Data chập chờn — 2026-04-03

• Thời điểm: 2026-04-03
• Agent: Incomex Hội đồng AI
• Mục tiêu: điều tra kỹ vì sao GPT Action đôi lúc kết nối Agent Data chập chờn / không ổn định.

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/current-state/reports/gpt-action-connection-instability-investigation-2026-03-31.md
• knowledge/current-state/reports/agent-data-connectivity-check-gpt-2026-03-31.md
• knowledge/current-state/reports/qdrant-investigation-2026-03-31
• knowledge/current-state/reports/qdrant-timeout-fix-2026-03-31
• knowledge/dev/ssot/connections/connection-dashboard

Kiểm tra trực tiếp hiện tại

1) healthCheck() ngày 2026-04-03

• overall: healthy
• qdrant: ok, latency 8.5 ms
• postgres: ok, latency 0.5 ms
• openai: ok
• sync_status: ok
• document_count: 838
• vector_point_count: 1253

Kết luận điều tra

1. Không phải lỗi "mất Agent Data" hay backend chết hẳn

Bằng chứng xuyên suốt các báo cáo:

• Postgres và OpenAI vẫn ok
• sync_status vẫn ok
• nhiều phiên vẫn đọc/ghi được (searchKnowledge, getDocument, createDocument, deleteDocument)

=> Gốc vấn đề không phải kho dữ liệu hỏng.

2. Có 3 nguyên nhân chính đã từng chồng lên nhau

A. Session readiness chỉ che được lỗi đầu phiên, chưa che được runtime action path

PR #322 thêm /session-ready và gate ở đầu phiên. Nhưng chính báo cáo close issue xác nhận patch này:

• chỉ gate session-start
• không gate runtime routes như /chat, /mcp, MCP tool-call

=> Vì vậy vẫn có khả năng:

• đầu phiên PASS
• nhưng đến lúc gọi action thật thì fail / timeout / tool route lỗi

Đây là lý do vì sao user cảm nhận kiểu "phiên này được, phiên kia không" dù patch đầu phiên đã có.

B. Qdrant/search từng degraded hoặc chậm, làm action timeout gần ngưỡng GPT

Báo cáo ngày 2026-03-31 cho thấy:

• có lúc health báo qdrant degraded
• latency qdrant từng lên khoảng 753.4 ms
• /chat qua HTTPS vẫn chạy được nhưng tổng latency có lúc 8–27s
• timeout GPT Actions khoảng 30s

=> Khi search path chậm gần ngưỡng timeout, người dùng sẽ thấy kết nối rất chập chờn: có request qua được, có request gãy.

C. Health check cũ từng bị "stale cache", làm chẩn đoán sai hoặc báo degraded giả

Báo cáo qdrant-investigation-2026-03-31 nêu rất rõ:

• health degraded lúc đó là cached từ startup probe, không phản ánh realtime
• test trực tiếp trong container và docker network lại OK

=> Một phần cảm giác bất ổn trước đây đến từ monitor báo không đúng thời điểm thực tế, khiến khó phân biệt:

• backend hỏng thật
• hay chỉ health cache cũ

3. Nguyên nhân gốc khả dĩ nhất theo vận hành

Nguyên nhân thật không phải 1 lỗi đơn lẻ, mà là mô hình lỗi nhiều tầng:

session-start gate chưa bao phủ runtime + search/qdrant từng chậm hoặc degraded + health cache cũ làm tín hiệu sai

Nói ngắn gọn:

• backend dữ liệu vẫn sống
• nhưng đường action runtime và search path từng không ổn định đủ để tạo cảm giác chập chờn

4. Vì sao sau sửa vẫn có lúc bị nghi là chập chờn?

Vì các đợt sửa ban đầu tập trung vào session-start readiness, chưa xử lý hết runtime path. Sau đó mới có đợt fix tiếp theo cho Qdrant:

• timeout giảm từ 15s xuống 1s
• health re-probe từ startup-only sang refresh theo TTL 30s
• deploy warm-up tốt hơn

Báo cáo fix ngày 2026-03-31 cho thấy sau sửa:

• qdrant health từ degraded → healthy
• qdrant latency từ 753.4 ms → khoảng 9.2 ms
• search latency từ 6,000–16,000 ms → khoảng 397–478 ms
• worst-case retry từ 45s → 3s

=> Nghĩa là một phần lớn nguyên nhân chập chờn đã được xử lý rồi.

5. Đánh giá hiện tại ngày 2026-04-03

Dựa trên healthCheck() hiện tại:

• qdrant đang tốt (8.5 ms)
• postgres tốt (0.5 ms)
• sync_status tốt
• không thấy dấu hiệu degraded tại thời điểm kiểm tra

=> Hiện tại hệ thống đang ổn định.

Nhưng nếu hỏi vì sao trước đây chập chờn, thì câu trả lời trung thực nhất là:

1. readiness chỉ chặn lỗi đầu phiên
2. runtime action path/search path từng gần timeout hoặc degraded
3. health cũ từng bị stale cache nên tín hiệu quan sát bị nhiễu

Phán quyết cuối

Nguyên nhân gốc khả dĩ nhất của hiện tượng chập chờn không phải là mất dữ liệu hay backend chết, mà là lỗi đa tầng ở runtime action path và search dependency, đặc biệt là Qdrant/search latency và readiness chưa bao phủ runtime.

Ưu tiên khuyến nghị

1. Giữ probe đầu phiên và probe runtime route thật
2. Tách bạch service health và action health
3. Log rõ loại lỗi: session_binding_failed, tool_route_down, dependency_degraded:qdrant
4. Khi search degraded, vẫn cho getDocument/listDocuments sống để user không cảm giác toàn hệ chết
5. Theo dõi vài ngày với chuỗi probe nhiều phiên, thay vì dựa vào 1 phiên PASS

Kết luận ngắn

• Trước đây chập chờn là có thật
• Nguyên nhân chính là runtime/search path, không phải mất dữ liệu
• Sau các fix cuối tháng 3, tình hình có vẻ đã tốt lên rõ rệt
• Hiện tại tại thời điểm kiểm tra: ổn định