mirror of
https://github.com/seaweedfs/seaweedfs.git
synced 2026-11-04 11:07:35 +01:00
Chris LuandClaude Opus 5.5
cadb614630
* filer.sync: pass the replayed entry down to the chunk retry gates The fetch, manifest-resolve, and manifest-upload retry gates only received the replayed version's mtime, which is not enough to order it against the live source entry. Pass the entry itself; the gates still compare mtime only, so behavior is unchanged. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * filer.sync: stop chunk retries with the same supersession check the skip uses The fetch, manifest-resolve, and manifest-upload retry gates stopped early only for a gone or strictly newer source entry. A transient error therefore kept retrying a version the source had rewritten under an older mtime until the read recovered, while a live lookup that lags the replay could stop the retries on its newer mtime alone. The error handler that runs once a gate stops already decides with sourceMovedOn, which orders by commit timestamp and compares chunk sets; the gates now use it too, and hasSourceNewerVersion has no callers left. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * filer.sync: a lagging live lookup cannot prove a chunk dropped A peer filer's event reaches subscribers before the source store applies it, so the live lookup can return the version the replay replaces. That entry never listed the replay's new chunk, so sourceDroppedChunk read a 404 on it as an obsolete version and cut the missing-chunk wait short. Like sourceVersion, it now ignores a live entry committed before the replayed version. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * filer.sync: test that a replicate failure on a superseded version is skipped Covers onReplicateChunkError with a transient error for a deleted source entry, a later commit with an older mtime, and an unchanged source, and points the unconfirmed-supersession test comment at it instead of the helper test. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * filer.sync: test the manifest gate against a missing volume and a lagging lookup Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
How replication works ====== All metadata changes within current cluster would be notified to a message queue. If the meta data change is from other clusters, this metadata would change would not be notified to the message queue. So active<=>active replication is possible. All metadata changes would be published as metadata changes. So all mounts listening for metadata changes will get updated.