Direct answer
Reproduce an integration failure by recording the application revision, starting data, provider conditions and expected result. Reset both provider and application state before each run. Check that the affected revision fails for the expected reason, then rerun the fixed revision under the same conditions. Preserve the case, its sources and its coverage limits in CI.
A document sync reports completion after importing only the first page.
An integration imports documents into a search index. Its first request succeeds. The provider throttles the next-page request, and the connector exits without importing the remaining documents. Its completion marker still advances. The incident report contains a throttling response, but that response alone does not describe what the connector had already written or where it would resume.
Use a small, invented dataset with two pages and known document identifiers. Start with an empty index and no checkpoint. Configure the test provider to throttle the first request for page two, then allow the retry. The application check should inspect the index and checkpoint, not just the HTTP status or process exit code.
This is a proposed regression case. It is not proof of a historical cause. Microsoft Graph documents throttling and retry guidance, but a test still needs evidence for the specific endpoint and conditions it claims to represent. Use only authorized provider observations and remove private data before sharing a case.
Keep three parts of the reproduction separate.
What the external service does
The responses, state changes, pagination and failure sequence. Record which behavior is documented, observed or assumed.
Where your connector starts
The database, index, checkpoint, configuration and queued work. Resetting the provider alone leaves earlier runs able to affect the next one.
What counts as recovery
The result your team requires. For this case, every expected document is indexed once and completion is recorded only after recovery.
Make a case another engineer can rerun.
- 01
Reduce the incident
Keep the smallest data and sequence that still expose the suspected bug. Record what you removed, including permissions or timing that might matter.
- 02
Choose a suitable environment
Use an existing mock, stateful simulator or provider sandbox when it covers the case. State machines and fault injection are established techniques; the question is whether the selected behavior represents this provider condition.
- 03
Pin and reset both sides
Record the application revision, dependency versions, test environment, dataset and check revision. Reset the index, checkpoint and provider scenario before every run. Isolate concurrent CI jobs.
- 04
Show the expected failure
Run the affected revision first. Inspect the failing assertion and observations. A missing credential, setup error or different exception does not establish reproduction of the intended bug.
- 05
Check the fix and a control
Run the fixed revision under the same conditions. Also run the normal path. Keep the checks unchanged unless the owner explicitly revises the requirement, and set a bounded timeout so a stuck retry cannot pass.
- 06
Hand off and maintain
Ask a colleague to rerun the case from its recorded instructions. Keep it in CI and assign an owner to revisit the provider assumptions after a relevant change. Measure setup and upkeep as well as runtime.
Before treating a reproduction as a regression test.
- The affected revision fails on the expected application assertion.
- The fixed revision and the normal-path control pass the agreed checks.
- Provider state, application state and queued work are reset or isolated.
- The provider behavior has a source, date and stated fidelity limit.
- Versions, dataset, configuration, time limits and check revisions are recorded.
- The case contains no credentials or unapproved customer data.
- A colleague can rerun it without the original author's intervention.
- Untested conditions and the owner of future maintenance are named.
- The scenario proves the selected fault was exercised; your application assertions judge recovery.
A regression-case record for the interrupted sync.
Illustrative example, not customer results
- Case
- document-sync / second-page throttle
- Starting state
- Four invented document IDs across two pages; empty index; no checkpoint
- Provider sequence
- Page one succeeds; first page-two request is throttled; retry succeeds
- Application check
- All four IDs indexed once; completion checkpoint written after recovery
- Affected revision
- Fails the completeness check under the recorded conditions
- Fixed revision
- Passes the same check and the normal-path control
- Rerun inputs
- Pinned app, environment, dataset and check revisions; reset instructions; timeout
- Not covered
- Permission changes, concurrent writes and unrelated provider failures
When your current tools are enough
Your current tools may already reproduce the failure, reset state, run the checks in CI and stay representative at an acceptable maintenance cost. A maintained external environment would need to remove work from that process to justify its setup and dependency.
A passing simulator run covers its stated conditions. Keep real-provider checks where they are needed to test authentication, configuration or behavior the simulator does not represent.
Telryn early access
Which failure is missing from your regression suite?
Tell us the integration and the condition your team struggles to reproduce. Each condition needs its own provider evidence and setup checks.
In development. No product access yet.
Sources and limits
- WireMock: Stateful behaviourDocuments scenario states and resetting scenarios. A state machine can encode a sequence; it does not establish provider fidelity. Accessed 2026-09-16.
- WireMock: Simulating faultsDocuments delays and fault simulation. These are existing alternatives for exercising selected failure paths. Accessed 2026-09-16.
- Microsoft Graph: Throttling guidanceDocuments throttling responses and retry guidance. It does not establish Telryn coverage or validate this hypothetical connector. Accessed 2026-09-16.
The method and case record are proposed engineering guidance. The scenario is hypothetical, not a customer result or a delivered Telryn capability. Reproducing a symptom does not by itself establish the cause of the original incident.