Separate publisher confirms from consumer acknowledgements for AI jobs

Ask which peer acknowledged what

An AI preprocessing dispatcher sees an acknowledgement and marks a summary completed. Elsewhere, a worker acknowledges its latest completed delivery and unintentionally covers another unfinished task. Both mistakes collapse different boundaries into one generic success flag.

The two official references inspected identify RabbitMQ documentation version 4.4. This worksheet selects AMQP 0-9-1 publisher confirms and manual consumer acknowledgements. Installed broker, client library, routing, queue type and persistence settings remain unknown.

Publisher confirms and consumer acknowledgements are independent: the former concerns publisher-to-broker interaction; the latter concerns broker-to-consumer delivery. A publisher confirm can also concern an unroutable publish. It therefore does not establish intended-queue admission, model completion or a downstream effect.

Bind a delivery to its channel before its job

The delivery-tag contract uses increasing positive integers scoped to a channel. Deliveries must be acknowledged on their receiving channel; unknown or repeated acknowledgements can produce channel errors. A remembered number alone is not a global job identifier.

Propose a protected association between active connection/channel identity C-A, received tag reference D-A, immutable application job J-A and its accepted content identity. Those references are fictional, not actual delivery metadata. Establish the association from the trusted receiver path and application record; a job field supplied by an arbitrary payload cannot grant authority.

This mapping, current object rights and a separately supported durable application disposition are unimplemented prerequisites. If any is unknown, the positive plan is blocked. No automatic client-recovery behavior or channel-generation scheme is supplied here.

Keep one ordinary two-job positive

The proposed positive acknowledges only D-A using the documented individual mode, leaving D-B outstanding. This supports useful progress without treating two deliveries as one completed application batch. It reports neither an observed broker acknowledgement nor a model result.

Before that decision, the consumer needs evidence that J-A’s required disposition is actually established, not merely present in a local variable. The reliability guide says consumers should finish their required work before acknowledging; acknowledgement lets the broker mark the delivery for deletion. It does not inspect whether the application’s own success claim is truthful.

Review the complete acknowledged set

With multiple=true, basic.ack coverage includes all outstanding tags up to and including the supplied tag on that channel. Individual mode does not cover the other outstanding deliveries.

Now change the worksheet: J-B has its required disposition, while earlier J-A remains pending. A cumulative acknowledgement through D-B would cover D-A too. Reject that plan; later completion proves nothing about the earlier job’s disposition. Even a two-row worksheet is not evidence that an actual channel contains only those two deliveries.

This narrow profile deliberately uses individual acknowledgements. A future cumulative design would need supported evidence for its entire acknowledged set; this guide supplies no implementation, enumeration or batching algorithm. Automatic mode is also different: the broker considers delivery successful when sent, rather than waiting for the later manual application decision.

Use eight inert boundary cards

Record acknowledgement direction, active channel, delivery association, individual/cumulative mode, required disposition and observed outcome separately. A boolean named acknowledged cannot explain those distinctions.

Preserve uncertainty without inventing exactly-once work

The reliability guide explains that a broker confirmation can be lost before reaching the producer; retransmission can then create duplicates. It also states that a redelivered flag is a hint of possible prior receipt, not proof that a consumer previously saw the message.

The same guide notes that connection failure closes its channels. A replacement channel requires its own evidenced associations; do not predict a particular error or safe outcome from coincident tag numbers. Existing job disposition must remain separate from delivery history.

This article implements no retransmission, claim, lease, duplicate-effect or recovery service. Actual topology, persistence, complete routing evidence and client behavior require separate review. No no-loss, physical-durability, ordering or exactly-once business-effect guarantee follows from the worksheet.

State the evidence actually collected

For these proposed cases, no broker, channel, queue, client, publish, consume or acknowledgement operation was created or run. No worker, network, API or model experiment occurred. Ordinary documentation reads and private editorial file handling are separate.

Boundary is a prelaunch model router with planned request-path checks, not a shipped broker or job-processing service. The synthetic action exercise and existing mock evidence do not validate this AMQP contract or its application prerequisites.