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

[deferred] Guardian / lock-state abort, and full filter-module snapshot/restore

Open
#28 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
15/100
Issue type
Feature
Clarity
Needs clarification
Activity status
Quiet
Tech stack
python
Domain
backend, security

Research direction

Review src/system_ident/safety.py, especially Watchdog and snapshot_state/restore_state, then read docs/tutorial/safety-and-ops.qmd and the Phase-C section of notes/strategic-roadmap-2026-07-draft.md. Check pyproject.toml for the missing hardware dependencies and resolve the open question about filter history. This is ready only after Component 1, plan review, and explicit operator sign-off define the permitted writes and restore behavior.

Written by the indexing model from the issue text.

Description

enhancement

Component 2 — deferred. Blocked on Component 1 and on operator sign-off.

Guardian / lock-state abort

Add a lock-state / Guardian hook on top of the existing Watchdog
(src/system_ident/safety.py:59), so a lock loss aborts the campaign through the same idempotent
handoff rather than continuing to inject into a changed plant. Today the watchdog keys only on physical
limits — actuator saturation and per-DoF output RMS — by design
(docs/tutorial/safety-and-ops.qmd), which is right for what it covers but says nothing about the
interferometer's state.

Full snapshot / restore

Component 1 implements snapshot_state / restore_state honestly but minimally: live-excitation state
only, with the docstring stating that filter-module switch/gain/offset state is not captured.

Completing it means capturing and restoring the filter-module state — and that is a real escalation:

  • It needs ezca / pyepics, absent from pyproject.toml:21.
  • It means writing to the front end, so it needs explicit operator sign-off on exactly what may be
    written.
  • Open question from notes/strategic-roadmap-2026-07-draft.md §Phase-C: must the snapshot capture
    filter-module history (i.e. is fm_clear_history required), not just switch positions and gains?

On hardware restore_state is the "hand control back to the existing damping loops" step
(src/system_ident/safety.py:9), so getting it wrong is a safety issue, not a convenience one.


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
PR merge metrics
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.