chore(core): fix WalPurgeJob error on concurrent table drop - #6898
Conversation
|
Important Review skippedAuto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
WalkthroughThe pull request broadens exception handling in tenant pool creation and WAL purge logic to catch Changes
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes Suggested labels
Suggested reviewers
🚥 Pre-merge checks | ✅ 2 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (2 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
|
@coderabbitai review |
✅ Actions performedReview triggered.
|
catch(Throwable) risked silently swallowing Error types (e.g. OutOfMemoryError) when a table happened to be dropped. Narrow to the two exception types the concurrent-drop race actually produces: CairoException (normal path) and NullPointerException (when txFile is nulled mid-refresh). Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
[PR Coverage check]😍 pass : 3 / 3 (100.00%) file detail
|
Summary
getTableMetadata() fails for a concurrently dropped table. A concurrent drop can close
the metadata pool tenant's txFile during refresh, causing NullPointerException rather
than CairoException.
newTenant path, so the pool slot is always released on failure.
Test plan
FilesFacade.openRO to drop the table and throw NPE during metadata tenant creation
inside the purge job. Verified: fails without the fix, passes with it.
An instance of the error we are fixing: