/rugnux/status kept answering with the previous collection's rugnux run after POST /initialize,
and also after a /start whose collection does not run rugnux - the latter under the new run's
tokens. RugnuxLiveStatus gets a Clear(), called from JFJochReceiverService::ClearResults(), which
/start already uses to drop the previous run's status, plots and buffered images before the tokens
change. Initialize now calls ClearResults() instead of ClearImageBuffer(), so a fresh start also
drops the previous run's receiver status and plots.
Authentication: every rugnux endpoint (GET/PUT /config/rugnux, PUT/DELETE /config/rugnux/model,
GET /rugnux/status) was already in the broker's bearer-protected set and carries bearerAuth in
jfjoch_api.yaml; the HTTP auth test now checks all five.
The yaml descriptions of /initialize and rugnux_live_status say so; the C++ model and frontend
client are regenerated (comments only).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PXc1zD1yxHqaR1DGdCTHL4
The broker's rugnux live status carries expected_collection_s = images x image time
(DiffractionExperiment::GetImageTime, summation included), set at START. The frontend's
timeline uses it as the expected end until a frame rate is measured, and as the axis floor
while collecting, so the axis no longer starts at 10 s and rescales as images arrive. An
older broker without the field keeps the 10 s floor.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PXc1zD1yxHqaR1DGdCTHL4
The live panel showed ~80 Hz on a 100 Hz collection. Its clock started when
the receiver had applied and forwarded the START message, so the START ->
first image gap counted as collection time; the images were stamped when a
forward thread dequeued them, and the last image only after END and the
thread joins; and N images were divided by a span holding N-1 intervals.
- ImagePullerOutput carries `received`, a steady_clock time set by the TCP
and ZeroMQ pullers as the message comes off the socket, before it is
queued or deserialised (TestImagePuller stamps it on Put when unset).
- RugnuxLiveStatus takes those times: START's for its origin, each image's
for the first and last image (min/max, as forward threads report out of
order). last_image_s is the last data image's puller time.
- Zero of every reported time (elapsed_s, steps' started_s, probe_s,
last_image_s, cut_s) is now the FIRST IMAGE, as the frontend already
said; before the first image arrives "now" is 0 and earlier steps are
negative. The START -> first image time is recorded on its own as
start_to_first_image_s (snapshot, OpenAPI rugnux_live_status, regenerated
C++ model and frontend client, OpenAPIConvert).
- The frontend rate is (images_received - 1) / (last - first image); the
panel headers show "START -> first image X.X s".
- The broker logs "rugnux live: START -> first image ..., N images in T s
from the first to the last (R Hz)"; "done X s after the last image" and
last_image_to_written_s run from the puller time of the last image.
The deadline timer is unchanged (it still starts once the forward threads
have joined). No analysis result changes.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PXc1zD1yxHqaR1DGdCTHL4
leonarski_fandClaude Opus 5.5