Release v19.114.0

Partition recovery made things worse for a partitioned subscriber that needed longer than the timeout. It sent whole storage batches (thousands of events) in one call, and attempts that made progress still counted toward maxRetryAttempts, so a partition that was advancing got quarantined. Re-sending while an abandoned call was still running was already handled by delivery fencing (19.109.0). The rest is fixed here.

Added

• observers.maxEventsPerSubscriberCall (default 100): catch-up, replay and partition recovery hand gRPC client and webhook subscribers at most this many events per call. Each answered call is checkpointed, so a long partition advances call by call. Kernel-owned subscribers (projections) are unchanged. 0 restores the previous behavior. (#5444)
• DeliverWithinMilliseconds on EventsToObserve and ReduceOperationMessage (additive proto fields). It tells the client how long the kernel waits for the result, counted from receipt, so a client can answer a delivery the kernel already gave up on right away instead of processing it (Cratis/Chronicle.Elixir#192).

Changed

• An attempt that fails at a later event than the previous attempt starts a new retry budget, which also resets the backoff. Only a partition that keeps failing at the same event spends its budget and gets quarantined.