fix(gsd): show dispatched model in widget after hook override#3418
fix(gsd): show dispatched model in widget after hook override#3418atikin19sh wants to merge 2 commits intogsd-build:mainfrom
Conversation
🔴 PR Risk Report — CRITICAL
Affected Systems
File Breakdown
|
|
Re-ran verification on this branch with a full unit sweep. ✅ Relevant checks for this PR
ℹ️ Full suite status
The 12 failures are outside the scope of this PR and are in unrelated areas:
No failures were observed in the GSD auto-loop/model-routing/widget code path changed here. |
Solvely-Colin
left a comment
There was a problem hiding this comment.
Blocking: this can make the progress widget show a model the unit is not actually running on. We now prefer \currentUnitModelfor display, but inrunUnit()we still fall back to the session default if restoring that model afternewSession()fails. In that failure path,currentUnitModelis never cleared, so the widget can keep showing the override/selected model even though execution continued on the default session model. Can we either clearcurrentUnitModelon restore failure or fall back tocmdCtx.model` after session creation? I’d also like a behavioral test for that path, since the current test only checks source ordering and wouldn’t catch this regression.
When pi.setModel returns false after newSession(), the unit continues on the session default model but currentUnitModel was left pointing at the override/selected model. This caused the progress widget to display a model the unit was not actually running on. Fix: null currentUnitModel in the restore-failed branch so the widget falls back to cmdCtx.model (the actual session model). Add behavioral regression test: verifies currentUnitModel is null after a failed restore, which the prior source-ordering assertion did not cover. Closes gsd-build#3418
|
Friendly nudge — this PR has outstanding change requests that haven't been addressed yet. Please update when you get a chance so review can continue. 🤖 Automated PR audit — 2026-04-04 |
Summary
currentUnitModel(the actually dispatched unit model) with fallback tocmdCtx.modelupdateProgressWidgetcall to after hook model override handling inrunUnitPhasecurrentUnitModelat unit start to avoid stale carry-over on early failuresWhy
When a hook-level model override is applied, the widget could still show the pre-override model because the widget was created earlier in the phase. This makes model observability misleading.
Verification
npm run typecheck:extensionsnpm run test:compilenode --import ./scripts/dist-test-resolve.mjs --test dist-test/src/resources/extensions/gsd/tests/auto-loop.test.js