CommandIntake

The command intake of one bounded context: the subscription NAME of its command topic, run by the owners of the context's log partitions, each over the command partition of the same number, so a command is executed where its aggregate's log partition is owned, with no forwarding.

For each command, in its aggregate's lane (one aggregate's commands in order, different aggregates in parallel):

1. Execute it through the context's coordinator (WaitCoordinator.forward) with the wait context its envelope carries, a creation that names no aggregate given its id first by creations: the kernel deduplicates by request id (per aggregate type), so a command delivered twice, or sent twice by a saga that retried, is not decided again; the waiting node is signalled as for a saga's command.

2. Settle the outcome: committed, a duplicate or no change is done; when the command asks for the receipt of its commit (me.ahoo.wow.runtime.cluster.ReplyTo.committed), the receipt, a CommandReceipt.Committed with the aggregate, its version and the command's result, no state, is sent to wow.<replyTo.context>.receipts and acknowledged by the broker before the entry completes, in the same order as a rejection's below. A duplicate request answers with the original aggregate and version again, the result marked duplicate; the saga drops the copy by the command id. A receipt carries the command's wait context past its commit, so a chain whose next hop is the saga's @OnCommitted handler goes on through it. A rejection is a business outcome: it is not retried nor parked, and nothing is written to the log; when the command says where to reply (CommandWire.replyTo), the receipt, a CommandReceipt.Rejected, is sent to wow.<replyTo.context>.receipts and acknowledged by the broker before the entry completes, so the checkpoint never passes a rejection whose receipt is not durable. A crash in between handles the command again from the checkpoint: it is rejected again and its receipt sent again, which the sender drops by the command id.

3. Technical failures throw: a contended or unknown outcome, an executor that is closing, a store that is down, a receipt the broker does not acknowledge. The subscription retries them, then parks the aggregate in the context's failure ledger under NAME, at the command's offset (me.ahoo.wow.spi.ledger.ParkedAggregate.fromPosition); its later commands wait until it is retried or skipped.

An aggregate type or command type the context does not know is the sender's mistake, or a contract the sender has and this service does not yet: it is not this aggregate's failure, and parking it would hold its later commands for an operator. Such a command is rejected as FrameworkCodes.COMMAND_UNHANDLED, with its receipt as in 2 (unhandled). A command whose body the node's validators (the gateway's) find violations in is rejected as FrameworkCodes.COMMAND_INVALID, listing them, the same way and before any aggregate decides it (invalid), as the gateway refuses an admitted one.

A command the node refuses as busy is backpressure, not a failure: the intake throws a me.ahoo.wow.runtime.CommandBusyException, which its subscription retries after a backoff without spending its retry budget. The intakes of a node execute at most InFlightLimit.intakes commands at once, half its in-flight bound, so a node that owns many partitions of a backlog leaves room for its callers, sagas and timers. A command a schedule sent waits in its lane for its due time first (awaitDue).

The checkpoint is the offset after the last command whose outcome is settled, every command before it settled too (the subscription's contiguous low watermark), so a handover or a restart executes again at most what was in flight, which the kernel deduplicates.

The ledger's system commands (wow.ledger.*), which the ops context sends for an entry of this service, are not the kernel's: ledger runs them on the node's parked entries, and settles them as above.