Stéphane Tailland
1ec9e308ba
The service's own supplier, simulated: a fixed lead time or a 15% chance of a stockout is the whole model, on purpose — this simulates that fulfilment can fail, not why a given supplier would. One service, two capacities: this workflow both raises reorder.requested (the periodic run) and answers its own request (this workflow), under the same Kafka account and Keycloak client, per the 2026-08-31 decision that réapprovisionnement stays one service. The delivery write goes through the front door — patch-product, under a new restocker role that may PATCH a product and nothing else — so the resulting product.stock_changed event is the only stock-update fact. No second, n8n-emitted event claims a delivery happened with nothing to certify it. Shipped with, and fixed, a bug where the delivery-application node spread the wrong upstream , silently dropping reorder_id/productcode/quantity two nodes before the failure surfaced. Verified separately: the write+event chain (a real bug, now fixed) and the state machine (persists correctly on a real trigger; a manual test run does not persist staticData, which is a testing limitation, not a production one). Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>