Skip to main content

ListProjectGatewayMembers

GET 
/admin/v1/customers/:customer_id/projects/:project_id/gateway-members

List a project's member gateways with their membership state (D1 multi-gateway projects, fraser#5987 / ADR 052).

This is the fleet-consistency primitive (epic tetrate-ai-platform#2865, gate amendment 6): for every member it reports the membership state machine position (syncing / ready / detached_zeroized / detached_unreachable), the member's last-acked config version vs. the project's head config version for that member, health (tri-state: unknown is a valid answer), last-seen, and the state timestamps. The shape is deliberately reusable by future consumers (D3 T1 steering, fleet-upgrade tooling): "is this fleet converged on config head?" is answerable per member from status + config_version + head_config_version alone.

A member is advertised as ready ONLY under confirmed convergence: every per-gateway config slot acked by the data plane at its current version, PLUS the member workspace's shared PROXY (authz-map) slot when one exists (an absent workspace slot passes vacuously — the slot is minted on first authz-map generation). Because that PROXY slot is shared by every gateway in the workspace, a bump to it flips ALL of the workspace's members back to syncing until the new map version is acked — cross-member flap on workspace-slot bumps is expected behavior, not a defect. A previously-ready member whose project config moved ahead reports syncing again until the new head is acked. The config_version / head_config_version columns stay scoped to the member's own per-gateway slots (gateway family only): the workspace PROXY slot participates in the READY predicate but never in the version columns.

Although marked NO_SIDE_EFFECTS, this read performs idempotent ledger reconciliation: attachments that predate the membership ledger are backfilled insert-only (a detached record is never reset by a list; only the Attach RPC does that). A legacy attachment backfilled this way gets a fabricated attached_at equal to the first list's server time — its true attach time was never recorded.

A project with ZERO member gateways is fully valid: the response carries an empty members list (and whatever detached history exists), never an error.

Responses carry NO credential material (gate amendment 5): identity, state, versions, and timestamps only.

Enterprise only: on SaaS deployments (DEPLOYMENT_PRODUCT=saas) this RPC fails with UNIMPLEMENTED — the multi-gateway surface does not exist there (the existing attach/detach RPCs remain, capped at one gateway per project).

Request​

Responses​

Success