Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Stage D: lifecycle — nothing stops an excitation on Ctrl-C; idempotent stop; snapshot/restore

Open
  • Is something wrong?
#16 1 comment 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
55/100
Issue type
Feature
Clarity
Clearly specified
Activity status
Quiet
Tech stack
python
Domain
backend, embedded-iot

Research direction

Start with the backend interface in src/system_ident/backends/base.py and compare the in-memory snapshot/restore implementations in twin.py and rtsfreerun_adapter.py. Then inspect lifecycle handling in the backend, loop.py, and safety.py, along with pyproject.toml to confirm hardware dependencies are absent. Done means safe interruption, idempotent stopping, and restorable in-memory excitation state without pretending to restore filter-module state.

Written by the indexing model from the issue text.

Description

bug

Stage D (spec §3.6, §4.2).

Ctrl-C leaves the AWG driving
grep -rn 'KeyboardInterrupt|atexit|signal\.|SIGINT|finally' src/system_ident/*.py src/system_ident/backends/*.py
-> zero matches

src/system_ident/loop.py:181 catches only SafetyAbort, so a KeyboardInterrupt during a
multi-hour read() propagates straight out of run(), past watchdog.abort() at
src/system_ident/loop.py:187, and the excitation keeps running. The sibling project solved this on
hardware with a finally + started flag + loud warning + conditional re-raise; that logic is correct and
hard-won and should be ported verbatim.

Fix belongs in the backend, not the loop — the loop must stay backend-agnostic
(src/system_ident/backends/base.py:3):

  • try/finally around start → settle → fetch in read(), calling an idempotent _stop_all.
  • Register atexit and a SIGINT/SIGTERM handler in __init__ calling the same _stop_all
    (atexit does not fire on SIGTERM).
  • Add KeyboardInterrupt to src/system_ident/loop.py:181's handler as belt-and-braces, so the
    campaign still runs watchdog.abort().
ramp_down must be idempotent

src/system_ident/loop.py:164 calls it per DoF, and Watchdog.abort
(src/system_ident/safety.py:137) calls it again for every channel at
src/system_ident/loop.py:187 — so the last DoF's channel is stopped twice. The sibling project found
that calling stop() in the wrong state raises "cannot join thread before it is started" and masks the
real error. Keep self._started: dict[str, bool] and no-op when not started.

snapshot_state / restore_state are mandatory here

src/system_ident/loop.py:140 calls them unconditionally and the base class raises
(src/system_ident/backends/base.py:66), so a campaign dies at line 140 without them.
TwinBackend (src/system_ident/backends/twin.py:223) and RTSfreerunBackend
(src/system_ident/backends/rtsfreerun_adapter.py:246) simply save/restore their in-memory drives.

Keep the scope honest. Capture only what can actually be restored — which channels have a live
excitation, and their ramptime — and state in the docstring that filter-module switch/gain/offset state
is NOT captured. On hardware restore_state is the "hand control back to the damping loops" step
(src/system_ident/safety.py:9), and doing that properly needs ezca/pyepics (absent from
pyproject.toml:21) plus operator sign-off on what may be written. That is deferred to Component 2.
Do not fake it.

Campaign: CDS hardware backend · branch feat/cds-hardware-backend
· spec · plan · handoff
Code is deferred until the plan and issues have been reviewed.

Dominant language
Python
Stars
0
Forks
1
No merged PRs in 30d

Getting set up

This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from CaltechExperimentalGravity/system_ident

All issues in CaltechExperimentalGravity/system_ident

Similar issues

More Python issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.