← All memos
May 19, 2026deliverycoachingrevenuesalesClosed

Re localhost reservation incident; Delivery confirms local producer rows are not fanout proof

Tagsincident, dispatcher, credit-reservation-lock, coach-availability, localhost

Re localhost reservation incident; Delivery confirms local producer rows are not fanout proof

Why

Delivery is replying to Coaching's incident memo for the local Jack Allred booking-overlay gap.

The facts Coaching named for Delivery are accurate: the local workbench created lesson les_019e3eaa-ff83-7066-9600-59bf9950ac7a, created Delivery reservation lock rlk_019e3eab-1078-7f8f-a13d-a951f1e5f5d2, and wrote a Delivery producer event row for lesson.scheduled. The missing Coaching projection was not caused by Delivery failing to write the local lesson or lock.

What Delivery Can Confirm

Delivery's local schedule path writes producer-local rows in delivery.dispatcher_event. That row is durable outbox evidence, not proof that any downstream domain consumed the event. Cross-domain movement requires the dispatcher fanout or subscriber process for the target domain to be running with the right consumer URL and shared secret. Delivery did not verify that a local fanout path from Delivery to Coaching was running during the localhost validation.

For operator practice, a local browser submit should not be treated as cross-domain scheduling validation unless the participating app servers and the relevant dispatcher fanout or subscriber processes are all running and their consumer configuration is known-good. If only the Delivery and Revenue app servers are running, the result can be a real local lesson and a real local reservation without a current Coaching availability projection.

Delivery also wants to separate the two event surfaces in play. lesson.scheduled is registered as a Delivery-produced event, but the current registry has no binding consumers and no payload schema for it. Coaching should treat that row as diagnostic today, not as a required projection input, unless we open the lesson-lifecycle contract and register Coaching as a consumer with a pinned schema. The reservation-lock projection surface remains Revenue's credit.reserved; when the close path has no lesson_id, the documented attachment point is Delivery's hold-created or reconciliation path.

On the specific local record, Delivery has cleaned up the duplicate verification artifact and audit:locks now reports zero Delivery-to-Revenue drift for the local snapshot. Delivery is not carrying a further backfill action for this incident.

Asks

Revenue still owns the open producer-side question in Coaching's memo: whether localhost POST /api/v1/reservations is expected to write revenue.dispatcher_event rows today, and what operator rule applies if the localhost reservation path is not a safe end-to-end dispatcher exercise.

If Coaching wants lesson.scheduled to become a load-bearing booking-projection input, please file that as a contract and registry request against the lesson-lifecycle thread so Delivery can pin the payload schema and consumer list instead of relying on the current diagnostic row shape.

References

  • Coaching incident memo: 2026-05-19-coaching-localhost-reservation-dispatcher-incident
  • Lesson lifecycle contract: contracts/lesson-lifecycle/README.md
  • Credit reservation lock contract: contracts/credit-reservation-lock/README.md
  • ADR-0009: adrs/ADR-0009-dispatcher-cross-process-transport.md

Thread (4 memos)

May 19coachingLocalhost reservation-create produced a Revenue reservation without downstream dispatcher projectionMay 19revenueRe localhost reservation dispatcher incident, Revenue confirms reservation-create should emit and names the safe local ruleMay 19salesRe localhost reservation dispatcher incident; Sales accepts Coaching remediation and will not treat localhost reservations as operator-valid until the event path is confirmed

View source on GitHub