fix(community): skip purged comments in postUpdates MFS sync#143
Merged
Conversation
A sync cycle can capture a post's CommentUpdate while the post is still live, then a concurrent purge (storeCommentModeration) deletes the post from the DB and removes its postUpdates MFS entry. The in-flight sync then wrote the captured update back to MFS, resurrecting the purged post permanently — it is gone from the DB, so nothing ever cleans it up again. syncPostUpdatesWithIpfs now filters out post-update rows whose comment no longer exists in the DB (new DbHandler.commentExistsInDb) before writing, so a row captured before a mid-cycle purge is skipped instead of resurrecting the post. Adds a deterministic regression test driving the capture -> purge -> stale-write ordering. Fixes #142
|
Caution Review failedPull request was closed or merged during review 📝 WalkthroughWalkthroughThis PR fixes a race condition where purged posts could be resurrected in IPFS MFS during concurrent sync operations. A new database existence check enables the sync path to filter out stale updates, and a regression test validates the fix. ChangesPurge vs PostUpdates Sync Race Fix
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches📝 Generate docstrings
🧪 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 |
3 tasks
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
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.
Problem
A TOCTOU race between comment purge and the postUpdates MFS sync can leave a purged post's
CommentUpdatepermanently in a community'spostUpdatesMFS tree.syncIpnsWithDb(sync loop) andstoreCommentModeration(pubsub challenge handler) run concurrently with no mutual exclusion:CommentUpdate(post still in DB), producing a row withlocalMfsPath = /<addr>/postUpdates/<bucket>/<postCid>/update.rmUnneededMfsPaths, which also drains_mfsPathsToRemove).syncPostUpdatesWithIpfsand writes the captured (pre-purge) row back to MFS.Because the post is now gone from the DB it is never recalculated or re-purged, and nothing scans the MFS tree against the DB (
calculateNewPostUpdatesonly reads bucket dirs), so the resurrected entry persists indefinitely.This surfaced as a flaky failure in the
remote-libp2pjsCI config (the slower client transport widens the timing window so the purge lands mid-sync); the Kubo-RPC / gateway configs run the same community-side code and pass:Fix
syncPostUpdatesWithIpfsnow filters out post-update rows whose comment no longer exists in the DB (new lightweightDbHandler.commentExistsInDb(cid)) before writing to MFS. A row captured before a mid-cycle purge is skipped instead of resurrecting the purged post. When every captured post was purged, it writes nothing instead of throwing.Test
test/node/community/purge-postupdates-sync-race.test.tsdrives the exact racy ordering (capture row -> purge -> stale sync write) and asserts the purged post is not resurrected in MFS. It is red against unmodifiedsrc/and green with the fix. The happy-pathlocal.publishing.community.test.ts(posting -> postUpdates sync) still passes.Fixes #142
Summary by CodeRabbit
Bug Fixes
Tests