Batching honors a batch handler registered with AddMessageHandler

[jeremydmiller]

Batching honors a batch handler registered with AddMessageHandler

Problem

BatchMessagesOf<T>() refused a batch handler registered with opts.AddMessageHandler(typeof(TBatch), handler) — a pre-generated or hand-written MessageHandler. Two places looked the batch type up with HandlerGraph.ChainFor, which reads discovered chains only:

• BatchingOptions.ProcessorBuilder<T>.Build threw on the first element — "…there is no known handler for T[]" — so every element went to the error queue. The message also named T[] even when a custom IMessageBatcher produces a different batch type.
• WolverineRuntime.applyBatchProbePolicies skipped ProbeIndividuallyAfter(n) for such a handler without a word.

Found by CritterWatch (JasperFx/CritterWatch#1356): its embedded console now registers pre-generated handler classes with AddMessageHandler, so an embedding host needs no runtime compilation. The console batches its telemetry, and the console received nothing.

Fix

HandlerGraph.ChainOrRegisteredHandlerChainFor(Type) (internal): the discovered chain, else the chain of a MessageHandler in the pre-canned map. It reads the map directly rather than through HandlerFor, so a miss is not memoized and an IAgentCommand type does not take the agent path. Both call sites use it. The error names batcher.BatchMessageType.

Tests

CoreTests.Acceptance.batching_with_a_registered_batch_handler — the element type is batched onto the registered handler's chain, the probe policy reaches that chain, and batches are delivered end to end. All three fail without the fix (verified by reverting src/Wolverine) and pass with it. All 345 batching/pre-canned tests and the full CoreTests suite (3,111 passed, 2 skipped, 0 failed, net9.0) are green.

Also verified downstream: CritterWatch packed against a local 6.40.1-cw1356.1 — its embedded console lists its own host within a second, where it never did on 6.40.0.

🤖 Generated with Claude Code