leonarski_fandClaude Opus 5
a6a715703f
An acquisition started with async_start returns from /start before the measurement thread has run, so a failure there had no caller to raise it to. MeasurementThread stored it in start_exception, but only the synchronous branch of Start() ever read it. The ordinary-failure path - a writer refusing to overwrite an existing file, say - sets the state to Idle rather than Error, and Idle is what wait_until_running_post maps to 504 "timeout, need to restart". So the one case the async workflow exists to report came back as a timeout with an empty body, and the writer's message was dropped. /wait_till_done was worse: Idle is its success case, so it answered 200 for a run that never started. Only a critical detector fault, which leaves the state at Error, was reported at all. The wait functions now rethrow start_exception, so both endpoints produce the same 500 and the same message as a synchronous start. rethrow_exception does not consume the exception_ptr, so repeated calls all report the same failure. It is cleared by every entry point that begins new work - Start (before ImportDatasetSettings, which can throw), Initialize, Pedestal, LoadDetectorSettings, SetDarkMaskSettings - so a pending failure is never attributed to the operation after it. The synchronous branch no longer clears it, so a wait call made after a failed /start reports the failure rather than an apparent timeout. wait_until_running_post and wait_till_done_post drop their timeout == 0 special case, which called GetStatus() directly and so bypassed the rethrow: ?timeout=0 returned 200 from /wait_till_done where ?timeout=1 returned the error. wait_for evaluates the predicate before expiring, so the state reported is unchanged. JFJochReceiverService::Start clears the receiver status when the start fails. JFJochReceiver's constructor sets progress to 0 and a zeroed status before the throw, and nothing cleared it, so /status reported Idle with progress 0 - a stalled acquisition, to the frontend - and /statistics reported an all-zero run that never happened, until the next start overwrote it. Its catch widens to std::exception, so a non-JFJochException gets the cleanup and the logging it skipped before. Nothing else is left dirty by a refused start: the receiver keeps its null receiver and Idle state, PrepareAction only resets counters (the FPGA is armed in StartAction, in a thread launched after the start message goes out), and SendStartMessage precedes every std::async in the receiver constructor. The test starts four more times afterwards, one of them a complete acquisition with no re-initialisation in between. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Uwv9ScHtDH6g8tYgfSuApo
Jungfraujoch
Application to receive data from the PSI JUNGFRAU and EIGER detectors.
All documentation is now placed in docs/ subdirectory and for the current version hosted on Jungfraujoch Read The Docs page.