Skip to content

Distinguish router and non-router replicas - #4101

Open
jvstme wants to merge 2 commits into
masterfrom
issue_3959_distinguish_router_and_non_router_replicas
Open

Distinguish router and non-router replicas#4101
jvstme wants to merge 2 commits into
masterfrom
issue_3959_distinguish_router_and_non_router_replicas

Conversation

@jvstme

@jvstme jvstme commented Aug 5, 2026

Copy link
Copy Markdown
Collaborator

Problem: Non-router replicas in a service with
a router should not be registered on the gateway.
To determine whether a particular replica should
be registered, one has to parse its job spec and
run spec and see if it is a router replica or not.
This does not work well for the upcoming gateway
state sync mechanism, which needs to quickly fetch
all jobs to be registered from the database,
without parsing their specs.

Solution:

  • Do not set JobModel.registered for
    non-router replicas in services with a router.
    That way, JobModel.registered can be reliably
    used to identify the jobs that should be
    registered on the gateway, without parsing the
    job spec.
  • Since the router worker sync pipeline needs both
    router and non-router replicas with successful
    probes, introduce JobModel.ready, set for any
    replica once probes pass.
$ dstack event --within-run prefill-decode | grep -E "ready|register"
[2026-08-05 10:30:29] [job prefill-decode-0-0] Service replica ready to receive requests
[2026-08-05 10:30:29] [job prefill-decode-0-0] Service replica registered to receive requests
[2026-08-05 10:44:45] [job prefill-decode-0-1] Service replica ready to receive requests
[2026-08-05 10:45:00] [job prefill-decode-0-2] Service replica ready to receive requests
[2026-08-05 11:15:22] [job prefill-decode-0-0] Service replica unregistered from receiving requests

#3959

jvstme added 2 commits August 5, 2026 18:32
**Problem**: Non-router replicas in a service with
a router should not be registered on the gateway.
To determine whether a particular replica should
be registered, one has to parse its job spec and
run spec and see if it is a router replica or not.
This does not work well for the upcoming gateway
state sync mechanism, which needs to quickly fetch
all jobs to be registered from the database,
without parsing their specs.

**Solution**:
- Do **not** set `JobModel.registered` for
  non-router replicas in services with a router.
  That way, `JobModel.registered` can be reliably
  used to identify the jobs that should be
  registered on the gateway, without parsing the
  job spec.
- Since the router worker sync pipeline needs both
  router and non-router replicas with successful
  probes, introduce `JobModel.ready`, set for any
  replica once probes pass.

```shell
$ dstack event --within-run prefill-decode | grep -E "ready|register"
[2026-08-05 10:30:29] [job prefill-decode-0-0] Service replica ready to receive requests
[2026-08-05 10:30:29] [job prefill-decode-0-0] Service replica registered to receive requests
[2026-08-05 10:44:45] [job prefill-decode-0-1] Service replica ready to receive requests
[2026-08-05 10:45:00] [job prefill-decode-0-2] Service replica ready to receive requests
[2026-08-05 11:15:22] [job prefill-decode-0-0] Service replica unregistered from receiving requests
```
@jvstme
jvstme requested review from Bihan and r4victor August 5, 2026 20:33
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant