You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
ci(bench): erd_open_200 scenario times out in app_perf_bench; make bench failures exit non-zero #1546
benchmark/app_perf_bench.dart (added in #1173) fails in the erd_open_200 scenario on current dev:
BENCH error: Bad state: timeout waiting for diagram of 200 tables
The scenario runs a 200-table DDL script in a new tab, taps open_diagram_tab, and waits up to 20 s for the card with key erd_table_erd_t199. The key still exists (lib/features/erd/widgets/erd_table_card.dart).
What was found
Re-running with only this scenario and dumping the visible texts on timeout showed the UI on the connection's Overview tab with Tables 3 (the demo's own tables), and no erd_table_* cards. So either the DDL script did not create the tables (multi-statement run in one tab) or the Diagram tab was never opened. It is not shown to be an ERD performance problem.
Because the scenario aborts, everything after it in the bench is unchecked, and the ERD scenario guards nothing.
Scope
Find out which of the two it is (assert the table count after the DDL run; assert the Diagram tab is the active one before waiting).
Fix the scenario so it opens the diagram and reports build/raster for the 200-table layout and first paint.
Make the bench fail loudly (non-zero exit) when a scenario times out, instead of printing BENCH error and exiting 0.
Optional: a budget check for run_heavy_query (max build) so a regression fails the run.
Acceptance
erd_open_200 runs and prints build/raster numbers.
Suggestion while fixing this scenario: add a leak check to the same harness. The method that found #1555 is small: after warm-up, force a full GC with getAllocationProfile(gc: true), record instancesCurrent per class, repeat N x (run query in the same tab / open + close a tab with "Discard & Close"), GC again, and fail the run if _VirtualResultGridState, ResultsTab, QueryEditorTab or CompactResultDataset grew. Also print mounted-element counts next to live instances, which separates tabs that were not closed from tabs that leaked. Note that closing a dirty SQL tab opens a confirmation dialog, so a scripted close has to tap "Discard & Close".
Activity
ZhuchkaTriplesix commentedon Oct 12, 2026
Suggestion while fixing this scenario: add a leak check to the same harness. The method that found #1555 is small: after warm-up, force a full GC with
getAllocationProfile(gc: true), recordinstancesCurrentper class, repeat N x (run query in the same tab / open + close a tab with "Discard & Close"), GC again, and fail the run if_VirtualResultGridState,ResultsTab,QueryEditorTaborCompactResultDatasetgrew. Also print mounted-element counts next to live instances, which separates tabs that were not closed from tabs that leaked. Note that closing a dirty SQL tab opens a confirmation dialog, so a scripted close has to tap "Discard & Close".ci(bench): open the diagram through the workspace; the toolbar button…
ci(bench): erd_open_200 diagnoses itself; an aborted bench run fails …
fix(erd): the card cache compared a palette built anew on each read, …
perf(erd): opening a 200-table diagram no longer builds every card in…
ZhuchkaTriplesix commentedon Oct 23, 2026
Done in #1714 (bench diagnoses itself, aborted run fails the job) and #1715 (200-table diagram no longer builds every card in one frame).