FullSchemaMergeInsertExec::split_updates_and_inserts runs its batch loop on a detached tokio::spawn task that owns both channel senders. A panic inside that task unwinds it, drops the senders, and the update and insert receivers yield None. That is indistinguishable from a source that ended normally. The JoinHandle is dropped, so nothing observes the panic either.
Depending on where the panic lands, the writer then either commits a partial merge or trips an unrelated unwrap further down. Neither outcome reports what actually happened. The explicit error path forwards through handle_stream_processing_error; only the panic path has no route out.
Reproducer: poison the updating_row_ids mutex so the splitter panics when the first UpdateAll row reaches the capture call. The update stream returns Ok([]) rather than an error, so as far as the writer is concerned the source simply ran out of rows.
Reproduced on main at ebba5814c.
FullSchemaMergeInsertExec::split_updates_and_insertsruns its batch loop on a detachedtokio::spawntask that owns both channel senders. A panic inside that task unwinds it, drops the senders, and the update and insert receivers yieldNone. That is indistinguishable from a source that ended normally. TheJoinHandleis dropped, so nothing observes the panic either.Depending on where the panic lands, the writer then either commits a partial merge or trips an unrelated unwrap further down. Neither outcome reports what actually happened. The explicit error path forwards through
handle_stream_processing_error; only the panic path has no route out.Reproducer: poison the
updating_row_idsmutex so the splitter panics when the firstUpdateAllrow reaches the capture call. The update stream returnsOk([])rather than an error, so as far as the writer is concerned the source simply ran out of rows.Reproduced on
mainatebba5814c.