Antalya 26.1: Fix rescheduleTasksFromReplica#1568
Conversation
|
@codex review |
|
Codex Review: Didn't find any major issues. Already looking forward to the next diff. ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
If Codex has suggestions, it will comment; otherwise it will react with 👍. Codex can also answer questions or update the PR. Try commenting "@codex address that feedback". |
There was a problem hiding this comment.
Just for the record
AI audit note: This review comment was generated by AI.
Audit update for PR #1568 (Fix rescheduleTasksFromReplica):
Confirmed defects
No confirmed defects in reviewed scope.
The change is correct:
std::move(processed_file_list_ptr->second)safely transfers list ownership to a local variable;std::listmove leaves the source empty and well-defined.processed_file_list_ptr(a map iterator) is invalidated by the subsequenterase, but is never dereferenced after that point.getReplicaForFileis called within the mutex-held region, iterating overreplica_to_files_to_be_processedwhich now correctly excludes the lost replica, so rendezvous hashing picks the best surviving replica.- The
replica_to_files_to_be_processed.size() < 2guard on line 307 still executes before the erase, correctly verifying at least one other replica remains.
Coverage summary
- Scope reviewed:
rescheduleTasksFromReplica(changed function),getReplicaForFile(callee),getNextTask/getPreQueuedFile/getMatchingFileFromIterator/getAnyUnprocessedFile(concurrent accessors),RemoteQueryExecutor::processPacket(caller onConnectionLost), class header and all member data structures. - Categories passed: move-semantics safety, iterator invalidation, logical correctness of erase-before-hash, RAII/resource leaks, integer types, exception safety within the function, mutex coverage within
rescheduleTasksFromReplica, rollback/partial-update (single-function scope, all mutations under one lock). - Categories failed: none.
- Pre-existing issue noted (not introduced by this PR):
getNextTaskaccessesreplica_to_files_to_be_processedat lines 52 and 70 without the mutex, whilerescheduleTasksFromReplicamutates it under the mutex.getMatchingFileFromIteratorcallsgetReplicaForFile(which iterates the same map) at line 197 without the mutex. These are data races that can lead to use-after-free if a replica's in-flightgetNextTaskoverlaps withrescheduleTasksFromReplicafor the same replica. This PR does not introduce or worsen this race in any meaningful way. - Assumptions/limits: audit is static-only; no test for
rescheduleTasksFromReplicawas found in the test suite (gtest_rendezvous_hashing.cppcoversgetNextTaskonly).
|
AI audit note: This review comment was generated by AI (gpt-5.3-codex). Audit update for PR #1568 ( Confirmed defectsNo confirmed defects in reviewed scope. Coverage summary
|
QA Verification1. Code reviewTwo independent AI audit reviews conducted on the changed function and adjacent call paths ( References: #1568 (review), #1568 (comment). 2. CIAll CI builds and tests passed. The only regression failure is 3. Related regression coverageA swarms regression scenario covering VerdictConsidering this is a small, focused change confirmed by the audit reviews and a green CI, this PR can be considered safe to merge. Adding |
Changelog category (leave one):
Changelog entry (a user-readable short description of the changes that goes to CHANGELOG.md):
Fix rescheduleTasksFromReplica
Documentation entry for user-facing changes
Fix incorrect change from c523f29
getReplicaForFileusesreplica_to_files_to_be_processedto find best replica for file, With removing lost replica aftergetReplicaForFilecall,getReplicaForFilechooses the same replica, so rescheduling makes no sense, files will be choosen only ingetAnyUnprocessedFileand executed on random replicas.This PR fixes the order, now files are matched with new best replicas.
CI/CD Options
Exclude tests:
Regression jobs to run: