Repository navigation
P0 Studio: cancel queued SV START with bounded priority STOP and block bare START - #250
Conversation
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: eb7448b23e
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| tone: bar.workflow.injectionRunning ? "danger" : "neutral" | ||
| iconSource: Qt.resolvedUrl("../assets/material/stop.svg") | ||
| enabled: (bar.workflow.injectionRunning || bar.controller.offlinePreviewRunning) | ||
| enabled: (bar.workflow.injectionRunning || bar.workflow.startQueued || bar.controller.offlinePreviewRunning) |
There was a problem hiding this comment.
During the pending-START interval, this enables cancellation only through the ribbon button, while the F6 shortcut in Main.qml:658 remains enabled only when the session state is already RUNNING. An operator pressing F6 while startQueued is true therefore gets no action, allowing the queued START to proceed despite the stop intent; gate the shortcut on workflowBar.startQueued as well.
Useful? React with 👍 / 👎.
1 participant
P0 guardrail — queued SV START cancellation (precedes acknowledged scenario transaction)
Base: PR #247 at
f3e445616e9e7d8ba10e787ba4248a1a0396e557(stacked on #246/#234). Do not target or merge tomain.Root cause
The primary Studio START uses an all-or-none serial queue batch rather than firmware ACK. A second stale entry point
requestStart()could bypass the current 4I+4V snapshot, whilerequestStop()returned success without sending STOP before RUNNING telemetry arrived. The Stop ribbon button was disabled during queued START, and only PTP STOP had a reserved full-queue safety slot.Focused changes
DeviceController::startand supervisorrequestStart; requirerequestStartWithScenariofor operator intent.SCENARIO START) without relaxing bounded queue/ordering.Invariants / test contract
No ISR, PTP servo, MAC hardware timestamp gate,
smpSynch, SV codec, shape math, signal scales or automatic firmware flash changed. Shutdown still sends SV STOP before PTP STOP. Both emergency stop slots are bounded. Worker transport-write acceptance is not firmware ACK.Explicitly NOT solved by this PR
The
FREQ/SET/ENABLE/SHAPEcommands still update firmware incrementally and the existing START batch is not firmware-atomic. A new typedscenario -> staging -> validated COMMIT -> generation/hash ACK -> readback -> gated STARTintegration PR is P0-A and remains mandatory before hardware acceptance. This PR does not establish GUI-to-PCAP equality, physical STOP delivery or PTP <10s lock. Physical ESP32-P4 cancellation and PCAP must be tested, and exact-SHA CI runs must be checked.Acceptance / rollback
Build Studio Qt + Windows Lifecycle + Native Preview from exact HEAD, run
arstack_session_harness, then independently test STOP during queued START with serial + PCAP on isolated lab Ethernet. Roll back to #247 SHAf3e44561if regression. Leave in draft until review/CI/field proof.