Bug
Commit a24b2c0 ("auto-start trainer when opening Segment Folder in workstation mode") added auto-start logic intended for workstation builds. However, the gate is just if self.server_manager:, which is truthy whenever find_trainer_launch() returns any spec — including the dev fallback find_dev_trainer_launch() (in painter/src/main/python/server_manager.py).
As a result, when running the painter from a source checkout that has trainer/env/bin/python, clicking Segment Folder (or opening a project — same logic at a second site) spins up a second trainer alongside any trainer the developer is already running externally. The two trainers race for instructions, and it becomes hard to tell which one is doing what.
Affected sites
painter/src/main/python/root_painter.py:517-520 — show_segment_folder
painter/src/main/python/root_painter.py:1094-1096 — same pattern when opening a project
Design question, not just an implementation fix
The fix is not as simple as "gate on bundled trainer". A developer running from source might still want workstation-style auto-start (e.g., when testing the workstation UX without rebuilding the bundle), and conversely they might be running an external trainer and not want auto-start. The gate isn't really "bundled vs. dev" — it's "user intent."
Possible directions to consider:
- Explicit opt-in via env var (
ROOTPAINTER_AUTOSTART_TRAINER=1) or CLI flag.
- Menu toggle ("Auto-start trainer" checkbox under Network or Extras).
- Detect an already-running trainer (e.g., heartbeat instruction round-trip) and skip auto-start if one is responsive.
- Default off in source mode, on in workstation mode, with an override either way.
No preferred direction yet — filing this so the question gets thought through before patching.
Bug
Commit a24b2c0 ("auto-start trainer when opening Segment Folder in workstation mode") added auto-start logic intended for workstation builds. However, the gate is just
if self.server_manager:, which is truthy wheneverfind_trainer_launch()returns any spec — including the dev fallbackfind_dev_trainer_launch()(inpainter/src/main/python/server_manager.py).As a result, when running the painter from a source checkout that has
trainer/env/bin/python, clicking Segment Folder (or opening a project — same logic at a second site) spins up a second trainer alongside any trainer the developer is already running externally. The two trainers race for instructions, and it becomes hard to tell which one is doing what.Affected sites
painter/src/main/python/root_painter.py:517-520—show_segment_folderpainter/src/main/python/root_painter.py:1094-1096— same pattern when opening a projectDesign question, not just an implementation fix
The fix is not as simple as "gate on bundled trainer". A developer running from source might still want workstation-style auto-start (e.g., when testing the workstation UX without rebuilding the bundle), and conversely they might be running an external trainer and not want auto-start. The gate isn't really "bundled vs. dev" — it's "user intent."
Possible directions to consider:
ROOTPAINTER_AUTOSTART_TRAINER=1) or CLI flag.No preferred direction yet — filing this so the question gets thought through before patching.