Poland buildings R120 acceptance test is a marginal timeout on a healthy query #166
Labels
No labels
blocked
claude-wip
map-report
map:is
map:se
needs-review
No milestone
No project
No assignees
2 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
art/ismap#166
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
The Poland buildings acceptance test is a marginal timeout on a healthy query
The test
layer buildings (pl) / R120: every Poland source part becomes a classified footprint...(conf/plmap.yaml) consistently exceeds its 10 s timeout on this machine:the query takes ~11 s (10.98 s measured), because
sum(ST_NumGeometries(geom))overpl_bubd(Poland's largest staging table, 16.35 M parts) plus the three companionsubqueries is just too slow for the bucket. The data is correct — footprints == source
parts == 16 351 829, unclassified == 0 — so this is a timeout tuning problem, not an
import defect.
It surfaces in every
make acceptance-allas the single red line and forces a reviewerto check it isn't a regression. Options:
timeoutto 100 s (it is genuinely the heaviest query in the suite), orre-scanning 16 M geometries on every run.
Found while verifying issue #164, unrelated to that change.
Reproduced while reviewing #168/#169 (it is not from either branch — it fails identically on unmodified
main). Two details that change the options.The margin is larger than the ~11 s recorded above. Given a 100 s budget the test passes in 16.9 s, with the numbers this issue quotes, so it is the same healthy query:
Poland is 46/46 with that budget. Load moves the figure around, but 17 s against a 10 s bucket is not marginal — and it rules out a modest bump: raising the timeout to ~20 s would make the failure intermittent rather than fix it.
Option 1 (raise to 100 s) does not do what it looks like.
fastAcceptanceTimeoutis 10 andrunsInismode == "all" || t.Timeout <= fastAcceptanceTimeout(importer/acceptance.go:74,84), so raising this test's timeout past 10 does not make it pass inmake acceptance— it makes it stop running there, executing only under-acceptance all. Measured withtimeout: 100:That trades a red line a reviewer has to check for a check nobody sees, which is the worse of the two.
So option 2 is the one worth doing: the expensive half is
sum(ST_NumGeometries(geom))re-scanning 16.35 M geometries inpl_bubd, which is static per import. Either precompute that count at load time and compare against it, or split the test — a cheap always-on check on the footprint/unclassified counts inside the 10 s bucket, and the full source-part reconciliation as a separate-acceptance alltest where a 100 s budget is honest about what it is.Note for whoever picks this up: after #169 the test lives in
conf/pl/15-buildings.yaml, notconf/plmap.yaml.