Direct answer
Test sync failures with a small known dataset and a controlled sequence of provider responses. Exercise pagination, throttling and restart behavior separately before combining them. Assert the final document set, duplicate handling and checkpoint state. Reset both systems between cases, bound retries and record which endpoint behavior your environment can represent.
The documents were written. The checkpoint was not.
A hypothetical connector reads four documents across two pages. It writes the second page to its search index, then crashes before committing its progress. On restart it fetches that page again. The HTTP requests succeed, but an append-only write path creates duplicate index entries.
Place the interruption between the index write and checkpoint commit. Restart without resetting the application, because this case needs the partially completed state. Check the final identifiers, completion marker and retry log. Reset both systems only when starting a separate test case.
The connector’s storage and checkpoint design determine the recovery rule. Repeated reads may be valid. Repeated documents in the final index may violate the application requirement. Do not require exactly one HTTP request when replay is part of the recovery design.
This guide addresses a connector that synchronizes an index. A document-discovery or classification job may only enumerate and read files. Select checks for that job; do not add delta-token recovery unless the connector uses delta synchronization.
Separate provider rules from application requirements.
What the connector receives
Pages, continuation links and failures in a recorded order. Microsoft Graph’s paging guidance says to follow the returned nextLink URL; resource-specific behavior still needs checking.
Where the process resumes
The index, checkpoint and queued work at the interruption. A clean restart from empty data would miss the write-before-checkpoint failure.
What must hold after recovery
The expected IDs and content are present, prohibited duplicates are absent and completion is recorded at the right time for this connector.
A small sync regression matrix.
Scroll sideways to see all columns.
| Case | Provider or process condition | Application check |
|---|---|---|
| Normal pagination | Two pages, then no continuation link | All four expected IDs present; no extra documents; completion recorded |
| Empty intermediate page | Empty page with a valid continuation link, where the endpoint permits it | The connector follows the link instead of stopping at the empty page |
| One throttled request | Page two returns 429 with a stated Retry-After delay, then succeeds | No early retry; all IDs present after recovery; completion was not recorded early |
| Retry budget exhausted | Throttling continues beyond the test’s agreed deadline | The connector exposes incomplete work and retains enough state for the next attempt |
| Crash after write | Stop after the page is written but before progress is committed | Restart safely reprocesses the page; no duplicate index entries |
| Uncovered permission change | Access changes during the run; behavior not yet established | Mark coverage unavailable and assign an investigation; do not report a pass |
Make the failure point explicit.
- 01
Choose a fixed dataset
Use invented IDs A, B, C and D with known content. Record which records the test identity can read. Keep concurrent writes out of this first case.
- 02
Check the endpoint contract
Record pagination and retry guidance for the endpoint in use. Graph can return an empty page with a continuation link. Do not generalize one provider’s behavior to another.
- 03
Add one failure at a time
Run the normal case first. Then add a throttle or a process interruption at a named point. Use an injected test clock for backoff checks where practical; record that it differs from wall-clock execution.
- 04
Check during and after recovery
Inspect partial state before the retry and final state afterward. For Graph throttling, check the documented Retry-After handling. Also test repeated throttling against your job’s time budget.
- 05
Repeat from a clean baseline
Reset provider scenarios, index, checkpoint and queue before each independent case. Give parallel CI jobs separate state. Preserve partial state inside the crash-and-resume case.
- 06
Record the next missing case
Name exclusions such as permission revocation, concurrent edits or expired delta tokens. Delta synchronization has its own state rules and needs separate checks if your connector uses it.
Before adding the case to CI.
- The exact endpoint, provider behavior and source date are recorded.
- The initial index, checkpoint and queued work are known.
- The failure happens at a named request or persistence boundary.
- A broken implementation fails the intended assertion.
- The check inspects document IDs and content, not only counts.
- Retries have a deadline and an observable incomplete result.
- The reset rule distinguishes independent cases from an in-case restart.
- Missing provider behavior is recorded as uncovered, not passed.
A scenario specification for crash recovery.
Illustrative example, not customer results
- Case ID
- sync-write-before-checkpoint
- Dataset
- Invented documents A, B on page one; C, D on page two
- Initial state
- Empty index and queue; no checkpoint; normal provider responses
- Interruption
- Stop after C and D are persisted, before the page-two progress commit
- Restart
- Retain partial application state; resume through the normal recovery path
- Assertions
- IDs A–D each present once with expected content; no extras; completion recorded after recovery
- Time budget
- 30 seconds of test time, chosen for this case rather than as a provider guarantee
- Run record
- Pin application, scenario, dataset and check revisions; retain assertion results
- Excluded
- Concurrent writes, permission changes, deletes and delta-token expiry
When your current tools are enough
Existing stateful mocks and your test setup may already express these sequences. Keep them if the behavior is supported by evidence and maintaining it is manageable.
Use authorized provider checks for conditions the controlled environment cannot represent. Do not induce throttling against a shared or production tenant merely to obtain a repeatable test.
Telryn early access
Which sync failure can you not reproduce?
Tell us the integration and missing condition, without customer records or private logs. Each failure case needs its own provider evidence, setup and application checks.
In development. No product access yet.
Sources and limits
- Microsoft Graph: PagingDocuments continuation URLs, empty pages and differences between resources. Check the endpoint-specific contract. Accessed 2026-09-16.
- Microsoft Graph: Throttling guidanceDocuments 429 responses and Retry-After handling. The test’s job deadline is an application choice. Accessed 2026-09-16.
- Microsoft Graph: Delta query overviewDescribes a separate change-tracking protocol with state tokens. Delta recovery is excluded from the worked scenario. Accessed 2026-09-16.
The matrix and crash-recovery case are proposed tests for a hypothetical connector, not reports of Microsoft Graph incidents. They do not establish Telryn provider support or cover every sync design.