Overflow of FETCH Placeholder callback requests inside cloud filter api

Hi @Hangkun Ung ,

Thanks for the detailed description. I built a minimal provider on the real Cloud Filter API to test this and checked the public documentation.

The documentation doesn't describe a limit on pending callbacks, an overflow condition, or a case where the platform drops a FETCH_PLACEHOLDERS request, so I can't confirm or rule out an overflow from the documented contract. What it does state is that FETCH_PLACEHOLDERS is raised for a directory query or an open under the directory, that every callback request has a fixed 60-second timeout, and that a valid operation on any pending request from the provider resets the timers of all pending requests (CF_CALLBACK_TYPE). With CF_POPULATION_POLICY_FULL, the platform asks for all entries before completing the user request (CF_POPULATION_POLICY_PRIMARY). Reporting progress to reset that timer without completing the request is documented only for FETCH_DATA (CfReportProviderProgress).

In my tests on Windows 11 build 26300.9457, the result closest to your symptom wasn't an overflow. Process A looked up a child in a folder while my provider deliberately held the callback, then process B accessed the same folder. Only A produced a callback, yet both A and B failed with 0x800701AA after about 60.7 seconds. A sibling folder opened in 4.2 ms during that time, and a retry succeeded in 2.4 ms once the provider answered. In Explorer, my provider log showed the callback from explorer.exe arriving, and Explorer displayed the same cloud operation timeout message. So a requester with no callback of its own in your log isn't, by itself, evidence that a callback was lost. It may be waiting on a request that is already pending for that folder.

Bursts alone didn't reproduce the issue. 256 concurrent enumerations into different folders all completed, and 24 concurrent enumerations into the same folder produced a single callback with all 24 requesters succeeding. Two things did make a difference. Blocking inside the callback for 1 second delayed an unrelated requester by about 1.94 seconds, while handing the work to a worker thread kept it at about 5 ms. Completing with zero entries, a total count of 0 and no CF_OPERATION_TRANSFER_PLACEHOLDERS_FLAG_DISABLE_ON_DEMAND_POPULATION produced 256 callbacks in about 50 ms followed by 0x80070781, which matches the repeated-callback note in CF_OPERATION_TRANSFER_PLACEHOLDERS_FLAGS. These are observations from my environment, not documented behavior.

To narrow it down on your side, I'd suggest the following:

1. Log every callback at entry, before any lock, dedupe, or queue in your engine: timestamp, thread ID, path, FileId, TransferKey, RequestKey, and the requesting process. Connecting with CF_CONNECT_FLAG_REQUIRE_PROCESS_INFO and CF_CONNECT_FLAG_REQUIRE_FULL_FILE_PATH gives you the process and the full path (CF_CONNECT_FLAGS). When the error appears, look for an earlier FETCH_PLACEHOLDERS on the same folder from any process, including SearchProtocolHost.exe, that was never completed.
2. Log every CfExecute for that folder with its CompletionStatus, flags, counts and returned HRESULT, and log CANCEL_FETCH_PLACEHOLDERS as well. This shows whether the pending request was completed, rejected or cancelled, and whether your engine released ownership afterwards.
3. Keep the callback itself short and run the backend work on separate threads. Callbacks are invoked on thread pool threads and can run simultaneously (CF_CALLBACK_TYPE), and CfExecute can be called from any thread in the provider process (CfExecute).
4. While a folder is stuck, take a snapshot of both sides before anything recovers. Call CfGetPlaceholderInfo on the folder to record its placeholder state, and capture a dump of your provider process with ProcDump, for example procdump -ma <provider PID>. The dump shows whether your callback threads are blocked, waiting on a lock, or idle at that moment.
5. Capture the folder open with Process Monitor to see the requesting process, result and stack, and record a trace with the Minifilter I/O activity profile in Windows Performance Recorder. Opening the trace in Windows Performance Analyzer shows where the time is spent and how long the request stays in cldflt.sys.
6. Run fltmc filters and fltmc instances from an elevated prompt on an affected machine to list the other minifilters attached to the same volume (Tools for minifilter development and testing). If antivirus or DLP filters are present, repeating the test with the sync root excluded from them helps rule them in or out.

As for looking inside what the Cloud Filter API receives and sends, I couldn't find a publicly documented trace provider for the cloud files filter internals. The public tools show the two edges: file system activity on one side, and your provider's callbacks and CfExecute calls on the other. If the entry log and these traces show a request that never reaches your provider, I'd suggest filing it through Feedback Hub (Windows logo key + F) under the Developer Platform category with the capture attached, so the team that owns the component can review it.

There are some limitations to my testing. My provider is minimal, runs without your backend, and the bursts were synthetic. Windows Search was running, but I didn't capture any callback from SearchIndexer.exe or SearchProtocolHost.exe, so the exact indexer scenario remains unreproduced.

I hope this helps clarify the available documentation and the appropriate next step. If you found my response helpful or informative, I would greatly appreciate it if you could follow this guide or provide your insights.

Thank you.