delivery-semanticslisted

# Delivery Semantics ## Purpose Decide which delivery guarantee a path needs, and place the acknowledgement so the code actually provides it. The guarantee is not a broker setting; it is the position of the ack relative to the side effect, plus whatever the application does about duplicates. The failure this prevents is the system designed against a guarantee nobody implemented: a team believes the platform gives "exactly-once", the handler is not repeat-safe, and the first rebalance during a slow poll charges a customer twice. The second failure is its mirror — a consumer that acknowledges first and can silently drop unfinished work on a crash, which produces no error anywhere and is discovered by reconciliation months later. ## Workflow Java snippets are partial illustrations using Java 17 syntax, Kafka client 4.1 API and Jakarta Messaging 3.1 contracts, not complete consumers. Inspect resolved clients/provider, broker version, framework acknowledgement mode, transaction manager and durability/retention configuration. Existing project versions govern implementation; do not upgrade to fit a snippet. 1. **Name the required outcome, input identity and each side effect.** Inspect the current handler, effective configuration and recovery path before recommending a change. Locate effects inside the same broker cluster, in a database, or at a third party; a transaction cannot cover participants it does not enlist. Ask for missing loss tolerance or provider guaran