| Previous | Next |
| FILTER_S_FULL_CONTENTSCAN_IMMEDIATE | FILTER_S_DISK_FULL |
FILTER_S_CONTENTSCAN_DELAYED
Content scan should be scheduled later
FILTER_S_CONTENTSCAN_DELAYED is HRESULT 268083 (0x00041733) from Indexing Service. AllStat describes it as “A content scan of the disk needs to be scheduled for execution later.” The severity bit indicates a nonfailure result, but the value carries a specific condition that must not be collapsed into plain S_OK.
In the legacy Indexing Service or IFilter pipeline, this result means that a content scan of the disk needs to be scheduled for execution later. Ordinary completion must not be inferred from it until the owning component’s state and outputs agree.
Where the status is encountered
- Legacy Indexing Service catalog processing; log the exact method and object state instead of interpreting the constant outside that contract.
- IFilter text and property extraction; log the exact method and object state instead of interpreting the constant outside that contract.
- Search enumeration, scan scheduling, or catalog administration; log the exact method and object state instead of interpreting the constant outside that contract.
Because it is informational, a language binding may expose it as success and hide the symbolic distinction. Keep the original HRESULT available until the code-specific branch has run.
Evidence and telemetry
- preserve scan scope and priority.
- preserve deferral reason.
- preserve not-before and deadline times.
- preserve queue persistence identifier.
- preserve resource condition used to release the delay.
Also record filter_s_contentscan_delayed_operation, filter_s_contentscan_delayed_state_before, filter_s_contentscan_delayed_state_after, UTC time, process and thread identifiers, component version, and a correlation ID. For privacy-safe it diagnostics, log metadata and fingerprints instead of confidential source values.
What must be true before accepting it
Verify that the deferral reason and latest acceptable execution time are explicit. Only this contract check establishes that it is safe for the caller’s next step.
The return of it can follow observable side effects, so recovery begins with state reconciliation.
Correct handling and recovery
Place the scan in a durable delayed queue, preserve its scope, and retry when the blocking load or resource condition clears. Do not treat delayed scheduling as completed indexing.
Retry it only when a documented input or state has changed. Before another call following it, confirm that completed side effects are idempotent or reconciled.
Difference from nearby results
It must be distinguished from ordinary S_OK and from failure-severity values in the same API family; its documented state changes control the next action.
A nearby HRESULT can change object ownership, output validity, or the permitted next method.
Practical scenario
An indexing host defers a low-priority content scan during peak query load. It retains the request and starts it in the next maintenance interval.
A regression test should reproduce it, assert the relevant outputs and state, then change only the decisive condition and verify the expected neighboring result or ordinary completion.
References
- Microsoft: Filter interface values — official Microsoft material used to interpret it.
- Microsoft: About Indexing Service filters
- Microsoft: Using custom filters
- Microsoft: HRESULT values
Looking for a different code? Search another status or error code.