fix: skip stale merge scheduler todo - #24449
Merged
mergify[bot] merged 4 commits intoMay 27, 2026
Merged
Conversation
Qodo reviews are paused for this user.Troubleshooting steps vary by plan Learn more → On a Teams plan? Using GitHub Enterprise Server, GitLab Self-Managed, or Bitbucket Data Center? |
aptend
force-pushed
the
fix/24446-merge-scheduler-nil-supp
branch
from
May 19, 2026 03:17
f8cb00a to
357f77b
Compare
aptend
force-pushed
the
fix/24446-merge-scheduler-nil-supp
branch
from
May 19, 2026 03:20
357f77b to
267c07d
Compare
aptend
force-pushed
the
fix/24446-merge-scheduler-nil-supp
branch
from
May 19, 2026 03:34
4fe3289 to
6ebdc63
Compare
This was referenced May 19, 2026
heni02
pushed a commit
that referenced
this pull request
May 20, 2026
## What type of PR is this? - [ ] API-change - [x] BUG - [ ] Improvement - [ ] Documentation - [ ] Feature - [x] Test and CI - [ ] Code Refactoring ## Which issue(s) this PR fixes: issue #24446 Backport of #24449 to v3.0.6-hotfix-20260321. ## What this PR does / why we need it: Merge scheduler can keep stale todos in its priority queue after repeated table metadata commits enqueue multiple todos for the same table. If a later DROP removes the table supporter from `supps`, `doSched` may still peek an older todo from the queue and panic when it assumes the supporter exists. This PR skips stale todos whose supporter has already been removed, removing them from the priority queue so the scheduler does not keep peeking the same stale item. It also adds coverage for the nil-supporter path. Test: ``` CGO_CFLAGS="-I/home/mo/matrixone/thirdparties/install/include" CGO_LDFLAGS="-L/home/mo/matrixone/thirdparties/install/lib" LD_LIBRARY_PATH="/home/mo/matrixone/thirdparties/install/lib:${LD_LIBRARY_PATH}" go test -mod=mod ./pkg/vm/engine/tae/db/merge ```
XuPeng-SH
approved these changes
May 26, 2026
Contributor
Merge Queue Status
This pull request spent 8 hours 53 minutes 7 seconds in the queue, with no time running CI. Waiting for
All conditions
ReasonThe merge conditions cannot be satisfied due to failing checks HintYou may have to fix your CI before adding the pull request to the queue again. |
1 task
Contributor
Merge Queue Status
This pull request spent 1 hour 5 minutes 43 seconds in the queue, including 1 hour 4 minutes 27 seconds running CI. Required conditions to merge
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What type of PR is this?
Which issue(s) this PR fixes:
fixes #24446
What this PR does / why we need it:
TableEntry.ApplyCommitnotifies the merge scheduler throughOnCreateTableCommitwhenever the latest table metadata node is not dropped. This is not limited to the initial CREATE TABLE path: metadata changes such as ALTER TABLE can also commit a non-dropped table node and enqueue another merge todo for the same table ID.When the table is later dropped, one queued todo can observe
HasDropCommitted(), remove the table supporter fromsupps, and leave another old todo for the same table ID behind. When that stale todo is scheduled later,a.supps[todo.table.ID()]is nil. The old code dereferenced it viasupp.mergingTaskCnt, causing a TN panic and restart.This PR drops such stale todos when their supporter is already gone, so the scheduler neither panics nor keeps peeking the same invalid queue item. It also adds a regression test for the nil-supporter path.
Tested with: