feat(shard-distributor): Add ping verification to ephemeral shard creator #7496
+267
−89
Conversation
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
jakobht
requested review from
3vilhamster,
Shaddoll,
davidporter-id-au,
demirkayaender,
dkrotx,
neil-xie,
sankari165,
shijiesheng and
taylanisikdemir
as code owners
jakobht
force-pushed
the
add-ephemeral-shard-ping
branch
3 times, most recently
from
a043f8b to
f9d6569
Compare
jakobht
changed the title
jakobht
force-pushed
the
add-ephemeral-shard-ping
branch
7 times, most recently
from
0046451 to
9353d41
Compare
After creating a shard, the ephemeral shard creator now pings the owner to verify that: 1. The shard was created successfully 2. The owner can be reached via gRPC 3. The owner actually owns the shard This provides end-to-end validation of the shard creation and routing mechanisms in the canary test environment. Changes: - Switch from using ShardDistributor client to using Spectators - Add pingShardOwner() method that sends canary ping after creation - Verify executor ID and ownership in ping response - Log warnings if executor ID mismatches or ownership is incorrect - Add test coverage for ping verification flow - Use refactored *spectatorclient.Spectators type Signed-off-by: Jakob Haahr Taankvist <jht@uber.com>
Integrate all canary components into the module: - Create SpectatorPeerChooser and manage its lifecycle - Provide canary client using the dispatcher - Create and start the pinger component - Register ping handler as a YARPC server - Wire spectators to peer chooser on startup This connects all the pieces needed for executor-to-executor canary testing via ping/pong requests. Dependencies: - Requires SpectatorPeerChooser - Requires PingHandler - Requires Pinger component Signed-off-by: Jakob Haahr Taankvist <jht@uber.com>
Signed-off-by: Jakob Haahr Taankvist <jht@uber.com>
Signed-off-by: Jakob Haahr Taankvist <jht@uber.com>
Signed-off-by: Jakob Haahr Taankvist <jht@uber.com>
Signed-off-by: Jakob Haahr Taankvist <jht@uber.com>
jakobht
force-pushed
the
add-ephemeral-shard-ping
branch
from
3efbb33 to
150093f
Compare
eleonoradgr
reviewed
Dec 3, 2025
|
|
||
| fx.Provide( | ||
| func(t *grpc.Transport) peer.Transport { return t }, | ||
| ), |
Contributor
There was a problem hiding this comment.
we have transport in fx.supply, do we need this? it seems redundant
eleonoradgr
approved these changes
Dec 3, 2025
| }), | ||
|
|
||
| fx.Provide( | ||
| func(t *grpc.Transport) peer.Transport { return t }, |
Contributor
There was a problem hiding this comment.
we have transport in fx.supply, do we need this? it seems redundant
|
|
||
| for executorID, state := range namespaceState.Executors { | ||
| if now.Sub(state.LastHeartbeat) > p.cfg.HeartbeatTTL { | ||
| p.logger.Info("Executor has not reported a heartbeat recently", tag.ShardExecutor(executorID), tag.ShardNamespace(p.namespaceCfg.Name), tag.Value(state.LastHeartbeat)) |
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.
What changed?
The ephemeral shard creator now pings shard owners immediately after creation to verify end-to-end functionality.
This also wires up the spectator, and dispatcher and fixed namespace pinger.
Why?
This adds canary verification that validates:
Previously, the shard creator only verified that GetShardOwner returned successfully, but didn't verify that the executor was actually reachable or owned the shard.
How did you test it?
Unit tests
Potential risks
Low risk - this only affects the canary test environment and adds verification without changing core shard creation logic.
Documentation