Uh oh!
There was an error while loading. Please reload this page.
[fix](insert overwrite) delay overwrite partition routing until incremental open - #63209
Conversation
sollhui
commented
May 13, 2026
run buildall |
hello-stephen
commented
May 13, 2026
TPC-H: Total hot run time: 29460 ms |
hello-stephen
commented
May 13, 2026
TPC-DS: Total hot run time: 172487 ms |
hello-stephen
commented
May 13, 2026
BE Regression && UT Coverage ReportIncrement line coverage Increment coverage report
|
liaoxin01
commented
May 13, 2026
/review |
There was a problem hiding this comment.
Code review completed for PR 63209.
Summary opinion: no blocking issues found. The change is small and targeted: partition replacement now finishes the create-partition callback, including incremental open/open_wait, before publishing the new partition/tablet mapping into local routing. This matches the stated race and avoids exposing new tablet ids before the sender-side channels/streams are ready.
Critical checkpoint conclusions:
- Goal and proof: the code addresses the described auto-detect insert overwrite race, and the updated unit test verifies the callback runs before local replacement is visible.
- Scope: the modification is focused on callback/routing order plus a targeted test harness extension.
- Concurrency: the affected behavior is a routing publication race; this PR reduces the unsafe window by keeping old routing visible until incremental open completes. I did not find a new lock-order or dependency issue in the changed code.
- Lifecycle/static state: no new static/global lifecycle concerns were introduced.
- Configuration/compatibility: no new config, wire format, or storage-format compatibility changes.
- Parallel paths: both create-partition and replace-partition paths now publish routing after callback completion; V1/V2 writer callbacks consume the same result shape.
- Error handling: callback and add/replace failures are propagated with
RETURN_IF_ERROR; no ignored Status in the changed lines. - Tests: unit coverage was updated for the replace ordering. I did not run the BE unit test in this review environment.
- Observability/performance: no additional observability appears necessary for this small ordering fix; the extra copy in
cast_as_create_resultis not on a hot path and avoids moving from the original result before later use.
User focus: no additional user-provided review focus was specified.
hello-stephen
commented
May 14, 2026
BE Regression && UT Coverage ReportIncrement line coverage Increment coverage report
|
Uh oh!
There was an error while loading. Please reload this page.
…mental open (#63209) ### What problem does this PR solve? Problem Summary: In auto-detect insert overwrite, BE sender could publish newly replaced temporary partitions to local row routing before incremental open finished on target BEs. The race was: 1. One sender calls FE `replacePartition` and receives new temporary partition/tablet metadata. 2. The sender records the new partition id and replaces local `_vpartition` routing first. 3. Another concurrent batch can then route rows to the new tablet. 4. The first sender has not finished incremental open yet, so the target BE may not have created the delta writer for that tablet. 5. The target BE returns `unknown tablet to append data`. This PR makes the sender finish `_create_partition_callback`, including incremental open/open_wait, before publishing the new partition/tablet to local routing and marking the new partition as handled.
…mental open (#63209) ### What problem does this PR solve? Problem Summary: In auto-detect insert overwrite, BE sender could publish newly replaced temporary partitions to local row routing before incremental open finished on target BEs. The race was: 1. One sender calls FE `replacePartition` and receives new temporary partition/tablet metadata. 2. The sender records the new partition id and replaces local `_vpartition` routing first. 3. Another concurrent batch can then route rows to the new tablet. 4. The first sender has not finished incremental open yet, so the target BE may not have created the delta writer for that tablet. 5. The target BE returns `unknown tablet to append data`. This PR makes the sender finish `_create_partition_callback`, including incremental open/open_wait, before publishing the new partition/tablet to local routing and marking the new partition as handled.
…mental open (apache#63209) ### What problem does this PR solve? Problem Summary: In auto-detect insert overwrite, BE sender could publish newly replaced temporary partitions to local row routing before incremental open finished on target BEs. The race was: 1. One sender calls FE `replacePartition` and receives new temporary partition/tablet metadata. 2. The sender records the new partition id and replaces local `_vpartition` routing first. 3. Another concurrent batch can then route rows to the new tablet. 4. The first sender has not finished incremental open yet, so the target BE may not have created the delta writer for that tablet. 5. The target BE returns `unknown tablet to append data`. This PR makes the sender finish `_create_partition_callback`, including incremental open/open_wait, before publishing the new partition/tablet to local routing and marking the new partition as handled.
What problem does this PR solve?
Problem Summary:
In auto-detect insert overwrite, BE sender could publish newly replaced temporary partitions to local row routing before incremental open finished on target BEs.
The race was:
replacePartitionand receives new temporary partition/tablet metadata._vpartitionrouting first.unknown tablet to append data.This PR makes the sender finish
_create_partition_callback, including incremental open/open_wait, before publishing the new partition/tablet to local routing and marking the new partition as handled.Release note
None
Check List (For Author)
Test
Behavior changed:
Does this need documentation?
Check List (For Reviewer who merge this PR)