diff --git a/csaxs_bec/bec_ipython_client/plugins/flomni/AI_docs/TOMO_QUEUE_COMMAND_JOBS_PLAN.md b/csaxs_bec/bec_ipython_client/plugins/flomni/AI_docs/TOMO_QUEUE_COMMAND_JOBS_PLAN.md index 5bf05a8..a8ebbef 100644 --- a/csaxs_bec/bec_ipython_client/plugins/flomni/AI_docs/TOMO_QUEUE_COMMAND_JOBS_PLAN.md +++ b/csaxs_bec/bec_ipython_client/plugins/flomni/AI_docs/TOMO_QUEUE_COMMAND_JOBS_PLAN.md @@ -505,6 +505,22 @@ a pure regression. A later pass added `TomoParamsWidget.add_edited_to_queue()` ( dict from the current form fields — exactly per this section's "must assemble the job dict itself" rule — and only then did `submit_params()` become the intended hard block. +**The same live-vs-unsaved-edit confusion has two doors, not one.** Found at the +beamline: `TomoQueueDialog.add_to_queue()` (the "Add current params to queue" button +in the *separate* ☰ Queue control… window) *also* reads live vars via +`self._load_params()`, same as `tomo_queue_add()` always did — it was never updated to +know the params panel might have an unsubmitted edit open. An operator who edits a +value, doesn't click the panel's own "Add to queue", and instead reaches for the queue +window's button gets the stale pre-edit values queued with no indication anything's +off — the exact trap this section's "must assemble the job dict itself" rule was +written to avoid, just reachable from a second window that rule didn't originally +cover. Fixed with a warning (not a block, unlike Submit): `TomoQueueDialog.add_to_queue()` +now checks `self.parent()._edit_mode` and, if set, confirms before proceeding, naming +the panel's own "Add to queue" as the correct button. A warning rather than a hard +block because queuing the live params while an unrelated edit happens to be open +elsewhere is still legitimate — unlike Submit's case, there's no live-scan-perturbation +risk here, just a wording/expectation mismatch worth flagging rather than forbidding. + ### 6.2 No in-place row editing Editing a queued job = **delete it, add a new one, reorder into place**. One diff --git a/csaxs_bec/bec_ipython_client/plugins/flomni/AI_docs/TOMO_QUEUE_GUI_TESTING.md b/csaxs_bec/bec_ipython_client/plugins/flomni/AI_docs/TOMO_QUEUE_GUI_TESTING.md index 998d697..fd793e1 100644 --- a/csaxs_bec/bec_ipython_client/plugins/flomni/AI_docs/TOMO_QUEUE_GUI_TESTING.md +++ b/csaxs_bec/bec_ipython_client/plugins/flomni/AI_docs/TOMO_QUEUE_GUI_TESTING.md @@ -12,11 +12,11 @@ gaps (all fixed, see section 6c below): a confusing duplicate row-number column, `tomo_parameters()`/the queue table/scilog/the PDF report/the progress-ring label not showing an active hook at all, and a clarification that `unregister_at_each_angle_hook()` doesn't clear `at_each_angle_hook` -(confirmed expected, now documented). **Sections 6c, 6d, and 6e are new and -not yet clicked through** — 6c is the fixes above, 6d is the new "Load into -editor" feature (reuse a queued job's settings as a new edit), 6e is a -declined-scan/stuck-queue incident found live at the beamline and its fix -(CLI-side sim-verified; the GUI delete/clear override itself is not). +(confirmed expected, now documented). **Sections 6c, 6d, and 6e have now also +been clicked through and pass** (37–52), including the stale-`running` +delete override, which fixed an actual stuck job found live at session +start. **Section 6f is new and not yet clicked through** — a warning added +after 6e's testing surfaced one more mixed-surface confusion (see below). Companion docs: `TOMO_QUEUE_COMMAND_JOBS_PLAN.md` section 6 (the design this implements), `TOMO_QUEUE_TESTING.md` (Steps 1 & 2, already sim-validated). @@ -141,8 +141,16 @@ support on top of it: stuck at `running` with no live process. And delete/clear on a `running` row now check `tomo_progress`'s heartbeat: stale or missing offers a "proceed anyway?" override instead of refusing forever; a - fresh heartbeat still blocks outright. See section 6e below — not yet - click-tested. + fresh heartbeat still blocks outright. Click-tested (section 6e) and + passing — the staleness override fixed an actual stuck job found live. +13. **Warn before "Add current params to queue" mid-edit.** That button + (in the ☰ Queue control… window) reads live global vars, not the + params panel's in-progress edit -- a second place the same + live-vs-unsaved-edit confusion as item 8 could bite, since it's a + different window from the panel's own (correct) "Add to queue" + button. Now warns and names the correct button before proceeding if + the panel is mid-edit; no warning if it isn't. See section 6f below — + not yet click-tested. --- @@ -451,6 +459,25 @@ forever with the GUI unable to delete it. status guard there at all) — useful as a fallback even without the GUI open. +## 6f. Test plan — new: warn before "Add current params to queue" mid-edit + +Found during 6e testing — a second confusion between the two "add to queue" +buttons living on two different windows. + +53. Click **Edit** in the params panel, change a value, but do **not** + click Submit or the panel's own "Add to queue" yet. Open **☰ Queue + control…** and click **"Add current params to queue"** (the button in + that window, not the panel). Confirm a warning dialog appears naming + the live-vs-unsaved-edit mismatch and pointing at the panel's own "Add + to queue" button, before anything is queued. +54. From that dialog, click **Cancel** — confirm nothing was added to the + queue. Click the button again and this time confirm **Yes** — confirm + it queues the **live** (pre-edit) values, not your in-progress edit, + exactly as the warning said it would. +55. With the params panel **not** in edit mode, click "Add current params + to queue" — confirm it queues normally with **no** warning (only + fires when an edit is actually in progress). + ## 7. Known limitations of this first iteration (by design, not bugs) Worth knowing before you file something as broken: diff --git a/docs/user/ptychography/flomni.md b/docs/user/ptychography/flomni.md index 7d89934..948e41f 100644 --- a/docs/user/ptychography/flomni.md +++ b/docs/user/ptychography/flomni.md @@ -367,6 +367,14 @@ as if you'd just clicked Edit. Nothing is written yet — review or tweak the fi then Submit (writes live, blocked while the beamline is busy) or "Add to queue" (always allowed) as usual. If you already had an edit in progress, it asks before discarding it. +**GUI: two different "Add to queue" buttons.** The params panel's own **"Add to +queue"** (visible in edit mode) queues whatever you've typed, unsubmitted. The ☰ +Queue control… window's **"Add current params to queue"** is a different button on a +different window — it always queues the *live* parameters, regardless of any edit +open in the panel. If you have an unsaved edit open and click the queue window's +button instead of the panel's, it warns and names the correct one before proceeding, +since it would otherwise queue your last-submitted values, not what you just typed. + #### Command jobs — reconfiguring the beamline between scans In addition to tomogram jobs, the same queue can hold **command jobs**: an ordered