Fix batched file move watcher events

[gabrimatic]

Description

Fixes stale file tree entries after batched file move events. Linux can report multiple rename sources before their matching targets, and the watcher previously kept only one pending source path.

This queues pending rename sources and pairs them with rename targets in order, so multi-file mv file1 file2 subdir/ batches remove each old path and add each new path correctly.

Linked Issue

Fixes #9592

Testing

• cargo fmt --package watcher -- --check
• cargo test -p watcher pairs_batched_rename_from_and_to_events_in_order
• cargo test -p watcher
• cargo clippy -p watcher --all-targets -- -D warnings

[oz-for-oss]

@gabrimatic

I'm starting a first review of this pull request.

You can view the conversation on Warp.

I reviewed this pull request and requested human review from: @warpdotdev/oss-maintainers.

Comment /oz-review on this pull request to retrigger a review (up to 3 times on the same pull request).

Powered by Oz

[oz-for-oss]

Overview

This change factors the watcher event merge logic so it can be unit-tested against raw notify events, then queues RenameMode::From paths and consumes them FIFO when matching RenameMode::To events arrive. The added test covers the Linux-style batched from/from/to/to ordering described in the PR.

Concerns

• No blocking correctness or security concerns found in the changed lines.

Verdict

Found: 0 critical, 0 important, 0 suggestions

Approve

Comment /oz-review on this pull request to retrigger a review (up to 3 times on the same pull request).

Powered by Oz

[moirahuang]

overall this looks good to me! just a small comment and then i'll approve!

[moirahuang]

@gabrimatic mind attaching a video of you testing the original issue's use case please?

[moirahuang]

@gabrimatic fyi I am clarifying in the original issue about how to reproduce the issue #9592 (comment)

[gabrimatic]

@gabrimatic mind attaching a video of you testing the original issue's use case please?

warp-pr-10217-file-tree-move-review.mp4

[sergioanselmi]

Hello @moirahuang , I'm sending a video capture.
In @gabrimatic 's case, he seems to be using a Mac; I use Ubuntu.

Screenrecord_1_warpbug.mp4

[moirahuang]

@sergioanselmi thank you for the video! I asked my teammate @acarl005 to test on his Ubuntu 24.04.03 ARM in Parallels VM and he's not able to reproduce the issue your video. Do you mind sending over your logs please? https://docs.warp.dev/support-and-community/troubleshooting-and-support/sending-us-feedback/#gathering-warp-logs

Screen.Recording.2026-05-13.at.1.50.16.PM.mov

[sergioanselmi]

Hi @moirahuang, attaching the logs as requested.

I'm running Warp on Ubuntu 24.04 (x86_64). The issue reproduces consistently for me with basic mv + ls sequences in the file tree panel.

The reproduction steps performed during the logged session (~15:57–15:59 UTC-3) were:

1. touch file1
2. mkdir dir1
3. mv file1 dir1/
4. cd dir1 / cd ..
5. mv dir1/file1 .
6. ls -la — file tree panel shows stale entries (old paths not removed / new paths not reflected correctly)

Two files attached:
• warp-logs.tar.gz — full Warp application logs
• warp-session2.log — log entries filtered to the timeframe of the reproduction session

warp-session2.log
warp-logs.tar.gz

[moirahuang]

@sergioanselmi Thank you for the logs, they're really helpful! It looks like the actual reason why project explorer isn't showing your files is because Warp is failing to register filesystem watchers for the exact directories in your recording because the process has hit the max watch limit.

That explains why @acarl005 wasn't able to reproduce, he likely hasn't hit his watcher limit. I'm going to 1) close this PR since it's not addressing this issue 2) going to mark the original issue as needs-mocks. We need design input on how to surface this error to users.