fix(bindings): forward the full streaming config through the standalone clients#808
Merged
Merged
Conversation
…ne clients The standalone Python and TypeScript StreamingClient builders only carried a subset of the streaming and reconnect tuning surface. Knobs like host selection, the watchdog and keepalive cadences, the reconnect backoff and replay pacing, and the newer wait strategy and consumer-core affinity were silently dropped, so tuning DirectConfig and then using a standalone client gave you builder defaults instead. Both bindings now snapshot the whole StreamingConfig and ReconnectConfig out of the user's Config and thread every field into StreamingClientBuilder, the same wholesale-snapshot the C ABI uses. That keeps the standalone connect path on the same ring-build and consumer-affinity code as the unified client, and a future config field cannot drift out of a hand-maintained subset. The C ABI builder was also missing the wait strategy and consumer-core knobs; it now forwards them too, so every client reaches the same connect surface. Each binding crate gets a regression test that sets every streaming and reconnect knob to a non-default value, snapshots the params, and asserts each one survives, so a forgotten field fails the build instead of dropping a user's tuning. Closes #802 Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The standalone Python and TypeScript StreamingClient builders carried only a subset of the streaming and reconnect tuning surface that the unified client and the C ABI forward. Several knobs were silently dropped: host selection and shuffle seed, the IO read slice and data watchdog, the keepalive idle/interval/retries cadence, the reconnect ceiling and server-restart and replay pacing, and the newer wait strategy and consumer-core affinity. Setting those on DirectConfig and then opening a standalone client gave you builder defaults instead of your tuning.
Both standalone clients now snapshot the whole StreamingConfig and ReconnectConfig out of the user's Config and thread every field into StreamingClientBuilder. This is the same wholesale-snapshot the C ABI already uses, so the standalone connect path reaches the same ring-build and consumer-affinity code as the unified client, and a future config field cannot drift out of a hand-maintained subset.
The C ABI builder was itself missing the wait strategy and consumer-core knobs, so it now forwards those too and every client lands on the same connect surface.
Each binding crate gets a regression test that sets every streaming and reconnect knob to a non-default value, snapshots the params, and asserts each one survives the snapshot. A forgotten field fails the build rather than dropping a user's tuning.
Closes #802
🤖 Generated with Claude Code