perf: eliminate schema_changes_alerts temp table to reduce concurrent DDL#1025
Conversation
… DDL Each schema_changes test was creating a __schema_changes_alerts__tmp persistent table solely as an intermediary step — store_schema_test_results read from it immediately and the test assertion selected from it directly. With many monitored sources running in parallel, this caused 74 simultaneous CREATE OR REPLACE TABLE DDL operations on the shared ELEMENTARY schema, which triggered a Snowflake internal metadata fault with a 245-second retry on one of the queries (confirmed via fault_handling_time in QUERY_HISTORY). The fix runs the alert query inline instead of materializing it, matching the existing pattern already used in test_schema_changes_from_baseline. This halves concurrent DDL from 74 to 37 per run. Resolves: CORE-1042 Related: CORE-1041 Co-authored-by: Cursor <cursoragent@cursor.com>
|
👋 @elazarlachkar |
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (1)
📝 WalkthroughWalkthroughThe ChangesSchema Changes Test Simplification
Estimated code review effort🎯 1 (Trivial) | ⏱️ ~3 minutes Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
…es_alerts__tmp-table-run
Summary
Each
schema_changestest was creating a__schema_changes_alerts__tmppersistent table solely as an intermediary —store_schema_test_resultsread from it immediately and the test assertion selected from it directly. This table served no purpose beyond being a short-lived middleman.With many monitored sources running in parallel (e.g. 37 sources × 2 tables = 74 simultaneous
CREATE OR REPLACE TABLEDDL operations on the sharedELEMENTARYschema), Snowflake's internal metadata catalog becomes overloaded. This triggered a non-actionable Snowflake fault with a 245-second retry on one query, confirmed viafault_handling_timeinACCOUNT_USAGE.QUERY_HISTORY:total_elapsed_timeexecution_timefault_handling_timepartitions_scanned > partitions_totalFix
Run the alert query inline instead of materializing it into a temp table — matching the pattern already used by
test_schema_changes_from_baseline, which has always worked this way.CREATE OR REPLACE TABLE __schema_changes_alerts__tmp AS {alert_query}→SELECT * FROM that_tableschema_changes_alert_querydirectly tostore_schema_test_resultsand return it as the test assertionstore_schema_test_resultsalready callsrun_query(sql)internally, so it handles a raw query string just as well as aSELECT * FROM table.Impact
Related
Test plan
test_schema_changesintegration test — should detect column_added, column_removed, type_changed as beforeelementary_test_resultsis populated correctly inon_run_end__schema_changes_alerts__tmptables are created in the Elementary schemaMade with Cursor
Summary by CodeRabbit