Picks up JasperFx#632, which fixes the Count accounting Wolverine's back-pressure reads: PushUpstream built its BlockSet with an empty 'previous' list, so the downstream block -- the one actually executing the work -- was invisible to the set. Count double-counted the top transform stage and reported ZERO for any backlog held downstream. ShardedExecutionBlock.DeserializeFirst composes exactly that shape for both BufferedReceiver and DurableReceiver, so a PartitionProcessingByGroupId endpoint latched back-pressure against the wrong number and then decided whether to RESUME against that same wrong number. Also in the range: JasperFx#600/JasperFx#601 (the app-assembly stack walk could adopt a test runner -- JasperFxGH-3776/JasperFxGH-3777) and JasperFx#599 (DatabaseId escaping surviving a System.Uri round trip). JasperFx.RuntimeCompiler stays on its own 5.x line. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01WHAuhdWS3XeAk16swV9G8m

Uh oh!

Uh oh!

Disambiguate multiple usages of ProblemDetails in the same chain #632

Description

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions