Skip to content

fix(dashboard): honor extension update confirmation states - #5065

Merged
gabsprogrammer merged 1 commit into
Osmantic:public-betafrom
tang-vu:fix/beta-extension-update-confirmation-recovery-20260915
Sep 15, 2026
Merged

gabsprogrammer merged 1 commit into
Osmantic:public-betafrom
tang-vu:fix/beta-extension-update-confirmation-recovery-20260915

Conversation

@tang-vu

@tang-vu tang-vu commented Sep 14, 2026 •

Copy link
Copy Markdown
Contributor

Ready for independent review (2026-09-15). Candidate f8a0586be811217a46ef4034ed64bf6d9fd04033 has a successful GitHub check rollup and no base-branch conflict at this review snapshot. This supersedes earlier draft-status wording only. All validation gaps, migration requirements, live gates and independent human review requirements below remain in force; this is not a merge-ready approval.

Why this matters

An operator can load the extension catalog, modify an installed definition in the terminal, then click Update. The API correctly rejects the stale request with 409 locally_modified and force_available: true, but the UI only shows an error. Repeating the action keeps sending the same unconfirmed request. The API's unknown-inspection state is also unreachable from the UI because no new-release flag is set.

Expose library refresh for installed definitions with local modifications or unknown inspection state, even when no newer release is available. Show the overwrite and rollback warning before sending force=true. When the API detects a newer unknown/modified/untracked state than the catalog, reopen confirmation with that specific reason. The first response never triggers an automatic forced retry.

Overlap check

Searched open and closed PRs for extension unknown update force, extension modified refresh, and update confirmation 409; checked changes to Extensions.jsx in the historical and latest PR file indexes. #1906 introduced these backend confirmation states. Inspected #2903's lifecycle-plan patch: it retains the old force predicate and does not handle these update conflicts. #4468 adds an Assistant First plan interface; #4982 displays installation credentials. This fixes the existing library update UI contract without adding either independent feature.

Validation

  • Regression suite covers direct unknown/modified refresh, cancel without mutation, explicit forced confirmation, all three server conflict codes, duplicate clicks while pending, and refusal to escalate an unrelated conflict, a missing permission flag, or an HTTP 403. Before the fix: 5 failed, 1 passed. Final suite: 8 passed.
  • npm test -- --maxWorkers=4: 1,077 passed across 135 files.
  • npm run lint, npm run build, scoped pre-commit hooks, git diff --check: passed.
  • Existing API update suite: 23 passed, including unknown-state and local-modification guards.
  • make gate reproduces the beta baseline's two no-sudo Docker contract failures; this is not represented as a fully green local gate.

Lifecycle and review

The existing backend remains responsible for authentication, current-state inspection, operation locks, the forced update transaction and rollback. Each overwrite requires a concrete confirmation dialog; mutation closes that dialog and disables other extension actions until the request settles. Only the three recognized update conflict codes with force_available: true and HTTP 409 can reopen confirmation. Errors from an already-forced request remain terminal errors. Success refreshes the catalog; reloading the page discards any unfinished confirmation and reads current state.

Targets public-beta, independently based on d49ad4bbc760be319de7f4c9b9a93b1f18fe3922. Revert restores the old UI and does not alter installed definitions or data. Awaiting independent review and a live host-agent update check. DOM tests prove confirmation behavior, not host filesystem permissions or Docker readiness. Exact-head CI and combined batch integration receipts will be added.

Exact-head CI at f8a0586: 32 successful checks and 4 conditional skips; no pending or failed checks. Independent review and live validation remain deferred as described above.

Final combined receipt and review status

Ready for review at the 2026-09-15T08:28:06.7269998+00:00 snapshot; the candidate remains f8a0586be811217a46ef4034ed64bf6d9fd04033. GitHub: 34 successful checks, 8 conditional skips, none failed or pending.

The versioned 40-PR compatibility receipt records every candidate SHA, merge order, shared-file resolutions, pairwise comparisons and remaining gates. All 40 candidates are ancestors of tested integration a72e15781e4f41c3bd81f3b7f27f5b0fc5503a63: 2,997 API tests passed (3 skipped), 1,134 UI tests passed, 247 changed root contract tests passed (28 opt-in skips), and all four smoke paths passed. The full Makefile audit passed 84/87 suites; the three failures reproduce on the unchanged base. Simulation correction: the wrapper exits 0 but its artifact records 3/4 golden paths passed; Linux NVIDIA stops at the root-user guard, reproduced on the unchanged base. This supersedes any earlier simulation-pass wording. BATS and all-file private-key baseline failures are also documented, so a fully green local gate is not claimed.

The receipt supersedes provisional batch-validation wording above, while preserving the candidate-specific tests and their stated limitations. Integration results do not substitute for unexecuted native platform, hardware, browser, upgrade or host-agent lifecycle probes. Ready status permits review; independent human review and every declared live/operational gate still apply. No upstream merge or deployment has been performed.

@tang-vu
tang-vu marked this pull request as ready for review September 15, 2026 01:30
@gabsprogrammer
gabsprogrammer merged commit 8bcf54d into Osmantic:public-beta Sep 15, 2026
42 checks passed
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.

2 participants