---
title: "Verify a previous client works with the candidate server"
description: "Test an externally prepared previous-version client against a candidate sandbox server, checking a real edit journey and the saved record contract."
canonical_url: "https://vostride.com/agent-library/release-regression/previous-client-new-server.md"
md_url: "https://vostride.com/agent-library/release-regression/previous-client-new-server.md"
content_kind: "recipe"
topic: "release-regression"
---

# Verify a previous client works with the candidate server

Test an externally prepared previous-version client against a candidate sandbox server, checking a real edit journey and the saved record contract.

## Risk

A fresh page load exercises only the newest client. Users with an already open app may retain older request shapes, so the compatibility fixture must record the actual client and server versions before the journey begins.

## Fixtures

- An owned sandbox environment with a previous supported client already loaded and an externally deployed candidate server.
- An external release fixture reporting both build identifiers and preventing automatic client replacement during this compatibility run.
- A disposable task with baseline values and a read-only record oracle exposing accepted fields and revision history.

## Steps

1. Verify the fixture reports the intended previous client and candidate server pair, then open the existing task and verify its baseline identifier and values.
2. Edit a field through the older client, save, and verify the UI reports the updated task rather than an unsupported-request or generic success screen.
3. Leave and reopen the task within the same preserved client session and verify the edited field and unchanged surrounding values.
4. Inspect the independent record oracle and verify one accepted revision with the expected data shape; confirm the client build stayed at the prepared previous version throughout.

## Expected results

- The old client completes the supported edit contract against the candidate server.
- Persistent data includes the intended change without dropped required fields.
- The fixture retains the actual version pair under evaluation.

## False-pass traps

- Reloading into the candidate client silently turns this into an ordinary same-version smoke test.
- A success toast can accompany a server response that ignored an obsolete request field.

## Cleanup

- Restore the fixture task and close the externally prepared previous-client session.

## 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)

- [Release regression QA recipes](/agent-library/release-regression.md)
- [Software factory QA library](/agent-library.md)