ProcessorExpectations

The commands the handlers called synchronously, in order, each answered by ProcessorSpec.answerCalls; those of a handling that threw are not listed.

The commands the handlers derived, in order, but the schedules they set or cancelled (schedules).

What a handler threw; null when they all returned.

The handlers called, by subscription name (processor.function), in order.

The schedules the handlers set or cancelled: their derived system commands wow.schedule.Set and wow.schedule.Cancel, in order.

The handlers called commands of exactly these bodies synchronously, in order, field by field as Wow writes them to JSON: a mismatch lists each difference by its path.

The handlers derived exactly one command, a C, whose body check checks, as an aggregate's Expectations.expectEvent checks its event: that body.

The handlers derived exactly one command, of body, to to when given, as expectCommands compares them: that command.

The handlers derived exactly one command, of type, whose body check checks: that body.

The handlers derived exactly count commands, as an aggregate's expectEventCount counts its events.

The handlers derived exactly one command, a C, which check checks with its envelope: the aggregate it goes to, its ids, scope, request facts and operator beside its body (Command.body), as an aggregate's Expectations.expectEventEnvelope checks its event's.

The handlers derived exactly one command, of type, which check checks with its envelope.

The handlers derived commands of exactly these bodies, in order, field by field as Wow writes them to JSON: a mismatch lists each difference by its path, [0].quantity: expected 3, was 2.

The handlers derived exactly these commands, each a body to the aggregate it goes to (stock to ReserveStock(…)), in order, as expectCommands of bodies compares them.

The handlers derived commands of exactly these types, in order.

A saga's handling of the same commit, or rejection, again, with a fresh context as the runtime gives a retry, derives the same commands (ids and request ids included), the schedules among them, and calls the same ones: the targets decide them once. A projection's or a reactor's handling would run its side effects again, so it has no such check.

A handler threw a T, which check checks.

A handler threw a type, which check checks.

The handlers called are exactly functions, by function name or subscription name, in order.

The handlers called no command synchronously.

The handlers derived no command.

No handler threw.

The handlers changed no schedule.

The handling failed, and the runtime parks it after this attempt, the first by default, for its parked retries and an operator, as parking reads what it threw.

The handling failed, and the runtime retries it after this attempt, the first by default, as parking reads what it threw. The backoff between the attempts is the runtime's. A handling that ran longer than its @Retry(timeout) was cancelled, and threw a me.ahoo.wow.kernel.HandlerTimeoutException.

The handlers cancelled the schedule key, of target when given.

The handlers scheduled command under key: they derived wow.schedule.Set to target when given, which schedules command as rule says when it is given.

Runs block on a copy of the specification as this handling left it, as ProcessorSpec.fork does: the scenarios after a handling branch from its checks, a rejection of the command it derived in one fork and its receipt in another, say. A check that fails before it ends the block, so the forks after it do not run.

Hands the success receipt of command, one this handling derived, to the saga's @OnCommitted handler of it, as ProcessorSpec.whenCommitted does: the specification goes on from this handling.

Hands the rejection of command, one this handling derived, to the saga's @OnRejected handler of it, as ProcessorSpec.whenRejected does: the specification goes on from this handling.