fix(api): re-register api-grpc Consul service as alias of api-internal-grpc#2631
Conversation
…l-grpc #2470 renamed the API internal gRPC Consul service from api-grpc to api-internal-grpc. Old client-proxy allocations still have API_GRPC_ADDRESS=api-grpc.service.consul:<port> baked in and break when the old name disappears. Re-register api-grpc on the same internal port so legacy client proxies keep working during the migration. Remove once no pre-#2470 client-proxy allocations remain.
PR SummaryLow Risk Overview Reviewed by Cursor Bugbot for commit 0b2448e. Bugbot is set up for automated code reviews on this repo. Configure here. |
❌ 6 Tests Failed:
View the full list of 7 ❄️ flaky test(s)
To view more test analytics, go to the Test Analytics Dashboard |
There was a problem hiding this comment.
LGTM — straightforward backwards-compatibility Consul service alias with clear documentation for removal.
Extended reasoning...
Overview
This PR adds a single Consul service stanza to iac/modules/job-api/jobs/api.hcl re-registering the api-grpc name on the existing api_internal_grpc port. The block is well-commented with the rationale (legacy client-proxy allocations still hold API_GRPC_ADDRESS=api-grpc.service.consul:<port> bindings) and an explicit removal condition.
Security risks
None. This is a Nomad job spec change that re-exposes an existing internal port under an additional Consul service name on the same network surface; no new ports, credentials, or auth surfaces are introduced.
Level of scrutiny
Low. This is a config-only HCL change scoped to a single file, follows the exact pattern of the adjacent api-internal-grpc service stanza (same port, same TCP health-check shape), and is intentionally a temporary migration shim. The duplicate health check on the same port is a deliberate trade-off, not a bug — health-checking the same TCP endpoint twice every 3s is negligible cost.
Other factors
The Cursor bugbot flagged the duplicate service registration as a theoretical discovery-confusion concern, but that is precisely the point of the change (give legacy callers a working name during migration). Codecov reports clean. Author has stated the removal criterion explicitly in both the description and an inline comment, which is the right hygiene for this kind of transitional shim.
…l-grpc (#2631) #2470 renamed the API internal gRPC Consul service from api-grpc to api-internal-grpc. Old client-proxy allocations still have API_GRPC_ADDRESS=api-grpc.service.consul:<port> baked in and break when the old name disappears. Re-register api-grpc on the same internal port so legacy client proxies keep working during the migration. Remove once no pre-#2470 client-proxy allocations remain.
…l-grpc (e2b-dev#2631) e2b-dev#2470 renamed the API internal gRPC Consul service from api-grpc to api-internal-grpc. Old client-proxy allocations still have API_GRPC_ADDRESS=api-grpc.service.consul:<port> baked in and break when the old name disappears. Re-register api-grpc on the same internal port so legacy client proxies keep working during the migration. Remove once no pre-e2b-dev#2470 client-proxy allocations remain.
#2470 renamed the API internal gRPC Consul service from api-grpc to api-internal-grpc. Old client-proxy allocations still have API_GRPC_ADDRESS=api-grpc.service.consul: baked in and break when the old name disappears. Re-register api-grpc on the same internal port so legacy client proxies keep working during the migration. Remove once no pre-#2470 client-proxy allocations remain.