Design baseline · 28 SEP 2026 · 06 / 23

TDD · Intake & Process Routing

Technical design cho channel intake, business context và chọn Process Definition / Process Instance / Workflow con.

DESIGN DIAGRAMS · TARGET ARCHITECTURE 2.0

−Vừa khung+Mở toàn màn hình ↗Tải SVGNguồn

Luồng inbound đang triển khai · 30 SEP 2026

Mỗi tenant + account session + channel + thread type + nhóm/thread + sender có phiên gom độc lập. Callback đầu mở phiên; callback tiếp theo cùng khóa nối text/media/source messages và reset quiet timer (mặc định 60 giây, giới hạn 300 giây). Tài xế khác hoặc nhóm khác mở phiên riêng và tiếp tục nhận dữ liệu dù phiên khác đang chạy AI. Provider submission ID tách album nếu có; timer chỉ là fallback, không bảo đảm ranh giới hai album cùng tài xế/nhóm.

Đóng phiên → ghép một event → commit Gateway inbox → forward Core → commit event và core_master_jobs trong cùng transaction ngắn → ACK → worker Master → handler → OPS → review → outbox. Không giữ transaction khi đợi tin nhắn và không gọi Master trong intake HTTP. ACK xác nhận lưu bền vững event/job, không xác nhận đã có routing decision. Retry/lease theo job; các phiên khác không chờ AI của phiên trước. Phiên chưa đóng hiện còn trong RAM: shutdown chủ động flush, crash đột ngột có thể mất phần chưa chốt.

Acceptance hiện hành: xen kẽ hai tài xế trong một nhóm, một tài xế trong hai nhóm; mỗi phiên có đúng text/ảnh của mình; Core ACK vẫn nhanh khi Master đang chậm; duplicate không nhân đôi job/task; lỗi model retry có giới hạn và không tự gửi kết quả. Process/case routing bên dưới là thiết kế mở rộng, không khẳng định đã có generic live executor.

Responsibility boundary

Channel Intake chịu trách nhiệm nhận canonical event, scope validation, dedupe, durable persistence và ACK. Process Orchestrator chịu trách nhiệm resolve Business Case/Process Instance, intent và Workflow con cần start/resume. Intake không gán Role trực tiếp và không biến mỗi message thành Task.

Context đầu vào cho Process Orchestrator

Routing algorithm

1. Gateway gom callback trong phiên sender/thread độc lập trước khi tạo canonical event; giữ text/media/source metadata. Không giữ transaction trong thời gian đợi.
2. Khi chốt phiên, commit event vào Gateway inbox. Core xác minh scope, chống duplicate, commit event + pending routing job rồi ACK trước AI.
3. Resolve open Business Case/Process Instances bằng khóa nghiệp vụ + tenant + provenance. Không tạo instance mới chỉ vì có message mới.
4. Áp dụng deterministic routing cho direction, configured group/session, explicit identifier và supported media. Dùng AI classification chỉ khi cần hiểu intent/ambiguity; trả structured proposal gồm intent, case candidates, process/workflow candidates, confidence và reason.
5. Backend xác thực proposal: process definition đang bật, version hợp lệ, scope đúng, workflow thuộc process và Role owner hợp lệ. AI không được tạo Role/Workflow/Task type tự do.
6. Quyết định là một trong: IGNORE có reason, ATTACH vào task/workflow đang chờ, START/RESUME Workflow trong case, MULTI_ROUTE khi nhiều intent độc lập, hoặc IGNORE khi mơ hồ.
7. Ghi event correlation, decision audit, process/workflow/task changes atomically hoặc qua transactional outbox; chỉ ACK sau durable commit.

Message, Task và Workflow không đồng nhất

• Message Event là bằng chứng hoặc trigger; nó có thể cập nhật Business Case hiện có mà không tạo Task mới.
• Một message có thể kích hoạt nhiều workflow nếu chứa nhiều intent độc lập; mỗi route phải có correlation/idempotency riêng.
• Một Workflow Instance chứa nhiều Task Instances. Task graph có thể fan-out/fan-in; Workflow có một Role owner.
• Process Instance bao gồm nhiều Workflow Instances xuyên suốt nghiệp vụ. Handoff Role diễn ra giữa các Workflow con trong cùng Process Definition.
• Reply vào WAITING_INPUT/REVIEW task chỉ attach khi scope/correlation xác định duy nhất; nếu nhiều ứng viên thì IGNORE để bảo vệ an toàn nghiệp vụ.

Data and idempotency keys

providerEventKey = tenant + session + channel + providerEventId; albumKey = providerAlbumId (fallback gồm tenant/session/thread/sender/time window); caseKey dựa trên business type + canonical business identifier; workflowRunKey = caseId + workflowDefinitionId + business trigger; taskKey = workflowInstanceId + taskDefinitionId + branch/iteration key. Không dedupe chỉ theo container number: một container có thể có nhiều event và nghiệp vụ.

Failure behavior

• Scope invalid → reject/dead-letter, không tạo case/process.
• DB unavailable trước commit → không ACK ACCEPTED; Gateway giữ inbox và retry ổn định event ID.
• Classifier/provider lỗi hoặc JSON sai → routing job retry theo policy, hết lượt thành FAILED có reason; không ghi IGNORE như thể đã có quyết định nghiệp vụ.
• Business correlation mơ hồ → không tạo duplicate Process Instance; ghi nhận IGNORE có lý do để không tạo trùng lặp.
• Workflow đã có active task cùng idempotency key → attach/replay decision, không nhân đôi.
• ACK ACCEPTED chỉ khẳng định event và pending routing job đã commit; decision được ghi bất đồng bộ sau đó; không đồng nghĩa Workflow đã xong.

TDD acceptance

Observability

Trace nối provider event → intake → case correlation → routing decision → process instance → workflow instance → task. Metrics: inbox lag, duplicate rate, case match ambiguity, process/workflow start/resume, ignore rate, route latency. Log IDs/reason codes; không log token, raw image hoặc toàn bộ tin nhắn.