jcoffey-dev
d5996f9209
Deleting a file queues the task that archives it for undelete. Files aren't search-indexed, so the file paths had never queued a task before, and none of them woke the task manager after writing it. The task waited for the manager's next periodic look at the queue, up to five minutes, unless other work happened to wake it first. FileNode/set and FileNode/copy, and WebDAV DELETE, COPY and MOVE now wake it after committing a deletion, as the calendar, contact and mail paths already do. The system and jmap suites each sat out one of those waits on every run, and the system suite's occasional LMTP timeout came right after it: they now take about 2.5 and 3 minutes instead of 7.5 and 8. Test: a new webdav check deletes files over WebDAV (DELETE, COPY and MOVE over a file) and JMAP, and needs the queue empty within 10 s. On main the WebDAV DELETE task was still queued after 10 s; taking out the JMAP or MOVE change alone fails its own step; with the change all pass.