Feat/flomni queue with commands #259

Merged

holler merged 51 commits from feat/flomni_queue_with_commands into main 2026-07-14 15:48:39 +02:00

Conversation 0 Commits 51 Files Changed 28

+6046 -117

holler commented 2026-07-14 15:45:02 +02:00

Member

Copy Link

Copy Source

No description provided.

holler added 51 commits 2026-07-14 15:45:02 +02:00

first iteration afb81f247c

refactor(flomni): rename _TOMO_QUEUE_PARAM_NAMES to _TOMO_SCAN_PARAM_NAMES ... cf44d09a12

The constant lists live scan properties snapshotted/restored by the tomo
queue, not queue state itself -- the old name was misleading. Confirmed
with Mirko. Updates the matching comment in tomo_params.py, which mirrors
this tuple as QUEUE_PARAM_NAMES (unchanged name, own mirror constant).

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

test(flomni): add tomo-queue e2e harness against the simulated flOMNI ... ff50711dc9

Sections A-C of TOMO_QUEUE_TESTING.md's checklist, run against a live sim
session: params-restored-per-job, legacy queue migration, empty/all-done
no-ops, start_index semantics, exception/SIGKILL crash-resume, resume-
before-fresh ordering, and concurrent queue edits from a second client.
All 10 tests pass together with no cross-test interference.

The flomni_sim fixture and _bootstrap.py factor out what it takes to
construct a live Flomni against the sim (builtins/reload bootstrap,
side-effect neutralization, RT-feedback/fsamx setup) for reuse by both
in-process tests and the SIGKILL-based subprocess tests.

Also adds the AI_docs/ handoff docs (testing checklist results, command-
jobs plan with the action-registry decisions) that this work updated.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

feat(flomni): add command jobs to the tomo queue ... 30b5119a2f

Type-tags queue jobs with a "kind" field (back-compat: missing kind
defaults to "tomo"), and adds "command" jobs that reconfigure the
beamline (currently: absolute moves on an allow-listed device, plus an
optimize_idgap stub) between tomograms instead of running a scan.

Command jobs are added via tomo_queue_add_command() against a curated
named-action registry (_TOMO_QUEUE_ACTIONS) - not arbitrary code - so
every queued action is auditable and safe to persist across a kernel
restart. Validation is two-layer: schema checks at add time, and each
action re-checks its own arguments against live hardware at execution
time, which is the actual safety boundary. Crash-resume for a command
job re-runs the whole step sequence from the top if every step is
idempotent, or prompts the operator otherwise.

flomni_webpage_generator.py is guarded against command jobs, which
have no "params" key.

See AI_docs/TOMO_QUEUE_COMMAND_JOBS_PLAN.md for the full design.

test(flomni): add e2e coverage for tomo-queue command jobs ... bfe60ecd36

Covers add-time validation (unknown action, disallowed device,
out-of-range/wrong-type params, unknown kwarg - each rejected without
landing in the queue), the execution-time allow-list re-check as the
real safety boundary, the tomo_queue_actions global var matching the
live registry, tomo_queue_show()/the webpage generator surviving a
command job, legacy kind-less jobs still running as tomograms
alongside a real command-job device move, and the non-idempotent
resume prompt (distinct from the executor's own start-confirmation
prompt).

Also fixes flomni_sim: it only snapshotted/restored whatever was
already in the tomo_queue/tomo_progress global vars, so a stale entry
left behind by an earlier crashed run or manual debugging session
against the same shared sim Redis would contaminate every test that
assumed it started from an empty queue. Now resets both to empty at
setup, in addition to snapshotting/restoring around the test.

docs(flomni): reflect shipped command jobs and the e2e folder move ... 4f256595d9

TOMO_QUEUE_COMMAND_JOBS_PLAN.md and TOMO_QUEUE_TESTING.md were written
while command jobs (Step 2) were still in progress; update both now
that it's implemented and sim-tested (16/16 e2e tests passing,
including the 6 new command-job ones - see TOMO_QUEUE_TESTING.md
section 4D for what each covers), and record the Redis test-state
contamination gotcha found while testing it.

Also fixes the harness-script path references in SIMULATED_ENDSTATIONS.md
and the two scripts' own docstrings, stale after tests/e2e and
tests/sim_*_harness.py moved to omny_e2e_tests/ (in the previous
commit) - kept out of tests/ specifically so gitea's CI, which runs
pytest against ./csaxs_bec/tests/ unconditionally, doesn't sweep up
tests that need a live sim + Redis.

docs(flomni): document tomo-queue command jobs for operators ... e6f427d0fb

Adds a "Command jobs" reference section covering
tomo_queue_add_command(), the move/optimize_idgap action registry, the
mokev/idgap device allow-list, tomo_queue_show() output format, and
the idempotent-vs-prompt crash-resume behaviour, plus a pointer to it
from the quick-start queueing section.

docs(flomni): add plugin-agnostic e2e testing guide ... 78f4757c80

Generalizes the patterns and gotchas learned building the flOMNI
tomo-queue e2e suite (main-thread-only live-update machinery, the
builtins/reload import-order bootstrap, neutralizing real side
effects, the demo-config trap in pytest_bec_e2e's shipped fixtures,
the omny_e2e_tests/ folder convention, and the Redis
cross-test-contamination fixture bug) into a standalone reference for
adding e2e coverage to any plugin in this repo, not just flomni.

Intended to be added to a Claude Project alongside this repo so a
coding assistant finds it and follows these patterns instead of
re-deriving them from scratch.

feat(bec_widgets): add command-job builder to the tomo queue GUI ... 3887a5ffbc

First iteration of Step 3 (TOMO_QUEUE_COMMAND_JOBS_PLAN.md section 6)
on top of the existing TomoParamsWidget/TomoQueueDialog baseline:

- CommandJobBuilderDialog: a structured step-by-step form (action
  dropdown, per-action fields) built entirely from the live
  tomo_queue_actions global var, so it tracks flomni.py's action
  registry and device allow-list with no hardcoded mirror. Produces a
  job dict identical to what tomo_queue_add_command() writes.
- TomoQueueDialog's queue table gained a "Details" column and renders
  command jobs (CMD + step summary + idempotency marker) the same way
  flomni.tomo_queue_show() does.
- "Add current params to queue" now stamps kind="tomo" and a fresh id
  on the job, matching the CLI's own self-describing format.
- Delete/clear now refuse when a "running" job is involved instead of
  silently allowing it (plan section 6.3).

Mid-run drag-reorder of queue jobs (plan section 6.4), multi-device
single move steps, and live device-limit validation are deliberately
not in this iteration - see TOMO_QUEUE_GUI_TESTING.md.

docs(flomni): add GUI test checklist and session-handoff instructions ... 458e5a06b2

TOMO_QUEUE_GUI_TESTING.md is the manual verification plan for the new
command-job builder: baseline regression checks, the builder itself,
the status-keyed delete/clear guards, and an end-to-end mixed-queue
run, plus this iteration's known gaps (no mid-run reorder, one device
per move step, no live limit validation). Nobody has clicked through
the actual widget against a live session yet - it's built and
smoke-tested at the logic level only, not GUI-validated.

Section 8 covers continuing this work after leaving the current coding
session: a Claude Project with AI_docs/ attached as project knowledge
is for planning/discussion, a Claude Code session attached to this
repo is what's actually needed to keep editing tomo_params.py - and a
ready-to-paste prompt for starting that next session.

Also updates TOMO_QUEUE_COMMAND_JOBS_PLAN.md's status line: Step 3 has
a first iteration built, not the "not started" it said before.

feat(flomni): add tomo_queue_move for reordering pending/incomplete jobs ... 2755f54073

Lets a queued job be moved to a new position via the CLI, refusing to
touch a running/done job and refusing any move that would displace the
currently running job (a hard floor, per the mid-run-reorder design in
AI_docs/TOMO_QUEUE_COMMAND_JOBS_PLAN.md section 6.4).

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

feat(bec_widgets): sort-mode reorder buttons and row tooltips in TomoQueueDialog ... c49d7afb55

Adds a checkable "Sort queue..." mode: other queue-mutating buttons
disable, the table goes single-select, and Move up/down swap the
selected row with an adjacent one -- but only between two
pending/incomplete rows, so a running or done neighbour blocks the
swap (gets the running-job floor and done-row pinning from
TOMO_QUEUE_COMMAND_JOBS_PLAN.md sections 6.3/6.4 without drag-and-drop
math). Also gives every row a full-detail tooltip (label, status,
steps/params, added-at) so hovering surfaces what the Label/Details
columns truncate at typical dialog widths.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

docs(flomni): document queue reordering and row tooltips ... d184064a9f

Updates the command-jobs plan (status line, section 6.4's
implementation note, new section 6.7, commit breakdown) and the GUI
test checklist (section 1's what-was-built list, a new section 6a
with test steps 19-26, and the corrected known-limitations entry) to
reflect tomo_queue_move and the sort-mode/tooltip GUI work. Neither
has been validated against a live session yet.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

feat(flomni): serve a local-only status page on account mismatch ... ea91f95867

Previously start() did nothing at all when the BEC account didn't
match the system user (e.g. a dev/sim session run under a different
account) -- now it starts a status page on a separate fallback port
(default 8081) for local debugging, while still skipping everything
that assumes the active account is the "real" one for this host: the
cross-session singleton lock, remote upload, and session.htpasswd
changes. Not yet tested against a live/sim session.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

fix(bec_widgets): give Label/Details room and drop Added-at column in queue table ... e4f2b1c2db

All 9 columns previously shared equal Stretch width, squeezing the two
free-text columns (Label, command-step Details) down to the same width
as short fixed-content ones like Type or Exp (s). Short columns now
auto-fit their content; Label and Details stretch to fill what's left
and left-align instead of centering. Also drops the Added-at column --
that value is still available via the row tooltip added earlier.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

docs(flomni): document queue table column sizing change ... d650944855

Updates plan section 6.7 and the GUI test checklist (section 1 item 7,
new test step 27) for the Label/Details stretch columns and the
dropped Added-at column.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

fix(flomni): don't let a disabled scilog crash a tomo scan or pause the queue ... 90a2d4a69c

tomo_scan() called bec.messaging.scilog directly with no guard, so a
session without scilog enabled raised RuntimeError from inside
tomo_queue_execute() -- marking the job "incomplete" and pausing the
whole queue over a logging side effect unrelated to whether the
tomogram succeeded. Adds _scilog_write(), mirroring the enabled-check
already used for the PDF report entry, and routes the three unguarded
call sites (tomo_scan, scilog_last_ptycho_scans, the alignment-scan
entry) through it.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

feat(bec_widgets): add "Add to queue" in edit mode, hard-block Submit while busy ... cf38a9a691

Previously the only way to queue a new tomo parameter set was to
Submit it live first (writing the running scan's global vars) or use
the separate queue dialog's "Add current params to queue", which
snapshots the live vars and silently ignores any unsubmitted edit --
so there was no way to prepare a new parameter set in the GUI while a
scan was running without perturbing it.

Edit mode now shows an "Add to queue" button that packages the
current (possibly unsubmitted) form fields as a new pending tomo job,
writing only tomo_queue -- never the live param vars -- so it's always
allowed. Submit becomes a real hard block while the beamline is busy
instead of a Yes/Cancel confirmation, now that there's somewhere else
to put an in-progress edit (TOMO_QUEUE_COMMAND_JOBS_PLAN.md section
6.1's two-write-paths rule, finally enforced as written).

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

docs(flomni): document edit-mode queue-add, hard Submit block, and scilog fix ... 7f7106c944

Updates plan section 6.1 (marks the two-write-paths rule as actually
implemented now) and the GUI test checklist (section 1 item 8, and
flags section 3 item 4 as needing re-testing since its old passing
result was against the since-replaced soft-warn Submit behaviour).

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

fix(flomni): don't crash feye_out() when fttrx1 isn't in the config ... b3330e6bce

feye_out() unconditionally moved dev.fttrx1 out of the way, raising
an unhandled DeviceConfigError on any session (e.g. sim) where that
device isn't configured, after already having closed the shutter and
moved other optics. Now checks "fttrx1" in dev first (same pattern
already used for rtx elsewhere in this file) and, if absent, asks via
OMNYTools.yesno() whether to continue without moving it instead of
crashing.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

fix(flomni,bec_widgets): treat incomplete jobs as a reorder floor, like running ... b8a567a9f8

Sort mode and tomo_queue_move() let a pending job be dragged/moved
visually ahead of an incomplete one. Harmless to actual run order --
tomo_queue_execute()'s pick-next loop always resumes the first
running/incomplete job it finds regardless of list position -- but
confusing to read, since list order looked like run order and wasn't.
Narrows the GUI's _MOVABLE_STATUSES to ("pending",) and the CLI's
floor check to the highest index among all running/incomplete jobs,
not just the running one. Found while testing the reorder feature
against a real interrupted scan.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

docs(flomni): document the incomplete-job reorder floor fix ... 9a83a44674

Updates plan section 6.4 and the GUI test checklist (item 5, new test
step 23a) for narrowing sort-mode/tomo_queue_move() reordering to
pending-only, with running and incomplete both acting as a floor.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

info files added from claude 129ad05119

add md describing webpage design 2a8959b3f7

feat(flomni): add curated at_each_angle hook registry for tomo-queue jobs ... 01e184507a

Flomni._at_each_angle() already had an escape hatch for custom
per-projection behaviour (a flomni_at_each_angle function checked via
builtins), but it's invisible to the tomo queue -- not a snapshotted
parameter, so a queued job had no way to select it. Adds a
session-only registry (register_at_each_angle_hook/unregister/list)
populated from the IPython session, plus a new snapshotted
at_each_angle_hook parameter so a tomo-queue job can carry its own
hook selection through add/execute/resume like any other tomo param.
Curated means the queue only ever stores a hook *name*, never code --
_at_each_angle() raises a clear error rather than silently falling
back to default behaviour if a job's named hook isn't registered in
the session running the queue (hooks don't survive a kernel restart).

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

fix(bec_widgets): include at_each_angle_hook in the GUI's param snapshot ... 40a3b78afe

TomoParamsWidget/TomoQueueDialog mirror flomni.py's snapshotted-param
list by hand (QUEUE_PARAM_NAMES/DEFAULTS) and it hadn't picked up the
new at_each_angle_hook parameter. Left as-is, a GUI-added job's params
dict would have no at_each_angle_hook key at all, so the executor's
per-job setattr loop would never touch it -- silently leaving whatever
hook the *previous* queued job had active in place for a job that
never asked for one. Adds the key to QUEUE_PARAM_NAMES/DEFAULTS (fixes
"Add current params to queue", which reads live global vars) and has
add_edited_to_queue() explicitly pass the live value through (there's
no editable widget for it yet, so it can't come from the form fields).

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

docs(flomni): document at_each_angle hooks in the user manual and AI_docs ... 48647bf0d9

Adds a "Custom behavior at each projection angle" subsection to the
Tomography section of the flOMNI user manual (docs/user/ptychography/flomni.md):
what a hook function looks like, a polarizer-modulation example, and
how to register/activate/deactivate/list/unregister one, with an
explicit warning about resetting at_each_angle_hook before queuing a
normal follow-up job. Also links it from the quick-start queueing
section. AI_docs/TOMO_QUEUE_COMMAND_JOBS_PLAN.md gets a new section
3.4 recording the design decision (session-only registry, not a
hardcoded one; a new _TOMO_SCAN_PARAM_NAMES entry, not a new job kind;
the GUI param-snapshot leak found and fixed while wiring this up; no
GUI widget yet).

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

fix(flomni): stop retrying _tomo_scan_at_angle on a definite FlomniError ... 5991920c15

Found by testing the new at_each_angle_hook feature against the live
sim: _tomo_scan_at_angle is wrapped in @scan_repeat(max_repeats=10,
default=True), which retries *any* exception, including a FlomniError
raised for an unregistered hook -- a condition that will never
succeed by retrying. The operator saw 10 silent retries before a
generic "TooManyScanRestarts", with the actual, actionable error
message buried in __cause__ instead of reaching
tomo_queue_execute()'s printed failure message. Adds an exc_handler
that skips the retry for any FlomniError (a definite, non-transient
failure by convention throughout this file), letting the real message
surface immediately. General fix, not narrowly scoped to hooks --
every other FlomniError this method could raise gets the same benefit.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

docs(flomni): record sim-validation results for the at_each_angle hook ... 0899ac9809

Notes what was actually exercised against the live sim (registration/
list/unregister, per-job param snapshot including the reset-to-None
case, the hook firing during a real tomo_queue_execute() run, and the
unregistered-hook incomplete/resume path) and the scan_repeat retry
bug found and fixed along the way.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

feat(flomni): publish registered at_each_angle hook names via a global var ... c90be4f336

Adds tomo_at_each_angle_hooks (a plain list of names), republished on
every register_at_each_angle_hook()/unregister_at_each_angle_hook()
call and reset to empty in __init__ (hooks are session-only, so a
stale list from a prior session must not linger). Same reasoning as
tomo_queue_actions for the command-job registry: a GUI (or any other
client) can build a dropdown from this directly, no hardcoded mirror.
Sim-validated: register/unregister updates the published list
correctly and the webpage generator's current_params payload picks up
an active hook.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

feat(bec_widgets): add at_each_angle hook dropdown to TomoParamsWidget ... 26e5466982

A new "At-each-angle hook" combo box in the params panel, built from
the live tomo_at_each_angle_hooks global var (no hardcoded mirror of
registered names). Rebuilt on every populate (i.e. every 2s poll while
not editing, and on entering edit mode), so hooks registered/
unregistered from the CLI while the dialog is open show up
automatically. The currently-set hook is always shown even if it
isn't in the published list (e.g. registered in a different or
since-restarted session), labeled accordingly, so it's never silently
hidden. Special-cased in _populate_fields()/_read_fields() like
tomo_type -- the generic QComboBox handling assumes integer data,
which doesn't fit a hook name string or None. This also makes the
manual params["at_each_angle_hook"] pass-through in
add_edited_to_queue() (added when there was no widget for this field)
redundant; removed, since _read_fields() now supplies it directly
from the dropdown.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

feat(flomni): show the active at_each_angle hook on the status webpage ... 08e1122230

TQ_PARAM_DISPLAY (the queue job detail table) and _CURRENT_PARAM_KEYS
(the live 'Current measurement' section) are both hardcoded mirrors of
which tomo params to render -- at_each_angle_hook wasn't in either, so
a hook-driven job wouldn't crash the page but also wouldn't show that
anything non-standard was running. Adds at_each_angle_hook to
_CURRENT_PARAM_KEYS (Python side, gates inclusion in the JSON payload
on the value actually being set) and a conditional row in
buildParamRows() (JS side, only rendered when the value is present --
deliberately left out of TQ_PARAM_DISPLAY so a normal job doesn't grow
a "-" row nobody needs). Sim-validated: current_params includes
at_each_angle_hook when set and omits it when not.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

docs(flomni): document the at_each_angle hook GUI dropdown and webpage display ... 25a6b89b92

User manual: explains the new "At-each-angle hook" dropdown and its
"None (default)"/"(not registered in this session)" states, plus that
an active hook shows on the status webpage.

AI_docs: updates section 3.4 (GUI widget added, webpage display
added, extended sim-validation note for the global-var publishing and
webpage payload) and the plan's top status line. GUI test checklist
gets a new section 6b (test steps 28-35: dropdown population/refresh,
Submit vs Add-to-queue behaviour, the "not registered" label, and the
webpage's queue-detail + Current-measurement rendering) and an updated
section 1 item 9 + top status line noting none of this is click-tested
yet.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

feat(flomni): warn in tomo_parameters() when single-point mode needs a different call ... 6f8623fee8

tomo_scan_projection() always runs a Fermat scan and tomo_acquire_at_angle()
always runs a single-point acquisition -- they aren't interchangeable, and
calling tomo_scan_projection() directly while single_point_instead_of_fermat_scan
is on triggers an interactive confirmation prompt that would hang an
unattended queue run. tomo_parameters() now prints a reminder of which one
to call (including inside a custom at_each_angle hook) whenever single-point
mode is enabled, surfacing this proactively instead of only at the point of
the runtime prompt.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

feat(bec_widgets): mirror the single-point acquisition-method warning in the GUI ... 7054bf9858

Adds a wrapped, styled warning label under "Random shift max" in the
params panel, shown whenever "Single-point scan" is checked and hidden
otherwise -- same reminder tomo_parameters() now prints on the CLI
side: use tomo_acquire_at_angle(angle), not tomo_scan_projection(angle),
when single-point mode is on. Toggled from the existing
_on_single_point_changed() handler, so it updates on both a live edit
and every params-panel refresh (the widget's checkbox state already
drives this handler either way).

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

docs(flomni): clarify hook re-registration and the two acquisition methods ... a23e9557a9

Two additions to the at_each_angle hook writeup: registering a hook
stores the function object at that moment, not a live link to its
name, so editing the function later requires calling
register_at_each_angle_hook() again -- redefining it alone does
nothing. And tomo_scan_projection()/tomo_acquire_at_angle() are not
interchangeable (Fermat vs single-point); the example hook now calls
tomo_scan_projection() plainly (no more confusing _internal=True in
user-facing code) with a clear note on when to use the other one
instead, matching the new CLI/GUI warnings.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

feat(flomni): fire the single-point acquisition warning on the off->on transition ... 13ad8bbf7a

Previously the tomo_acquire_at_angle()-vs-tomo_scan_projection()
reminder only printed when tomo_parameters() happened to be called
afterward -- easy to miss if you just flip
single_point_instead_of_fermat_scan directly. Its setter now prints
the same note immediately when the value transitions False->True.
Gated on the transition (checked via the property's own getter before
the write) so restoring an already-True value across consecutive
queued jobs doesn't reprint it every time -- sim-verified: silent on
False->False, True->True (repeat), and True->False; prints exactly
once per False->True flip.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

docs(flomni): note the single-point warning fires on the off->on transition ... ca8178fff3

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

docs(flomni): add test step 36 for the single-point warning label/print ... 9df9253c84

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

feat(flomni): surface the active hook (name + source) in reports and CLI ... 1ef95c6e2d

Adds _describe_active_hook() (flags a name that isn't currently
registered, e.g. after unregister_at_each_angle_hook() while
at_each_angle_hook still references it -- confirmed this is expected:
unregistering only removes it from the runtime dict, the property
itself is untouched) and _active_hook_source() (inspect.getsource(),
None if unavailable). Wired into:
- tomo_parameters()'s printed hook line, now flags "NOT registered"
- the end-of-scan scilog entry (name in the printed/scilog text,
  source code appended to the scilog text only, not the console)
- write_pdf_report() (name as a report line, source appended to both
  the PDF file and the scilog entry it sends)
So a hook-driven measurement's actual behavior is part of the
permanent record, not just inferable from a name that might not even
resolve anymore. Sim-verified all six states (unset, registered,
unregistered) for both helpers.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

feat(flomni): show the active hook in the ring progress bar ... 4c2282912e

flomnigui_show_progress()'s center label now includes a "Hook: name"
line when at_each_angle_hook is set, same condition/wording as
tomo_parameters()'s CLI note -- an operator watching the progress GUI
during an unattended queue run can tell a hook is active without
switching to a CLI session.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

fix(bec_widgets): drop the redundant row-number gutter in the queue table ... 436c3f0137

Qt's own vertical header (1-based) sat to the left of the dialog's own
0-based "#" column (which matches the CLI's indices -- tomo_queue_show(),
tomo_queue_delete(), tomo_queue_move()) -- two differently-based
indices next to each other read as confusing/wrong. Hides Qt's
gutter, keeping only the one that actually means something.

Also shows a tomo job's active at_each_angle_hook in the Details
column (e.g. "hook: name" or "hook: name (not registered)", checked
against the published tomo_at_each_angle_hooks list) -- previously
Details was always blank for tomo jobs, so a hook-driven queued job
looked identical to a plain one without expanding the row tooltip.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

docs(flomni): document hook reporting fixes and record real-session test results ... 8dc4a56b91

User manual: notes that the hook (name + source, when registered)
appears in tomo_parameters(), the scilog entry, the PDF report, and
the progress-ring label, and clarifies that unregistering a hook does
not clear at_each_angle_hook -- confirmed expected behavior.

AI_docs test checklist: records that sections 3-6b passed real-session
testing (updating the stale "not yet clicked through" status), adds
section 6c (test steps 37-41) for the fixes found during that testing,
and updates section 1's summary (new item 10).

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

feat(bec_widgets): add "Load into editor" to reuse a queued job's settings ... 97ac0acde9

Select a single tomo job (command jobs have no params, so they're
excluded) in the queue dialog and click "Load into editor" to enter
edit mode on the params panel populated from that job's saved
snapshot instead of the live backend. Reuses the existing edit-mode
machinery (_enter_edit_mode_with(), factored out of enter_edit_mode())
so the operator reviews/tweaks and then uses the normal Submit or "Add
to queue" paths -- no new write path, nothing touches live params or
the queue itself just by loading. If an edit is already in progress,
confirms before discarding it. The button is disabled outside a
single-tomo-job selection and during sort mode, and re-evaluated on
selection change and on every table refresh.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

docs(flomni): document "Load into editor" ... 7fbfee7c36

User manual: new paragraph in the queueing section explaining the
button and that Submit/"Add to queue" still gate the actual write.

AI_docs: plan section 6.8 records the design (not a third write path,
confirm-before-discard, button-eligibility gating) and the
_enter_edit_mode_with() refactor; GUI test checklist gets section 6d
(test steps 42-47) and a new section 1 item 11, with the status line
updated to flag 6c/6d as not yet clicked through.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

fix(flomni): raise instead of silently returning when a fermat scan is declined ... 778c953f2e

tomo_scan_projection() always runs a Fermat scan; when
single_point_instead_of_fermat_scan is on and _internal isn't passed,
it asks "Run a fermat scan anyway?" and, on "no", used to just print
"Aborted." and return -- no exception. Real incident: a custom
at_each_angle hook called this without _internal=True, got asked at
every projection angle, declining silently skipped each one, and the
eventual Ctrl-C (KeyboardInterrupt, which tomo_queue_execute()'s
`except Exception` does not catch) left the job stuck at status
"running" forever with no live process behind it. Declining now raises
FlomniError, which (with the earlier scan_repeat exc_handler fix)
isn't retried and correctly fails the job, marking it "incomplete" and
pausing the queue -- the crash-resume contract tomo_queue_execute()
already documents, instead of silent data loss followed by an
untraceable stuck state. Sim-verified: direct decline raises with a
clear message; through the queue via a hook missing _internal=True,
the job ends up "incomplete", not stuck "running" or silently "done".

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

fix(bec_widgets): let delete/clear escape a stale "running" queue job ... ee036873cd

Real incident: a job got stuck at status "running" after its process
died mid-scan (Ctrl-C during a repeated confirmation-prompt loop, a
separate bug fixed alongside this one) with no live process behind it
-- and the GUI's delete/clear guard treated "running" as an absolute
block, with no way to escape from the GUI at all (the CLI's
tomo_queue_delete() has no such guard and already worked, but that's
not obvious/discoverable from the GUI).

Adds a staleness check using the same tomo_progress heartbeat signal
TomoParamsWidget._is_tomo_running() already uses: if a "running" job's
heartbeat is missing or older than 120s, it's very likely orphaned,
not actively executing. Delete/clear now offer an explicit
confirmation ("looks stale -- proceed anyway?") in that case instead
of an unconditional refusal; a genuinely fresh heartbeat still blocks
outright as before.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

docs(flomni): document the declined-scan and stale-running-job fixes ... d8b7737cc7

User manual: notes that declining the fermat-scan confirmation now
fails the job instead of silently skipping a projection, plus how to
recover a job stuck at "running" (tomo_queue_delete has no status
guard; update_by_id to fix the status directly; the GUI's staleness
override).

AI_docs: plan section 3.4 records the second real incident (declined
confirmation silently returning) and its fix; section 6.3 records the
stale-"running" GUI guard fix. GUI test checklist gets section 6e
(test steps 48-52) and section 1 item 12, status line updated to flag
6c/6d/6e as not yet clicked through.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

fix(bec_widgets): warn before "Add current params to queue" during an edit ... 9aeacefbf0

Real footgun: edit a value in the params panel but don't click its own
"Add to queue" (or Submit) -- then use the *separate* Queue control
window's "Add current params to queue" button, expecting it to queue
what was just typed. It doesn't: that button reads live global vars
(TOMO_QUEUE_COMMAND_JOBS_PLAN.md section 6.1's rule -- only the panel's
own Add-to-queue reads the form), so it silently queues the stale,
pre-edit values with no indication anything's off. Now checks the
parent params panel's edit-mode state and, if an edit is in progress,
warns explicitly and points at the correct button before proceeding
-- a warning rather than a hard block, since queuing the live params
alongside an unrelated in-progress edit elsewhere is still a
legitimate thing to want.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

docs(flomni): record 6c-6e pass results and document the add-to-queue warning ... fd5fc84867

GUI test checklist: sections 6c/6d/6e (items 37-52) all passed
real-session testing, including the stale-"running" override fixing
an actual stuck job found live -- status line and section 1 items
updated. New section 6f (items 53-55) for the "Add current params to
queue" mid-edit warning, plus section 1 item 13.

Plan doc section 6.1: records the second live-vs-unsaved-edit
confusion (a second window, not just the panel's own button) and why
it's a warning, not a block, unlike Submit.

User manual: new paragraph distinguishing the params panel's "Add to
queue" from the queue window's "Add current params to queue", and
when the warning fires.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

docs(flomni): mark the tomo queue GUI checklist fully validated ... 9eedfa4d52

Rewrites both status headers (plan doc + GUI test checklist) now that
every item (1-55) has been clicked through live and passes. Fixes two
remaining stale "not yet click-tested" references in section 1 (items
9/10) left over from before sections 6c/6d were tested. No open
checklist items remain; section 7's known limitations are scope cuts,
not bugs, and are the documented starting point for future work.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

holler merged commit 9eedfa4d52 into main 2026-07-14 15:48:39 +02:00

holler deleted branch feat/flomni_queue_with_commands 2026-07-14 15:48:39 +02:00

Sign in to join this conversation.

Reviewers

No Reviewers

Labels

Clear labels

issue::not confirmed

Used if an issue has not yet been confirmed by a developer

issue::not reproducible

Used if an issue is not reproducible

issue::reproducible

Used if a developer was able to reproduce the issue

priority::critical

Should be done as soon as possible

priority::needed

An important update to the code base

priority::nice to have

Not really needed but a good improvement

scope::backend

An issue regarding the backend services

scope::frontend

An issue regarding the user-facing services

stage::in development

This issue is currently being worked on

stage::on hold

Something is blocking the development

stage::pre_release

For issues that have been merged into a pre-release branch and are waiting for their release.

stage::ready for review

For issues that have been resolved and are ready for review

stage::selected for development

This issue has been selected for development but has not been scheduled yet

stage::weekly backlog

This issue has been selected for development for the next development cycle

type::bug

It's a bug!

type::discussion

A discussion is wanted/needed

type::doc

Improvements to the documentation

type::feature

A new feature

type::improvement

Neither a feature nor a bug but an improvement to the code base

type::test

Missing tests or improvements to the test suite

bug

Something is not working

duplicate

This issue or pull request already exists

enhancement

New feature

help wanted

Need some help

invalid

Something is wrong

question

More information is needed

wontfix

This won't be fixed

No labels

Milestone

No items

No Milestone

Projects

Clear projects

No projects

Assignees

Clear assignees

acerbo_a (acerbo_a) appel_c (appel_c) bec-gitea celcer_t (celcer_t) debenjak_l (debenjak_l) diaz (diaz) divall_e (divall_e) guizar_m (guizar_m) haghta_s (haghta_s) holler (holler) lombosi_c (lombosi_c) menzel (menzel) perl_d (perl_d) usov_i (usov_i) wakonig_k (wakonig_k) wang_x1 (wang_x1) wyzula_j (wyzula_j) zamofing_t (zamofing_t)

No Assignees

1 Participants

Notifications

Subscribe

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: bec/csaxs_bec#259