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

Doric preflight-armed driver is reused at runtime but stimulation startup still calls connect()

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

Nobody has claimed this yet.

Assessment

Difficulty
3/5
Estimated time
1-2 days
Newbie friendliness
65/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Quiet
Tech stack
python
Domain
embedded-iot

Research direction

Read preflight_ui.py::_arm_laser_for_launch(), then follow stim_controller.py::from_config() and start() to trace reuse of live_state.laser_driver. Check doric_light_source.py::connect() and the bundled Doric lifecycle examples. Done means the preflight-armed path is explicit, skips a second connect(), and distinguishes reuse from fresh initialization without changing launch blocking.

Written by the indexing model from the issue text.

Description

Summary

When a laser run is verified in preflight, we keep a live DoricLightSource in live_state.laser_driver and reuse it during runtime. However, StimulationController.start() still unconditionally calls driver.connect().

Why this is confusing

  • Preflight launch verification already opens the Doric device and leaves it armed.
  • Runtime reuses that same driver object via live_state.laser_driver.
  • start() still calls connect() as if runtime owns first initialization.
  • This currently works only because DoricLightSource.connect() short-circuits when self._dll is not None.

Code references

  • preflight_ui.py: _arm_laser_for_launch() stores the armed driver in live_state.laser_driver.
  • stim_controller.py: from_config() reuses live_state.laser_driver when present.
  • stim_controller.py: start() still calls self._config.driver.connect() unconditionally.
  • doric_light_source.py: connect() returns early when _dll is already set.

Local evidence

  • Bundled Doric examples show a single lifecycle: init -> open_device -> use -> close_device -> quit.
  • We did not find local documentation explicitly stating that repeated connect() on an already-open device is supported.
  • In the current reuse path, the second connect() is probably harmless because our wrapper short-circuits, but that is wrapper behavior, not a documented Doric contract.

Desired fix

  • Make the preflight-armed runtime path explicit.
  • Do not call connect() again when reusing an already-armed preflight driver.
  • Keep runtime startup semantics clear: reuse vs fresh initialization should be distinguishable in code and UI copy.

Notes

  • This is separate from UI wording cleanup.
  • Preflight still blocks launch if required laser verification fails.
  • After launch, runtime fault handling remains a separate behavior question.
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 matiasandina/uid_python_api

All issues in matiasandina/uid_python_api

Similar issues

More Python issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.