Task: One auto-start with uniform startability semantics

Table of Contents

This page documents a task in the Feed lifecycle harmonization: asset-class-agnostic feed control-plane story. It captures the goal, current status, acceptance, and any notes or results.

Goal

One boot-time auto-start walk replaces auto_start_enabled_feeds and auto_start_enabled_ir_curve_feeds, with uniform startability semantics across kinds: enabled + auto_start + enabled container. auto_start becomes a common lifecycle column (the FX config gains it), and the startability gate is common code.

Status

Field Value
State DONE
Parent story Feed lifecycle harmonization: asset-class-agnostic feed control-plane
Now Nothing.
Waiting on Nothing.
Next Nothing.
Last touched 2026-08-11

Acceptance

  • auto_start exists on the FX config (codegen model + DQ artefact + seeds) so both kinds share the lifecycle column.
  • One auto-start walk reads every config kind once, applies the same startability gate, skips-with-warn the same way, and reports the same running-count summary.
  • Boot behaviour for existing FX and IR configs is preserved (IR configs keep their current auto_start values; FX gains the column with the container-enabled semantics it already had).

Plan

The FX config gains auto_start as a common lifecycle column, then the two boot walks collapse into one.

  1. auto_start on the FX config: add the field to ores.synthetic.fx_spot_generation_config.org (right after enabled, mirroring the IR model's placement and shape — boolean, not null, default false, orthogonal to enabled) and regenerate the entity's full codegen set. The DQ artefact table (dq_synthetic_fx_spot_configs_artefact_create.sql) gains "auto_start" boolean not null default false — the exact column the IR artefact already has — and the publish function's FX block threads it through (select a.auto_start, insert coalesce(r.auto_start, false)), matching the IR block's pattern.
  2. Seeds preserve boot behaviour: today every enabled FX row under an enabled container auto-starts, and every publish-created container is enabled — so the four FX populate scripts set auto_start=true on every row, keeping the boot-started set identical. The IR gate gains the enabled-container requirement; every published IR container is enabled, so IR boot behaviour is unchanged too.
  3. One walk: auto_start_enabled_feeds and auto_start_enabled_ir_curve_feeds become one auto_start_feeds pass. It reads every config kind once, applies one startability gate (enabled + auto_start + enabled container), collects per-kind build candidates (each carrying its kind string, display name, binding mode, and build input), then adds them all through the factory and the single controller with one skip-with-warn message shape (missing children warn, gate skip silent, conflict errors with the holding source name, build failures caught per candidate) and one running-count summary. The caller's single running-count line stays.

Notes

Test Scenarios

Manual QA scenarios (scaffolded via compass add test_scenario, run through the QA Validation Runner panel) that verify this task. Link new ones here as they're created; the scenario doc itself links back via its "Verifies task" field.

Scenario State Notes
     

PRs

PR Title
#1971 [synthetic,sql] One auto-start with uniform startability

Review

Comment summary File Decision Notes
       

Result

auto_start now exists on the FX spot generation config end to end: the codegen model (ores.synthetic.fx_spot_generation_config.org) and the DQ artefact model (ores.dq.synthetic_fx_spot_config.org) both gained the field after enabled (boolean, not null, default false, orthogonal to enabled), and the full codegen set was regenerated — domain structs, generators, repositories, mappers, the Qt detail dialog (autoStartCheck widget) and Qt model column, the DQ artefact create (dq_synthetic_fx_spot_configs_artefact_create.sql, SQL default false), the real-table create, and the publish-from-dq function (select a.auto_start, insert coalesce(r.auto_start, false), mirroring the IR block).

The four FX populate scripts set auto_start=true on every row, so the boot-started set is identical to before the column existed. The IR gate gains the enabled-container requirement, which changes nothing for published IR configs (every publish-created container is enabled).

auto_start_enabled_feeds and auto_start_enabled_ir_curve_feeds collapsed into one auto_start_feeds pass in application.cpp: one read of every config kind, one startability gate (enabled + auto_start + enabled container), per-kind build candidates collected in the same pass, one common add loop through the factory and the single controller, one skip/conflict warning shape, and one "Auto-started N enabled feed(s)." summary line.

Verification: full build green (100%), DB recreated (schema 0.0.25), rat green (exit 0) — including the folder-cascade tests, whose enabled FX row now sets auto_start=true like every published FX row.

Acceptance met: auto_start exists on the FX config; one auto-start walk with one gate, one skip-with-warn shape, one summary; boot behaviour preserved for both kinds.

Emacs 29.3 (Org mode 9.6.15)