---
title: "Verify competing sandbox bookings cannot claim one slot"
description: "Test a sandbox appointment slot with two prepared contenders, ensuring only the accepted booking persists and the other user receives a clear conflict."
canonical_url: "https://vostride.com/agent-library/scheduling/concurrent-slot-booking.md"
md_url: "https://vostride.com/agent-library/scheduling/concurrent-slot-booking.md"
content_kind: "recipe"
topic: "scheduling"
---

# Verify competing sandbox bookings cannot claim one slot

Test a sandbox appointment slot with two prepared contenders, ensuring only the accepted booking persists and the other user receives a clear conflict.

## Risk

A slot can appear free in two sessions before either commits. One UI success is not enough; the independent booking ledger must prove uniqueness while preserving each contender account boundary.

## Fixtures

- An owned sandbox booking service with one available slot and two disposable test users, with all payment and real notifications disabled.
- An external contender fixture that opens and reserves the same slot at a named checkpoint, reporting its committed booking identifier.
- A read-only booking ledger and an explicit product rule allowing at most one active booking for this resource and interval.

## Steps

1. As user A, open the prepared slot and verify it is initially offered as available without submitting yet.
2. Have the external user-B fixture commit that slot and verify its report confirms the accepted booking.
3. Submit A booking and verify the app shows the documented slot-conflict recovery instead of a successful second reservation.
4. Refresh available times, verify the claimed slot is unavailable, and inspect the independent ledger for exactly one active booking belonging to B and no partial A booking.

## Expected results

- Only one active booking claims the resource interval.
- The losing session receives a specific recoverable availability conflict.
- No partial booking, sandbox charge, or confirmation message exists for the rejected contender.

## False-pass traps

- Starting the second session after refreshing availability avoids the stale-slot race.
- A success toast followed by a later cancellation is not equivalent to correctly rejecting the conflict.

## Cleanup

- Cancel the accepted sandbox booking and reset the external contender 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)

- [Scheduling and calendar QA recipes](/agent-library/scheduling.md)
- [Software factory QA library](/agent-library.md)