fix(BA-5963): resolve current_revision_id by explicit match, not list[0]#11494
Draft
jopemachine wants to merge 3 commits intomainfrom
Draft
fix(BA-5963): resolve current_revision_id by explicit match, not list[0]#11494jopemachine wants to merge 3 commits intomainfrom
current_revision_id by explicit match, not list[0]#11494jopemachine wants to merge 3 commits intomainfrom
Conversation
`_convert_deployment_info_to_data` picked `info.model_revisions[0]` as the current revision. During a rolling update the list contains both current and deploying revisions, and PostgreSQL returned them in undefined order because `EndpointRow.revisions` had no `order_by`, so `current_revision_id` in REST/GraphQL responses could be reported as the deploying revision id — or as null when downstream adapters derived it from `data.revision.id`. Match the spec by `info.current_revision_id` directly, and add `order_by` on the `revisions` relationship for deterministic iteration in any other caller. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
github-actions
Bot
added
size:S
Stop deriving the API's `current_revision_id` from `data.revision.id`, which fell through to `null` whenever the matching `ModelRevisionSpec` could not be resolved (e.g. dangling `endpoints.current_revision` pointing at a removed `deployment_revisions` row — a real path observed in the field after replica/revision cleanup). Carry the column value through the data layer: `ModelDeploymentData` now has its own `current_revision_id`, populated from `info.current_revision_id` in the service layer, and the GraphQL/REST v2 adapter reads it directly. Identity is now decoupled from the spec, so the API mirrors the DB column even when the spec lookup fails. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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.
Summary
_convert_deployment_info_to_datapickedinfo.model_revisions[0]as the current revision spec. During a rolling update the list also contains the deploying revision, and PostgreSQL returned them in undefined order, so the API could expose the deploying revision id undercurrent_revision_id(ornullwhen downstream adapters derived the id fromdata.revision.id).info.current_revision_iddirectly inservices/deployment/service.py; addorder_by="DeploymentRevisionRow.revision_number"onEndpointRow.revisionsfor deterministic iteration in any other caller.current_revision_idthrough the data layer (ModelDeploymentData.current_revision_id) and read it from there in the GraphQL/REST v2 adapter, instead of recomputing it fromdata.revision.id. This stops the API from collapsing tonullwhen the matchingModelRevisionSpeccan't be resolved (e.g. danglingendpoints.current_revisionafter a revision row was removed) — the column value now flows straight through.Resolves BA-5963.