Found while running the full gated-live suite for #1855. Pre-existing on dev - reproduced on origin/dev at 85cff15 with no local changes, so it is not that PR's doing.
Symptom
Against a FRESH DARLING_TEST_PG database, a full dotnet test Darling/Darling.Tests run fails one test:
Darling.Tests.PayloadDimensionLiveTests.DimensionGc_DefersWhenAFactFloorIsUnmeasurable_ThenPrunesOnceItIs [FAIL]
Npgsql.PostgresException : 42P01: relation "timescaledb_information.continuous_aggregates" does not exist
at PayloadDimensionLiveTests.cs:line 840
It fails 3-5 ms into the run, before anything has migrated the store, and the class passes in isolation (12/12) because a sibling test migrates first.
Why it reads as someone else's bug
Across four full runs the failure MOVED - PayloadDimensionLiveTests three times and DarlingAnomalyBaselineTests.EndToEnd_RestartExclusionBaselines_AndWaitSpikeDetector_AgainstDevPostgres (Expected: 9 / Actual: 8) once - which is the expensive shape of flake described in the #1783 write-up: it looks exactly like the change under test broke something it never touched. The second one may be a different defect with the same cause (ordering against a not-yet-migrated store) or a genuinely separate one; only the TimescaleDB relation error has been root-caused.
The likely fix
The test reaches timescaledb_information.continuous_aggregates without first establishing the extension. Every sibling live class runs PgMigrations.MigrateAsync before touching the store; this path does not, or does it after the read. Either order the migration ahead of the read or make the CAGG probe tolerate a store where the extension is not yet installed - but ordering is the shape the rest of the suite uses.
Repro
createdb -h 127.0.0.1 -p <port> -U darling fresh
DARLING_TEST_PG="Host=127.0.0.1;Port=<port>;Username=darling;Database=fresh" dotnet test Darling/Darling.Tests/Darling.Tests.csproj --no-build
PostgreSQL 18.4 + TimescaleDB 2.28.1 from the repo's pg-runtime.zip. CI's darling-pg job also builds a throwaway cluster per run, so it is worth checking whether CI is green here by luck of scheduling order rather than by correctness.
Found while running the full gated-live suite for #1855. Pre-existing on
dev- reproduced onorigin/devat 85cff15 with no local changes, so it is not that PR's doing.Symptom
Against a FRESH
DARLING_TEST_PGdatabase, a fulldotnet test Darling/Darling.Testsrun fails one test:It fails 3-5 ms into the run, before anything has migrated the store, and the class passes in isolation (12/12) because a sibling test migrates first.
Why it reads as someone else's bug
Across four full runs the failure MOVED -
PayloadDimensionLiveTeststhree times andDarlingAnomalyBaselineTests.EndToEnd_RestartExclusionBaselines_AndWaitSpikeDetector_AgainstDevPostgres(Expected: 9 / Actual: 8) once - which is the expensive shape of flake described in the #1783 write-up: it looks exactly like the change under test broke something it never touched. The second one may be a different defect with the same cause (ordering against a not-yet-migrated store) or a genuinely separate one; only the TimescaleDB relation error has been root-caused.The likely fix
The test reaches
timescaledb_information.continuous_aggregateswithout first establishing the extension. Every sibling live class runsPgMigrations.MigrateAsyncbefore touching the store; this path does not, or does it after the read. Either order the migration ahead of the read or make the CAGG probe tolerate a store where the extension is not yet installed - but ordering is the shape the rest of the suite uses.Repro
PostgreSQL 18.4 + TimescaleDB 2.28.1 from the repo's
pg-runtime.zip. CI'sdarling-pgjob also builds a throwaway cluster per run, so it is worth checking whether CI is green here by luck of scheduling order rather than by correctness.