Pengzna opened a new pull request, #17335:
URL: https://github.com/apache/iotdb/pull/17335
## Summary
This PR fixes an IoTConsensusV2 replica inconsistency under concurrent
write/read plus CLI `DELETE`.
Root cause:
- a `PipeTsFileInsertionEvent` could be created before the corresponding
`.mods` file was generated by delete
- the event captured mod presence as a creation-time snapshot
- later tsfile transfer could miss the late-created mod file
- if a follower applied `delete(N)` first and loaded `tsfile(N+1)` later,
deleted data could become visible again on that follower
## Changes
- make `PipeTsFileInsertionEvent` refresh mod visibility dynamically instead
of freezing `isWithMod/modFile` at construction time
- preserve the "should transfer mod" intent across shallow copies
- update IoTConsensusV2/thrift sink handlers to decide transfer by a single
`getModFile()` snapshot
- add a regression test covering late-created mod visibility after shallow
copy
## Verification
Executed:
```bash
./mvnw -pl iotdb-core/datanode -am \
-Dtest=org.apache.iotdb.db.pipe.event.PipeTsFileInsertionEventTest \
-Dsurefire.failIfNoSpecifiedTests=false -DfailIfNoTests=false \
test -DskipITs
```
Result: `BUILD SUCCESS`
## Notes
A separate potential issue still exists in the historical deletion path:
`supplyDeletionEvent(...)` does not assign `replicateIndexForIoTV2`. That is
not the root cause of this incident, because the problematic delete in the
collected logs was clearly replicated and processed successfully with
`replicateIndex=160`.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
