---
title: "Verify create recovery after a lost success response"
description: "Test a sandbox create request whose response is externally dropped after commit, checking that user retry resolves to one logical record."
canonical_url: "https://vostride.com/agent-library/network-recovery/ambiguous-create-response.md"
md_url: "https://vostride.com/agent-library/network-recovery/ambiguous-create-response.md"
content_kind: "recipe"
topic: "network-recovery"
---

# Verify create recovery after a lost success response

Test a sandbox create request whose response is externally dropped after commit, checking that user retry resolves to one logical record.

## Risk

The hardest retry case is a successful server write that looks like failure to the client. Counting clicks or transport attempts is insufficient; the oracle must identify committed logical operations independently.

## Fixtures

- An owned web sandbox and a test account allowed to create disposable projects with run-specific names.
- An external fault proxy prepared to deliver the create request to the server, drop its success response, and report the affected request identity.
- A project-owned ledger exposing logical operation identifiers and committed project records; no production endpoint or real billing side effect is involved.

## Steps

1. Open Create project, enter the unique name and description, and verify both values before submitting under the prepared fault fixture.
2. Verify the fault report confirms commit followed by response loss, and verify the UI displays its documented uncertain or retryable state rather than a false definitive rejection.
3. Restore connectivity through the external fixture, choose the app-supported retry or status-recovery control, and verify a project detail page appears.
4. Verify the detail name and description match the original attempt, then reopen the project list and verify one matching logical project.
5. Inspect the independent ledger and verify one committed project even if multiple transport attempts occurred, with the final displayed identifier matching that project.

## Expected results

- The fault was injected after commit, making the outcome truly ambiguous to the client.
- The recovered detail identifies the one committed project and preserves submitted content.
- The ledger contains no duplicate logical create or orphan project from recovery.

## False-pass traps

- Dropping the request before the server receives it tests a simpler failure and misses duplicate-write risk.
- One visible row may conceal duplicates outside the current page or filtered view.

## Cleanup

- Delete the sandbox project and disable the external response-drop fixture.

## Use with agent-qa

Adapt this test design to your application's acceptance criteria and configured target using the [recipe execution guide](/agent-library/software-factory/turn-a-recipe-into-an-agent-qa-test.md). External fixture setup and non-UI checks require your own supported hooks or test tooling. Validate the authored test, execute it, and inspect the completed evidence; this recipe is not a recorded test result.

## References

- [agent-qa first test](/docs/agent-qa/guides/first-test.md)
- [agent-qa hooks](/docs/agent-qa/guides/hooks.md)
- [agent-qa test](/docs/agent-qa/configuration/test.md)

- [Network recovery QA recipes](/agent-library/network-recovery.md)
- [Software factory QA library](/agent-library.md)