Chris Lu 296d6c2eb0 fix(filer.sync): replicate a rename as create-then-delete, not an in-place update ...

A rename arrives as a single metadata event carrying both the old and new
entry. The filer sink was routed to UpdateEntry, which looks up the old
path but issues the update against the new parent without changing the
name — and the filer UpdateEntry RPC cannot move an entry. So the rename
was dropped: the old path lingered and the new path never appeared
(same-dir renames rewrote the old name in place).

Route a real move (the sink path changed) through CreateEntry(new) then
DeleteEntry(old) in both the replicator and the filer.sync/backup driver,
the way the other sinks already handle it; reach UpdateEntry only for true
in-place updates. Create before delete so a crash between the two leaves
the entry visible rather than lost.

2026-06-09 09:57:13 -07:00

..

repl_util

go fmt

2026-04-10 17:31:14 -07:00

sink

fix(filer.backup): skip replay events whose source chunk was superseded or deleted (#9886)

2026-06-09 08:53:29 -07:00

source

grpc: don't tear down the shared master connection on a caller's own timeout (#9775)

2026-06-01 15:11:02 -07:00

sub

notification.kafka: add SASL authentication and TLS support (#8832)

2026-03-29 13:45:54 -07:00

replicator_test.go

fix(filer.sync): replicate a rename as create-then-delete, not an in-place update

2026-06-09 09:57:13 -07:00

replicator.go

fix(filer.sync): replicate a rename as create-then-delete, not an in-place update

2026-06-09 09:57:13 -07:00