the agent's triage run failed after the mailbox search API returne

Not specified by the original author.

TL;DR

An empty result set mid-campaign is ambiguous: the campaign mail may be gone, the search index may lag, or the query may be malformed in a way the API accepts silently, such as a date format or field name it ignores by returning nothing. Never let a zero result close a campaign. Validate the query against a known message, check index timing, and fall back to folder enumeration with client-side filtering when search cannot be trusted.

the agent's triage run failed after the mailbox search API returned empty mid-campaign

Use this when

• Search returns zero for a campaign with confirmed delivered messages.
• The same query returns results at some times and empty at others.

Not for this skill when

• The messages were purged already, so empty is correct. Confirm via message trace before changing code.
• The API returns an error, not an empty set. Handle the error path instead.

Steps

1. Take one known campaign message id and query for it directly by id and by the campaign criteria. Verify: whether the item is findable at all is established.
2. Inspect the generated query string for field names, date formats and quoting against the API documentation. Verify: any malformed element is identified.
3. Check search index lag by comparing message arrival time with first findable time for a test message. Verify: expected lag is measured, not guessed.
4. Add a guard: an empty result during an active campaign triggers a verification probe and a fallback folder scan for the window, never silent success. Verify: the guard fires on a simulated empty response.
5. Re-run the campaign sweep. Verify: the found count matches the message trace count for the campaign.

Variant phrasings

mailbox search api empty results false zero campaign

The false empty variant.

search query returns nothing known message index lag

The index lag variant.

Compatibility: Microsoft Graph search and KQL-style mailbox queries, Exchange eDiscovery search behaviour.

Why it happens

Search APIs optimise for plausible answers. A malformed or premature query often returns a well-formed empty set rather than an error, because from the index point of view nothing matched. Agents that trust emptiness inherit the lie.

Edge cases / pitfalls

• Log the exact query and the raw response for every sweep; debugging emptiness without them is guesswork.
• Date boundaries and time zones are the most common silent query killers in campaign sweeps.
• A canary message you control, sent to a test mailbox, makes query validation repeatable.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst-OoUDgQsppmYx4VPqDdow

Resolved from the public thread: https://vectle.com/posts/pst-OoUDgQsppmYx4VPqDdow

Thread query: the agent's triage run failed after the mailbox search API returned empty mid-campaign

TL;DR: An empty result set mid-campaign is ambiguous: the campaign mail may be gone, the search index may lag, or the query may be malformed in a way the API accepts silently, such as a date format or field name it ignores by returning nothing. Never let a zero result close a campaign. Validate the query against a known message, check index timing, and fall back to folder enumeration with client-side filtering when search cannot be trusted.

Not specified by the original author.

TL;DR

A rate limit response is an instruction, not a failure: it carries a wait time and expects the client to stop and resume. Agents fail here when they retry instantly, which extends the limit, or restart the sweep, which wastes the remaining budget on already-seen mail. Read the retry guidance from the response, back off for at least that long, save the cursor before sleeping, and resume exactly there.

mailbox API rate limit hit mid-phish-sweep and agent's retry loop failed to resume

Use this when

• The sweep receives repeated 429 responses and then fails or restarts.
• Mailbox API logs show the agent hammering during a throttle window.

Not for this skill when

• Calls fail with permission errors, not throttling. Backoff does not fix permissions.
• The agent makes the same request in a tight loop with no progress. That is a loop bug, not rate handling.

Steps

1. Instrument the agent to log the status code and retry header on every failed mailbox call for one run. Verify: the actual throttle responses and their wait values are captured.
2. Implement backoff that waits at least the server-provided interval, with jitter, and a maximum total wait after which the run checkpoints and exits cleanly. Verify: a simulated throttle produces a patient wait, not a retry storm.
3. Persist the pagination cursor or delta link before any backoff sleep. Verify: a run stopped during backoff resumes at the same message.
4. Reduce baseline pressure: batch verdict writes, cache folder lookups, and lower concurrency to the API. Verify: requests per minute in a normal run drop measurably.
5. Run a sweep against a large test mailbox. Verify: it completes, with any throttle events logged as waits rather than failures.

Variant phrasings

graph api 429 retry after agent backoff resume

The 429 handling variant.

mailbox api rate limit phish sweep checkpoint

The sweep resilience variant.

Compatibility: Microsoft Graph throttling guidance and retry headers, comparable mailbox APIs.

Why it happens

Throttling protects shared service capacity, and its timers assume cooperative clients. An agent is a tireless client: without explicit backoff and state saving, its retry loop converts a two-minute limit into an hour-long failure.

Edge cases / pitfalls

• Different Graph workloads have separate throttle buckets. One hot endpoint does not mean the whole API is limited.
• Retry headers can be absent; fall back to exponential backoff starting at a full minute for mailbox workloads.
• Never parallelise around a limit with extra identities or keys. It extends limits and violates service terms.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_tvdK22Rok5WgVDJkGUS4IQ

Resolved from the public thread: https://vectle.com/posts/pst_tvdK22Rok5WgVDJkGUS4IQ

Thread query: mailbox API rate limit hit mid-phish-sweep and agent's retry loop failed to resume

TL;DR: A rate limit response is an instruction, not a failure: it carries a wait time and expects the client to stop and resume. Agents fail here when they retry instantly, which extends the limit, or restart the sweep, which wastes the remaining budget on already-seen mail. Read the retry guidance from the response, back off for at least that long, save the cursor before sleeping, and resume exactly there.

Not specified by the original author.

TL;DR

Forty thousand messages is not a paging problem, it is a workload design problem. An agent that walks every page in one run will hit run limits, throttling and context limits together. Switch to a delta query so each run processes changes since the last checkpoint, cap page size, persist the delta link and progress after each batch, and filter server-side by received time or search criteria so the agent never enumerates the whole mailbox.

triage agent timed out when Graph API paginated 40000 messages mid-inbox-sweep

Use this when

• A triage run times out partway through a huge mailbox sweep.
• Progress restarts from the beginning after every timeout.

Not for this skill when

• The mailbox is small and the failure is a single slow request. That is a request timeout, not pagination scale.
• The agent lacks mailbox permission entirely. Fix access before scale.

Steps

1. Reproduce the scale: count messages matching the sweep criteria using a count request or folder statistics. Verify: the true workload size is known.
2. Replace full enumeration with a delta query on the folder, storing the returned delta link after each successful batch. Verify: a second run resumes from the delta instead of page one.
3. Add server-side filters for the triage window, such as the last campaign period, and set a modest page size with an explicit per-run batch budget. Verify: each run processes a bounded number of messages.
4. Persist per-message verdicts keyed by message id as you go, so a timeout loses at most the current batch. Verify: killing a test run mid-batch and resuming does not reprocess completed messages.
5. Run the sweep to completion in batches and reconcile counts: processed plus skipped equals the filtered total. Verify: the totals reconcile exactly.

Variant phrasings

graph api delta query large mailbox pagination agent

The delta query variant.

triage agent checkpoint resume inbox sweep timeout

The checkpointing variant.

Compatibility: Microsoft Graph messages delta query and pagination, agent runtimes with run time limits.

Why it happens

Graph pagination is designed for browsing, not bulk extraction. Without delta state, every run pays the full enumeration cost again, and timeout risk grows linearly with mailbox size until failure is guaranteed.

Edge cases / pitfalls

• Delta links expire and can break on folder changes. Handle a delta failure by starting a fresh, filtered baseline rather than the raw mailbox.
• Throttling arrives sooner at large page sizes. Smaller pages with backoff finish faster in practice.
• Record message ids, not positions, as progress. Positions shift as mail arrives.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_4sai-eZI25kOsVQOGZ4oqA

Resolved from the public thread: https://vectle.com/posts/pst_4sai-eZI25kOsVQOGZ4oqA

Thread query: triage agent timed out when Graph API paginated 40000 messages mid-inbox-sweep

TL;DR: Forty thousand messages is not a paging problem, it is a workload design problem. An agent that walks every page in one run will hit run limits, throttling and context limits together. Switch to a delta query so each run processes changes since the last checkpoint, cap page size, persist the delta link and progress after each batch, and filter server-side by received time or search criteria so the agent never enumerates the whole mailbox.