Uh oh!
There was an error while loading. Please reload this page.
[branch-4.0][fix](file-cache) Make sync clear use safe removal #64578 - #64770
Conversation
(cherry picked from commit 874a1c4)
hello-stephen
commented
Jun 24, 2026
Thank you for your contribution to Apache Doris. Please clearly describe your PR:
|
gavinchou
commented
Jun 24, 2026
run buildall |
gavinchou
commented
Jun 24, 2026
/review |
There was a problem hiding this comment.
Requesting changes for cache-clear regressions introduced by the new safe sync-clear path.
Critical checkpoints:
- Existing inline review threads: none were present, so these are not duplicates.
- User focus: no additional user-provided focus was supplied.
- Changed-file sweep: reviewed all seven changed files and relevant cache removal, TTL bookkeeping, storage loading, and HTTP clear paths.
- Subagent conclusions: TEST-1 was accepted as M-1; OPT-1 was merged into M-2; OPT-2 was accepted as M-3; OPT-3 was accepted as M-4. Convergence round 2 ended with both live subagents reporting NO_NEW_VALUABLE_FINDINGS for this same final comment set.
| io::UInt128Wrapper hash = io::BlockFileCache::hash(segment_path); | ||
| io::BlockFileCache* cache = io::FileCacheFactory::instance()->get_by_path(hash); | ||
| cache->remove_if_cached(hash); | ||
| cache->remove_if_cached_async(hash); |
There was a problem hiding this comment.
The value-scoped clear path still accepts sync=true, but this branch now ignores it and always queues remove_if_cached_async. Before this change, clearing a single value used remove_if_cached, so callers such as op=clear&sync=true&value=... could rely on releasable blocks being physically removed before the HTTP request returned. With the async call the in-memory entry disappears immediately, but the cache file can remain in storage until background GC runs, which is a compatibility regression for the existing sync/value callers. Please preserve the sync flag here, e.g. use remove_if_cached(hash) when sync_clear is true and the async variant otherwise.
Uh oh!
There was an error while loading. Please reload this page.
| } | ||
| } | ||
| // we cannot delete the element in the loop above, because it will break the iterator |
There was a problem hiding this comment.
The new sync clear is only walking _files, so it no longer clears cache data that exists on disk but is not currently represented in memory. The old clear_file_cache_directly() called _storage->clear(), and FSFileCacheStorage::clear() sweeps the cache base path and deletes every cache subdirectory. With this replacement, any block that has not been loaded into _files yet, or any leftover cache/tmp directory that is not tracked in _files, survives a successful clear_file_caches(true) response. Please keep a storage-level sweep for the synchronous full clear path, or otherwise delete untracked files before reporting that the cache was cleared.
Uh oh!
There was an error while loading. Please reload this page.
gavinchou
commented
Jun 24, 2026
run buildall |
gavinchou
commented
Jun 24, 2026
run buildall |
1 similar comment
gavinchou
commented
Jun 24, 2026
run buildall |
gavinchou
commented
Jun 25, 2026
run buildall |
gavinchou
commented
Jun 25, 2026
/review |
There was a problem hiding this comment.
Automated review completed for PR 64770.
Critical checkpoints:
- Scope reviewed: all eight changed files plus the related full/value clear, factory, storage remove, holder cleanup, TTL bookkeeping, and HTTP response paths.
- Duplicate suppression: existing inline threads already cover the value-scoped sync regression, missing storage-level sweep for untracked files, stale TTL maps, and busy deleting blocks remaining discoverable.
- User focus: no additional review focus was provided.
- Tests: I did not run BE test binaries in this runner; the local checkout is shallow and does not contain a usable base/parent revision for a full local diff-check range. Review was based on the GitHub PR patch, current head files, and targeted code inspection.
Subagent conclusions:
- optimizer-rewrite proposed OR-1; I verified it independently, accepted it as M-1, and submitted it inline.
- tests-session-config reported no new valuable findings after reviewing tests, config/session compatibility, HTTP behavior, and style scope.
- Convergence round 1 ended with both live subagents replying NO_NEW_VALUABLE_FINDINGS for the same ledger and proposed final comment set.
Uh oh!
There was an error while loading. Please reload this page.
gavinchou
commented
Jun 25, 2026
run buildall |
gavinchou
commented
Jun 25, 2026
run buildall |
gavinchou
commented
Jun 25, 2026
/review |
There was a problem hiding this comment.
Automated re-review completed for PR 64770 at head 261cc88b6921fbf0a34abddc94477873f5338c1a.
Critical checkpoints:
- Scope reviewed: all eight changed files plus the related
FileCacheAction,FileCacheFactory,BlockFileCache,FileBlocksHolder, storage removal, TTL bookkeeping, cache lookup, and test paths touched by the sync/async clear changes. - Existing review context: all existing inline threads were treated as already-known issues. I did not submit duplicate comments for the already-raised storage sweep, busy/deleting block visibility, TTL map cleanup, sync remove failure propagation, or value-scoped
sync=truecompatibility regressions. - New findings from this pass: none distinct enough to submit as a new inline comment.
- User focus:
.code-review.DkRA02/review_focus.txtsays there is no additional user-provided review focus. - Repository instructions:
.code-review.DkRA02/review_prompt.txtwas followed; no requiredAGENTS.mdfiles were listed. The repo-local code-review skill path was not present in this checkout after targeted search, so the review followed the available review bundle workflow. - Verification:
git diff --checkwas clean for the PR range. No BE unit-test binaries were present in this checkout, so I did not run the new gtests locally.
Subagent conclusions:
optimizer-rewrite: no new valuable finding beyond existing inline threads.tests-session-config: no new valuable finding beyond existing inline threads.- Convergence round 1: both live subagents reviewed the same current ledger and zero-inline proposed final comment set and replied
NO_NEW_VALUABLE_FINDINGSafter the last main-ledger update.
Final opinion: this pass adds no new inline comments. The PR still has blocking cache-clear issues already represented by the existing CHANGES_REQUESTED review threads; this review is submitted as a summary-only comment to avoid duplicating them.
hello-stephen
commented
Jun 25, 2026
BE Regression && UT Coverage ReportIncrement line coverage Increment coverage report
|
1 similar comment
hello-stephen
commented
Jun 25, 2026
BE Regression && UT Coverage ReportIncrement line coverage Increment coverage report
|
hello-stephen
commented
Jun 25, 2026
BE Regression && UT Coverage ReportIncrement line coverage Increment coverage report
|
Uh oh!
There was an error while loading. Please reload this page.
Backport #64578 to branch-4.0.
Changes:
Validation: