Technical notes

Part 4 of 4 · Reading iVendNext's events reliably

Back: Two patterns built on the feed, and the nudgeNext: the sample, S3 · Price-deviation audit

What was proven where

• Proven on our test bench on 2026-10-04: the client stopped, sales booked, the client restarted and crashed before marking done, restarted again — every event collected once and none from another application, on both transports below — on the engine transport only because the client filters to its own rows (the key itself can reach the others', §3).
• At least once, §2: S3's outside service names each deviation after the sale line, so a second delivery answers 409 and writes nothing (proven by a full replay). Proven: a crash after 3 handled events and before done — on restart those 3 were skipped as seen, none handled twice.
• The engine transport's scope, §3: ⚠ none on the server. The log's application name is plain text, so the grant reaches every application's rows. Measured: app A's key read 24 of app B's rows and marked one of them done.
• The door's scope, §3: the server's: only the caller's own application's rows. Measured: A's key asking done for one of B's ids was refused whole ("One of these events is not yours."), B's queue unchanged.
• The door's status, §3: ✅ the door is live. Its events call, sent as a POST, was read on a test site on 2026-10-09. The crash-and-restart and two-application results above were taken against our stand-in for the door, which follows the contract — UNPROVEN against the live door.
• Events per sale, §4: a till sale followed as POS Invoice produced 6 rows on the bench (inserted, updated, submitted, and three changes).
• Lag, §4: on the bench, with the worker busy (a stock receipt's follow-up jobs), the rows of two sales took 58 seconds to appear (measured with sample S3's outside service).
• Reconciliation, §5: Proven: with one sale's event deleted on purpose, it named exactly that sale. Proven on the laptop only, against an in-memory stand-in for iVendNext: after a lost folder every handled sale reads unknown and none missing; a sale skipped after the new folder began reads missing; a sale still queued reads still_queued; a folder that holds seen events (an upgrade in place) takes no marker.
• The pictures, §6: our test bench, 2026-10-10; frames: the till at 1440 wide, then Desk. On the bench the feed was read through the programme's stand-in door.
• The nudge, appendix A: UNPROVEN: the nudge was not run on our test bench (it is configuration only; its signing is the webhook recipe's, proven there).

Bounds, stated

• The door's crash-and-restart results are against the stand-in, not the live door (above).
• unknown is bounded two ways: a sale is dated by when its draft was saved, so a draft saved before the loss, submitted after it and then skipped reads unknown; and the marker is taken at the first pass that reaches the retailer's iVendNext, so a sale skipped during a start-up outage reads unknown. Both are listed, never silent. After a restart the list holds the window's sales from before it that the new folder did not handle, for as long as they stay inside --since; only a lasting disk keeps it empty.
• Measured with two applications: 4 sales and 1 customer on the engine transport, 3 and 1 on the door; volume beyond that is the scale-profile kit's (tools/scale_profile/) — and it is sequential.
• The engine's grant cannot be scoped today; the proposed engine change (the log's application name as a link, the cashier's rights on the log narrowed) has been proposed to our product team.

Back: Two patterns built on the feed, and the nudgeNext: the sample, S3 · Price-deviation audit

This page in the kit