fix(FR-2774): query runtime variant id and decode to UUID for addModelRevision#7152
Merged
graphite-app[bot] merged 1 commit intoApr 30, 2026
Conversation
This was referenced Apr 29, 2026
Contributor
Author
This was referenced Apr 29, 2026
Contributor
Coverage report for
|
St.❔ |
Category | Percentage | Covered / Total |
|---|---|---|---|
| 🔴 | Statements | 8.12% (+0% 🔼) |
1859/22902 |
| 🔴 | Branches | 7.35% (-0% 🔻) |
1187/16156 |
| 🔴 | Functions | 4.83% (+0.02% 🔼) |
297/6153 |
| 🔴 | Lines | 7.89% (+0% 🔼) |
1750/22188 |
Test suite run success
865 tests passing in 40 suites.
Report generated by 🧪jest coverage report action from d033937
Contributor
There was a problem hiding this comment.
Pull request overview
Updates the deployment launcher flow to use the runtime variant’s GraphQL id (global ID) from the runtimeVariants query and decode it into the UUID required by the addModelRevision mutation.
Changes:
- Switched
runtimeVariantsquery selection fromrowIdtoid. - Decoded the runtime variant global ID to a local UUID when resolving
runtimeVariantIdforaddModelRevision. - Updated
DeploymentLauncherPageContentprop typing to reflect{ name, id }.
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.
| File | Description |
|---|---|
| react/src/pages/DeploymentLauncherPage.tsx | Queries runtimeVariants.node.id and decodes it to a UUID for modelRuntimeConfig.runtimeVariantId during submit. |
| react/src/components/DeploymentLauncherPageContent.tsx | Updates the runtimeVariants prop type from { name, rowId } to { name, id }. |
864d385 to
196024c
Compare
196024c to
f5f8814
Compare
This was referenced Apr 30, 2026
f5f8814 to
b6d3266
Compare
aafe474 to
2f19399
Compare
12 tasks
Merge activity
|
…lRevision (#7152) Resolves #7151 ([FR-2774](https://lablup.atlassian.net/browse/FR-2774)) ## Summary `addModelRevision` failed end-to-end after `createModelDeployment` succeeded, leaving the new deployment without a revision. Two related fixes that match the working pattern in `DeploymentAddRevisionModal.tsx` and `DeploymentRevisionHistoryTab.tsx`. ### 1. Runtime variant id resolution - `DeploymentLauncherPageRuntimeVariantsQuery` now selects `id` (Strawberry global) instead of `rowId`. In some live-server responses `rowId` returned null, tripping the frontend `Unknown runtime variant` guard at `DeploymentLauncherPage.tsx:314`. - `handleAddRevision` decodes the global id via `toLocalId` to derive the local UUID expected by `ModelRuntimeConfigInput.runtimeVariantId: UUID!`. Falls back to the raw `id` if `toLocalId` returns null, mirroring `DeploymentAddRevisionModal.tsx:204` (`toLocalId(node.id) ?? node.id`). - `DeploymentLauncherPageContent.runtimeVariants` prop type updated from `{ name; rowId }` to `{ name; id }`. ### 2. `deploymentId` / `id` fields → UUID, not Strawberry global ID `AddRevisionInput.deploymentId` and `UpdateDeploymentInput.id` are typed as `ID!` in `data/schema.graphql`, but the server resolvers expect the **local UUID**, not the Relay global ID. Working patterns in the same project: - `DeploymentAddRevisionModal.tsx:378`: `deploymentId: toLocalId(deploymentId) ?? deploymentId` - `DeploymentRevisionHistoryTab.tsx`: `id: toLocalId(deployment.id)`, `activeRevisionId: toLocalId(revision.id)` Previously the launcher wrapped both with `toGlobalId('ModelDeployment', ...)` before submitting, so the server rejected with `badly formed hexadecimal UUID string` after `createModelDeployment` succeeded. Now both `commitEdit` (`addModelRevision`) and `commitUpdateReplica` (`updateModelDeployment`) send the local UUID directly. The `deployment(id: $deploymentId)` query keeps `toGlobalId(...)` since Relay Node queries do require the global ID format. > The schema/runtime divergence (`ID!` typed but UUID expected) is a server-side documentation gap; flagging here so the next person doesn't reintroduce the wrap. ## Test plan - [x] `bash scripts/verify.sh` passes (Relay / Lint / Format / TypeScript). - [x] `/deployments/create`: filling the launcher and clicking **Create Deployment** completes without errors; the new deployment lands on `/deployments/:id` with the initial revision active. (User-verified in dev.) - [ ] `/deployments/:id/edit`: saving runs `addModelRevision` + `updateModelDeployment` in parallel and both succeed; new revision appears in history; replica count updates. [FR-2774]: https://lablup.atlassian.net/browse/FR-2774?atlOrigin=eyJpIjoiNWRkNTljNzYxNjVmNDY3MDlhMDU5Y2ZhYzA5YTRkZjUiLCJwIjoiZ2l0aHViLWNvbS1KU1cifQ
2f19399 to
ca553e6
Compare
b6d3266 to
d033937
Compare
graphite-app Bot
pushed a commit
that referenced
this pull request
Apr 30, 2026
…tialValues (#7153) Resolves #7150 ([FR-2773](https://lablup.atlassian.net/browse/FR-2773)) > Stacks on top of #7152 (FR-2774). ## Summary The Resource Preset row showed `-` on the deployment launcher review step even though the user had a preset selected on step 3. Fixed by extending the `applyInitialValues` omit list so any field whose child component owns an `autoSelectDefault` flow is left alone when its merged value is empty. ## Root cause 1. On mount, `ResourcePresetSelect`'s `autoSelectDefault` effect (a child) runs **before** the parent's `applyInitialValues` effect. 2. Auto-select sets `resourcePresetId` to the first available preset name. 3. `applyInitialValues` then runs and called `form.setFieldsValue(merged)` with `merged.resourcePresetId === undefined`, clobbering the auto-selected value. 4. `ResourcePresetSelect` uses `useControllableState_deprecated`, whose `stateRef` retains the auto-selected value when the antd-injected `value` is `undefined`. So the step-3 Select **kept displaying** the preset name (giving the user the impression it was selected), while `form.getFieldsValue()` returned `undefined`. 5. The review summary's `values.resourcePresetId ? <ResourcePresetReviewDisplay … /> : '-'` fell to the dash branch. The existing code already handled the same race for `resourceGroup` via `_.omit(merged, 'resourceGroup')`. This PR generalizes that omit list to also cover `resourcePresetId`. ## Test plan - [ ] `bash scripts/verify.sh` passes. - [ ] `/deployments/create`: select a resource group, allow auto-select to pick a preset on step 3, click Next → review step renders the preset name and resource slot icons (no `-`). - [ ] Manually change the resource preset on step 3 → review reflects the new preset. - [ ] Edit mode (`/deployments/:id/edit`): pre-filled preset still renders on review. - [ ] Edge: open `/deployments/create` directly (no URL pre-fill) and skip to review immediately → preset row shows the auto-selected preset, not `-`. [FR-2773]: https://lablup.atlassian.net/browse/FR-2773?atlOrigin=eyJpIjoiNWRkNTljNzYxNjVmNDY3MDlhMDU5Y2ZhYzA5YTRkZjUiLCJwIjoiZ2l0aHViLWNvbS1KU1cifQ
graphite-app Bot
pushed a commit
that referenced
this pull request
Apr 30, 2026
Resolves #7157 ([FR-2776](https://lablup.atlassian.net/browse/FR-2776)) > Stacks on top of #7153 (FR-2773) → #7152 (FR-2774). ## Symptom Relay compile errors after a schema sync: ``` ✖︎ Unknown argument 'options'. react/src/components/DeploymentAddRevisionModal.tsx:172:41 react/src/pages/DeploymentLauncherPage.tsx:259:41 ``` ## Schema change `addModelRevision` no longer takes `options` as a top-level mutation argument. The `AddRevisionOptions` payload is now a field on `AddRevisionInput`: ```graphql # Before addModelRevision(input: AddRevisionInput!, options: AddRevisionOptions): AddRevisionPayload! # After addModelRevision(input: AddRevisionInput!): AddRevisionPayload! # AddRevisionInput now has: options: AddRevisionOptions = null ``` ## Changes ### `react/src/pages/DeploymentLauncherPage.tsx` - `DeploymentLauncherPageEditMutation`: drop the `$options: AddRevisionOptions` variable and the `, options: $options` argument from the `addModelRevision` selection. - `handleAddRevision`: move `options: { autoActivate: true }` from `variables` (top level) into `variables.input`. ### `react/src/components/DeploymentAddRevisionModal.tsx` - `DeploymentAddRevisionModalAddMutation`: drop the inline `options: { autoActivate: true }` argument from the `addModelRevision` selection. - `commitAdd`: pass `options: { autoActivate: true }` inside the `input` payload. ### `data/schema.graphql` - Sync to the new server schema (drives Relay compiler against the latest definition). ## Test plan - [x] `pnpm run relay` compiles without errors. - [x] `bash scripts/verify.sh` passes (Relay / Lint / Format / TypeScript). - [ ] `/deployments/create`: create-then-add-revision flow still produces an active revision (auto-activated). - [ ] Standalone Add Revision modal: clicking "Add Revision" creates a new revision and auto-activates it. [FR-2776]: https://lablup.atlassian.net/browse/FR-2776?atlOrigin=eyJpIjoiNWRkNTljNzYxNjVmNDY3MDlhMDU5Y2ZhYzA5YTRkZjUiLCJwIjoiZ2l0aHViLWNvbS1KU1cifQ
Base automatically changed from
04-29-refactor_fr-2772_unify_deployment_card_ux_with_baicard_conventions
to
main
April 30, 2026 07:18
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
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.

Resolves #7151 (FR-2774)
Summary
addModelRevisionfailed end-to-end aftercreateModelDeploymentsucceeded, leaving the new deployment without a revision. Two related fixes that match the working pattern inDeploymentAddRevisionModal.tsxandDeploymentRevisionHistoryTab.tsx.1. Runtime variant id resolution
DeploymentLauncherPageRuntimeVariantsQuerynow selectsid(Strawberry global) instead ofrowId. In some live-server responsesrowIdreturned null, tripping the frontendUnknown runtime variantguard atDeploymentLauncherPage.tsx:314.handleAddRevisiondecodes the global id viatoLocalIdto derive the local UUID expected byModelRuntimeConfigInput.runtimeVariantId: UUID!. Falls back to the rawidiftoLocalIdreturns null, mirroringDeploymentAddRevisionModal.tsx:204(toLocalId(node.id) ?? node.id).DeploymentLauncherPageContent.runtimeVariantsprop type updated from{ name; rowId }to{ name; id }.2.
deploymentId/idfields → UUID, not Strawberry global IDAddRevisionInput.deploymentIdandUpdateDeploymentInput.idare typed asID!indata/schema.graphql, but the server resolvers expect the local UUID, not the Relay global ID. Working patterns in the same project:DeploymentAddRevisionModal.tsx:378:deploymentId: toLocalId(deploymentId) ?? deploymentIdDeploymentRevisionHistoryTab.tsx:id: toLocalId(deployment.id),activeRevisionId: toLocalId(revision.id)Previously the launcher wrapped both with
toGlobalId('ModelDeployment', ...)before submitting, so the server rejected withbadly formed hexadecimal UUID stringaftercreateModelDeploymentsucceeded. Now bothcommitEdit(addModelRevision) andcommitUpdateReplica(updateModelDeployment) send the local UUID directly. Thedeployment(id: $deploymentId)query keepstoGlobalId(...)since Relay Node queries do require the global ID format.Test plan
bash scripts/verify.shpasses (Relay / Lint / Format / TypeScript)./deployments/create: filling the launcher and clicking Create Deployment completes without errors; the new deployment lands on/deployments/:idwith the initial revision active. (User-verified in dev.)/deployments/:id/edit: saving runsaddModelRevision+updateModelDeploymentin parallel and both succeed; new revision appears in history; replica count updates.