admin: handle service restart on shard 0#29519
Conversation
The pandaproxy and schema_registry APIs are owned by shard 0. Handle their restart on shard 0 to ensure that any allocations/deallocations happen on the correct shard.
pgellert
requested review from
IoannisRP,
Copilot and
michael-redpanda
and removed request for
a team
There was a problem hiding this comment.
Pull request overview
This PR fixes a bug where the admin API service restart functionality was not handling pandaproxy and schema_registry services on the correct shard. These services are owned by shard 0, and the restart operation now ensures that allocations/deallocations happen on shard 0 by using invoke_on(0, ...).
Changes:
- Modified the
restart_service_handlerto invoke the restart operation on shard 0 instead of the current shard
| co_await restart_redpanda_service(*service); | ||
| co_await container().invoke_on(0, [service](admin_server& server) { | ||
| return server.restart_redpanda_service(*service); | ||
| }); |
There was a problem hiding this comment.
I noticed this in CI failures on another PR (#29517). It's unclear if this could have any user-visible impact, because I expect that the cross-shard de/allocations would still succeed in production, but there is certainly some possibility for data races, so it is definitely worth backporting.
Retry command for Build#80085please wait until all jobs are finished before running the slash command |
|
/ci-repeat 1 |
|
/ci-repeat 1 |
|
/backport v25.3.x |
|
/backport v25.2.x |
|
/backport v25.1.x |
The pandaproxy and schema_registry APIs are owned by shard 0. Handle their restart on shard 0 to ensure that any allocations/deallocations happen on the correct shard.
Backports Required
Release Notes
Bug Fixes