Symptom
Re-uploading a CSV over an existing DataTable (the override path) can leave the table in a corrupted state: the table advertises the NEW schema while its dataFrameId still points at the OLD (or now-missing) frame data.
Where
packages/app/src/lib/local-csv-handler.ts (~line 93, override branches).
Both override branches persist the DataTable's name/schema/fields/metrics BEFORE replacing or creating the linked DataFrame. If replaceDataFrame / addDataFrameEntry fails after the table update, the mutation is not rolled back.
Impact
Downstream previews and insights resolve fields from the new schema against stale frame storage — silently wrong or broken results rather than a loud error.
Suggested fix
Stage the replacement frame first, then update the DataTable once (fields/sourceSchema/metrics/dataFrameId together), then best-effort delete the old frame. Or wrap in a transaction if the storage layer supports it.
Related (same file, lower severity)
handleFileConnectorResult (~line 171) derives a new DataTable's id from dataFrame.id, but the parser built Field objects against the caller-selected table id — the persisted DataTable can carry fields whose tableId doesn't match the table itself.
Found by automated feature review while touching adjacent code; both issues pre-date the change under review.
Tracked internally as YW-412.
Symptom
Re-uploading a CSV over an existing DataTable (the override path) can leave the table in a corrupted state: the table advertises the NEW schema while its
dataFrameIdstill points at the OLD (or now-missing) frame data.Where
packages/app/src/lib/local-csv-handler.ts(~line 93, override branches).Both override branches persist the DataTable's name/schema/fields/metrics BEFORE replacing or creating the linked DataFrame. If
replaceDataFrame/addDataFrameEntryfails after the table update, the mutation is not rolled back.Impact
Downstream previews and insights resolve fields from the new schema against stale frame storage — silently wrong or broken results rather than a loud error.
Suggested fix
Stage the replacement frame first, then update the DataTable once (fields/sourceSchema/metrics/dataFrameId together), then best-effort delete the old frame. Or wrap in a transaction if the storage layer supports it.
Related (same file, lower severity)
handleFileConnectorResult(~line 171) derives a new DataTable's id fromdataFrame.id, but the parser built Field objects against the caller-selected table id — the persisted DataTable can carry fields whosetableIddoesn't match the table itself.Found by automated feature review while touching adjacent code; both issues pre-date the change under review.
Tracked internally as YW-412.