[feat] PIP-468: V5 client end-to-end smoke test + segment-bypass for internal subscribe/read#25586
Merged
merlimat merged 2 commits intoapache:masterfrom Apr 27, 2026
Merged
Conversation
…read The V4 client rejects segment:// topics for end-user subscribe/read paths (introduced in apache#25573 to keep the segment:// domain internal to V5). The V5 ScalableQueueConsumer / ScalableStreamConsumer / ScalableCheckpointConsumer themselves create per-segment v4 consumers and readers, and were tripping over the same check via the public ConsumerBuilder/ReaderBuilder paths. Mirror the existing PulsarClientImpl.createSegmentProducerAsync escape hatch with two new internal-only entry points: - subscribeSegmentAsync(ConsumerConfigurationData, Schema) — used by ScalableQueueConsumer and ScalableStreamConsumer. - createSegmentReaderAsync(ReaderConfigurationData, Schema) — used by ScalableCheckpointConsumer. Both validate single-topic config, sub/start-message-id, and topic name syntax, then bypass the scalable-domain check and dispatch to the existing single-topic subscribe/reader codepaths. The three V5 internal callers now build a config object directly and invoke the bypass instead of going through the v4 builder.
- pulsar-broker testImplementation: add pulsar-client-v5 and
pulsar-client-api-v5 so V5 end-to-end tests can live alongside the
rest of the client integration tests.
- New V5ClientBaseTest extending SharedPulsarBaseTest:
- newV5Client() builds a V5 PulsarClient against the shared
in-memory cluster.
- newScalableTopic(int) creates a topic:// scalable topic in the
per-test namespace via the admin API.
- track(...) registers producers / consumers / clients for ordered
cleanup in @AfterMethod.
- New V5SmokeTest exercises the full happy path on a 1-segment topic:
admin createScalableTopic -> DagWatchClient session -> per-segment
producer create -> wire send -> per-segment consumer attach ->
receive -> ack.
This was referenced Apr 27, 2026
Merged
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
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.
Summary
First end-to-end test for the PIP-468 V5 client, plus the small plumbing
fix it surfaced.
Plumbing fix — segment-domain bypass for V5 internals
The V4 client rejects `segment://` topics for end-user subscribe / read
paths (added in #25573 so the segment domain stays internal to the V5
SDK). But the V5 `ScalableQueueConsumer` / `ScalableStreamConsumer` /
`ScalableCheckpointConsumer` themselves build per-segment v4 consumers
and readers and were tripping over the same check via the public
`ConsumerBuilder` / `ReaderBuilder` paths.
Two new internal-only entry points on `PulsarClientImpl` mirror the
existing `createSegmentProducerAsync` escape hatch:
Both validate the config (single topic, valid topic name, sub /
`startMessageId` set), then skip the scalable-domain check and dispatch
to the existing single-topic codepaths. The three V5 internal classes
build a config object directly and invoke the bypass instead of going
through the v4 builder.
End-to-end test infra
`pulsar-client-api-v5` so V5 end-to-end tests can live next to the
other client integration tests.
cluster.
the per-test namespace via the admin API.
cleanup in `@AfterMethod`.
scalable topic:
admin `createScalableTopic` → `DagWatchClient` session → per-segment
producer create → wire send → per-segment consumer attach → receive
→ ack.
This is the start of a phased E2E test suite. Subsequent PRs will add
per-consumer-type basic tests (Stream / Queue / Checkpoint), schema
matrix, producer / consumer feature coverage, and (separately, on a
multi-broker base class) controller leader-election / redirect /
rebalance scenarios.
Test plan
"org.apache.pulsar.client.api.v5.V5SmokeTest"` passes (1/1).
:pulsar-client-v5:checkstyleMain
:pulsar-client-original:checkstyleMain` clean.
still pass.