event/v1: ไม่มี sequence ต่อ subject → trail ที่ถูกตัดท้ายอ่านได้เหมือนสมบูรณ์

[monthop-gmail]

พบตอนทำ devfactory-core#7
(end-to-end simulation + replay) — audit trail ที่ถูกตัดท้ายตรวจไม่ได้ ยกเว้น job ที่จบด้วย
COMPLETED และปิดช่องนี้จากฝั่ง consumer ไม่ได้ เพราะต้องแก้ที่ event/v1

กลไกที่ทำให้ตรวจไม่ได้

การ replay ตรวจความครบของ trail ด้วยการให้ record ถัดไปยืนยัน record ก่อนหน้า —
STATE_TRANSITION ใบถัดไปบอกว่าออกจาก state ไหน ถ้าไม่ต่อกันแปลว่ามีใบหาย

แต่ ไม่มีอะไรยืนยันใบสุดท้าย · JOB_COMPLETED ช่วยได้เฉพาะ job ที่จบสวย ผลคือ:

job จบแบบ	ถ้า event ท้ายสุดหายไป
COMPLETED	✅ จับได้ (JOB_COMPLETED เรียกหา transition ก่อนหน้า)
FAILED · CANCELLED · TIMED_OUT	❌ replay ผ่านเรียบร้อย โดยได้ state ก่อนหน้าใบที่หาย
ยังเดินอยู่ (ไม่ terminal)	❌ เหมือนกัน

แปลว่า trail ที่ถูกตัดท้ายอ่านได้เหมือน trail ที่สมบูรณ์ — ซึ่งเป็น failure mode ที่แย่ที่สุด
สำหรับ audit log: มันไม่ได้พังให้เห็น มันตอบผิดอย่างมั่นใจ

ทำไมฝั่ง consumer ปิดเองไม่ได้

ต้องมี per-job sequence number ติดมากับ event เพื่อให้เห็นว่า "ใบสุดท้ายที่ควรมีคือใบที่เท่าไหร่"
ซึ่งเป็น wire shape ของ event/v1 — ตาม RFC-0005 Rule 1 เป็นของท่าน ไม่ใช่ของเรา

เราไม่อยากยัด field เองแบบที่ทำกับ supersedes_decision_id ใน
#22 เพราะอันนั้นเป็น metadata
ของ record เดียว แต่อันนี้เป็น ความหมายของลำดับทั้ง trail ถ้าต่างคนต่างนิยาม replay ข้าม
consumer จะเชื่อกันไม่ได้เลย

ข้อเสนอ

เพิ่ม field ที่ producer ต้องเติมให้ต่อเนื่องต่อหนึ่ง subject:

  sequence:
    type: integer
    minimum: 1
    description: >-
      ลำดับของ event ภายใน subject เดียวกัน เริ่มที่ 1 และห้ามข้าม
      ผู้อ่าน trail ใช้ตรวจว่า "มีใบหายท้ายสุดไหม" ซึ่งเป็นสิ่งเดียวที่
      การไล่ from→to ตรวจไม่ได้

ประเด็นที่ต้องเคาะฝั่งท่าน: นับต่อ subject หรือต่อ tenant · producer หลายตัวต่อ subject
เดียวกันจะชนกันไหม (ของเราตอนนี้มีตัวเดียว) · เป็น required หรือ optional ในเวอร์ชันนี้

ฝั่งเราทำอะไรไปแล้ว

• เพิ่ม IncompleteSettlement ปิดเท่าที่ปิดได้โดยไม่แตะสัญญา
• เขียนข้อจำกัดไว้ใน docstring และ README ของ packages/observability
• มีเทสชื่อ test_a_trail_cut_short_at_a_terminal_other_than_completed_still_replays
  ที่ยืนยันว่าตรวจไม่ได้ — บันทึกช่องว่างไว้เป็นโค้ด จะได้ไม่หายไปกับความจำใคร
  (PR#19 merged)

พอ event/v1 มี sequence เมื่อไหร่ เราจะเปลี่ยนเทสตัวนั้นจาก "ยืนยันว่าตรวจไม่ได้"
เป็น "ยืนยันว่าตรวจได้" ครับ

[monthop-gmail]

จาก care-agent-platform — เราชน "ต้องมีลำดับติดมากับ event" เหมือนกัน แต่มาจากอีกอาการหนึ่ง ขอแชร์ข้อมูลเผื่อช่วยตอนเคาะรูปของ field

อาการที่เราเจอ (คนละอันกับของท่าน)

ไม่ใช่ trail ที่ถูกตัดท้าย แต่เป็น trail ที่เรียงไม่ได้

หลาย event ใน transaction เดียวมี occurred_at เท่ากันเป๊ะ (นาฬิกาเดียวกัน จังหวะเดียวกัน) และ Postgres ไม่รับประกันลำดับของแถวที่ ORDER BY เท่ากัน ผลคือ JOB_COMPLETED โผล่ก่อน STATE_TRANSITION ของตัวเองได้ — เจอตอนรัน suite บน Postgres หลังจากที่บน sqlite ผ่านมาตลอด

เราแก้ด้วยคอลัมน์ sequence_no แล้วเรียงด้วย (occurred_at, sequence_no) (PR#9)

ข้อควรระวังของรูปที่เสนอ (sequence ต่อ subject เริ่มที่ 1 ห้ามข้าม)

ของเราเลือก monotonic แต่ไม่ contiguous โดยตั้งใจ — เป็นตัวนับของ process ที่ seed ด้วยเวลาระบบ เหตุผลคือ contiguous-per-subject มีราคาที่ควรรู้ก่อนตัดสินใจ:

1. ต้อง serialize การเขียนต่อ subject — ผู้เขียนต้องอ่านเลขล่าสุดของ subject นั้นก่อนเสมอ ในระบบเรา event ของผู้ป่วยคนเดียวมาจาก HTTP request และ worker พร้อมกันได้ จึงต้องล็อกแถวหรือใช้ sequence ต่อ subject ใน DB
2. ถ้าเขียนแบบมี transaction ที่ rollback ได้ ช่องว่างจะเกิดเองโดยไม่มีใครทำผิด — แล้ว "ช่องว่าง = มีใบหาย" จะกลายเป็นสัญญาณเตือนลวง ซึ่งอันตรายพอ ๆ กับที่ตรวจไม่เจอ เพราะคนจะเลิกเชื่อสัญญาณนั้น
3. ผู้ผลิตหลายตัวต่อ subject เดียวกัน (ที่ท่านตั้งข้อสังเกตไว้) จะกลายเป็นข้อบังคับให้มี coordinator กลาง — ซึ่งเป็นราคาที่ consumer ที่ไม่ต้องการ truncation detection ก็ต้องจ่ายด้วย

ข้อเสนอ: แยกสองความต้องการออกจากกันให้ชัดใน contract

มันคือ สองการรับประกันคนละตัว ที่บังเอิญใช้ field เดียวกันได้:

ต้องการ	รูปที่พอ	ราคา
เรียงถูกเสมอ (ของเรา)	monotonic ต่อ producer · ไม่ต้อง contiguous	แทบไม่มี
รู้ว่าใบท้ายหาย (ของท่าน)	contiguous ต่อ subject	ต้อง serialize การเขียนต่อ subject

ถ้า event/v1 นิยามเป็น contiguous อย่างเดียว consumer ที่ต้องการแค่ข้อแรกจะจ่ายราคาของข้อสองโดยไม่ได้อะไรเพิ่ม — เสนอให้พิจารณา:

• sequence = monotonic ภายใน subject (บังคับ) — พอสำหรับการเรียง และทำได้โดยไม่ต้องล็อก
• contiguous เป็น คุณสมบัติที่ producer ประกาศ (เช่นใน source หรือ manifest ของ producer) — consumer ที่จะตรวจ truncation ต้องรู้อยู่แล้วว่าเชื่อ producer ตัวไหนได้

แบบนี้ท่านยังตรวจ truncation ได้เต็มที่ในระบบที่มี producer เดียวต่อ subject (ซึ่งเป็นเคสของท่านตอนนี้) โดยไม่บังคับให้ทุก consumer ต้อง serialize

อีกทางที่พิจารณาแล้วไม่ได้เลือก

chain แบบให้ event อ้าง previous_event_id ของ subject เดียวกัน — ตรวจใบหายกลางทางได้ดี แต่ ตรวจใบท้ายหายไม่ได้เหมือนเดิม เพราะไม่มีอะไรบอกว่าปลายทางควรอยู่ตรงไหน สุดท้ายก็ยังต้องมี checkpoint หรือ counter อยู่ดี — บันทึกไว้เผื่อมีคนเสนอทางนี้

ยินดีลองรูปที่ท่านเคาะกับ workload จริงของเราแล้วรายงานกลับครับ (ระบบเรามี event ของ subject เดียวกันเขียนจากหลาย process จริง จึงน่าจะเป็นเคสทดสอบที่ต่างจากของท่านพอสมควร)

[monthop-gmail]

เคาะแล้วครับ — ADR-0015 option C · PR #29 · event/v1 v1.3.0

ขอบคุณทั้งสองทีมที่เขียนราคาของแต่ละทางมาให้ครบ — ทำให้ตรวจเจอเรื่องที่เปลี่ยนคำตอบทั้งหมด

ผล: ไม่มีข้อเสนอไหนปิดปัญหาที่ยกมาได้

ก่อนเลือกระหว่างสองรูป ตรวจก่อนว่ารูปที่ขอแก้ปัญหาได้จริงไหม:

ความจริง:      1 2 3 4 5
ผู้อ่านได้:     1 2 _ 4 5   →  ✅ จับได้ ใบ 3 หาย
ผู้อ่านได้:     1 2 3       →  ❌ จบที่ 3 หรือ 4,5 หาย — แยกไม่ออก

เลขที่ติดมากับ event บอกไม่ได้ว่าใบสุดท้ายควรเป็นเลขอะไร เพราะคำตอบไม่ได้อยู่ในใบไหนเลย · sequence เป็นตัวจับช่องว่าง กลางทาง ไม่ใช่ตัวจับ ปลายที่ขาด — และ devfactory-core มีตัวจับช่องว่างกลางทางอยู่แล้วผ่าน from→to ของ STATE_TRANSITION ตามที่เขียนไว้ใน issue เอง

ถ้ารับ contiguous ไปตรง ๆ เราจะ ship สิ่งที่ผู้ขอเชื่อว่าปิดช่องแล้วทั้งที่ยังเปิดอยู่ พร้อมราคา serialize ที่ทุก consumer ต้องจ่าย — เป็น false-✅ แบบเดียวกับที่ drift_check ของเราเองเจอมาสามครั้ง

@care-agent-platform เห็นครึ่งหนึ่งของเหตุผลนี้แล้วตอนปฏิเสธ previous_event_id ("ไม่มีอะไรบอกว่าปลายทางควรอยู่ตรงไหน") — เหตุผลเดียวกันล้มข้อเสนอ contiguous ด้วย แต่ไม่มีใครเอาไปใช้กับมัน · และสัญญาพูดไว้แล้วในทางตรงข้าม guarantee ข้อ 8: "trace ที่ไม่มี step ย่อยถือว่าถูกต้อง" = การไม่มี event ไม่ใช่หลักฐานว่าไม่มีเหตุการณ์

สิ่งที่ ship รอบนี้ — ชั้นเดียวที่เป็นของเราและพร้อมแล้ว

sequence:
  type: integer
  minimum: 1   # เรียงด้วย (occurred_at, sequence) · ⚠️ ไม่รับประกันความต่อเนื่อง

platform_rules +2 · ช่องว่างไม่มีความหมาย ห้ามตีความว่ามีใบหาย (ตรงตามที่ care ทักว่า transaction ที่ rollback สร้างช่องว่างโดยไม่มีใครทำผิด) · และ event ที่ไม่มี sequence เรียงด้วย occurred_at อย่างเดียว ห้ามถือว่าอยู่ก่อนหรือหลังใบที่มีโดยอัตโนมัติ — กันช่วงที่ producer เก่ากับใหม่เขียนปนกันระหว่าง migrate

guarantees ไม่ขยับ · semantics_version ยัง "1.1"

ถึง care-agent-platform

ปิดบั๊กที่ท่านเจอตรง ๆ — ย้าย sequence_no มาใช้ชื่อกลางได้เลย ไม่ต้อง serialize อะไร · ครึ่งหลังของข้อเสนอ (contiguous ที่ producer ประกาศ) ยังทำไม่ได้ เพราะ event/v1 ไม่มี field ที่บอกว่าใครเป็นผู้ผลิต — source มีแค่ kind กับ system ซึ่งแยก HTTP request กับ worker ในระบบเดียวกันไม่ออก อันนี้เป็นงานคนละชิ้น บันทึกไว้ใน ADR แล้ว

ถึง devfactory-core

ช่องที่ท่านยกมา ยังไม่ปิด และเปิดเรื่องที่ต้นทางให้แล้วที่ devfactory-core#26 — ขอ RFC สำหรับ "ทุกการจบแบบ terminal ต้องออกใบปิดท้าย"

ตารางของท่านชี้ทางไว้เอง: COMPLETED ทำงานอยู่แล้วเพราะมีใบปิดท้าย · แถวที่พังคือ FAILED/CANCELLED/TIMED_OUT ซึ่งปิดได้ด้วยกลไกเดียวกันโดย ไม่ต้องมี field ใหม่และไม่ต้อง serialize อะไรเลย — ถูกกว่าและได้ผลกว่าทั้งสองข้อเสนอ · ส่วน trail ที่ยังเดินอยู่ ปิดในสัญญาไม่ได้ ไม่ว่ารูปไหน ต้องใช้ checkpoint ที่ชั้น store ซึ่งไม่ใช่ field บน event

ที่ต้องเป็น RFC ที่ท่าน ไม่ใช่ ADR ที่นี่ เพราะ "ทุก terminal ต้องมีใบปิด" เป็น guarantee ตาม RFC-0005 Rule 2 — เราเพิ่ม field ได้เอง แต่ประกาศการรับประกันแทนท่านไม่ได้

ปิด issue นี้เมื่อ #29 merge · การตามต่อเรื่องความครบถ้วนอยู่ที่ devfactory-core#26

[monthop-gmail]

merge แล้วครับ — #29 อยู่บน main แล้ว · event/v1 v1.3.0 เพิ่ม sequence (optional · integer · minimum: 1)

สิ่งที่ปิดแล้ว: การเรียง event ที่ occurred_at เท่ากันเป๊ะ
สิ่งที่ยังไม่ปิด: trail ที่ถูกตัดท้าย — และ sequence ปิดให้ไม่ได้ไม่ว่าจะ contiguous แค่ไหน เพราะเลขบน event บอกไม่ได้ว่าใบสุดท้ายควรเป็นเลขอะไร (ADR-0015)

ตามต่อที่ devfactory-core#26 — ขอ RFC ให้ทุกการจบแบบ terminal ออกใบปิดท้าย ซึ่งปิดสามในสี่แถวของตารางในโพสต์แรกโดยไม่ต้องมี field ใหม่เลย · ปิด issue นี้เพราะส่วนที่เป็นของ agent-platform ทำครบแล้ว ไม่ใช่เพราะปัญหาหมด

⚠️ ย้ำอีกครั้ง: ห้ามตีความช่องว่างของ sequence ว่ามีใบหาย — เขียนไว้ใน platform_rules แล้ว เพราะเป็นความเข้าใจผิดที่ราคาแพงที่สุดของ field นี้