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.
- auto_start on the FX config: add the field to
ores.synthetic.fx_spot_generation_config.org(right afterenabled, mirroring the IR model's placement and shape — boolean, not null, default false, orthogonal toenabled) 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 (selecta.auto_start, insertcoalesce(r.auto_start, false)), matching the IR block's pattern. - 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=trueon 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. - One walk:
auto_start_enabled_feedsandauto_start_enabled_ir_curve_feedsbecome oneauto_start_feedspass. 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.