Two agents, one remaining refund allowance
Design a concurrency test that checks shared refund capacity before dispatch, including pending approvals and unresolved provider responses.
Two agents each see $20 available and each request a $15 refund. Checking the balance in the agent process lets both proceed. The decision needs to reserve capacity at the execution boundary, where the two requests share state.
Anlyon impact limits reserve capacity before dispatch for governed actions routed through Anlyon. The limit belongs to one environment and configured scope. Another environment, or a direct provider call, is outside that allowance.
Construct a meaningful test
Use a dedicated test environment, the Stripe refund adapter in test mode, two independent Anlyon credentials, and two refundable test payments. Configure an applicable USD limit of 2,000 minor units. Ensure no previous operations consume that allowance. Give each request a distinct business operation key so the test exercises capacity rather than deduplication.
Start two requests for 1,500 minor units at approximately the same time. A local barrier helps synchronize the callers, but does not prove distributed concurrency by itself. Record request start times, effect identifiers, provider records and the allowance after settlement.
| Observation | Interpretation |
|---|---|
| One dispatched, one refused for capacity | The intended shared-boundary behavior |
| One pending approval, another refused | Reserved capacity can matter before provider completion |
| Both refused | Check setup, policy, credentials and existing exposure |
| Both dispatched | Investigate scope, quantity declarations and the actual execution path |
Do not count two HTTP errors as a passing test. Inspect the rejection reason and verify which provider writes happened.
Add the difficult cases
Repeat with a new session and a different key in the same environment. Neither should create a fresh allowance. Then lose the provider response in a controlled fixture. An unknown outcome must keep exposure held; otherwise the next agent can spend capacity that may already have been consumed.
This is a test procedure, not a report of a live experiment. Capture your run count and raw results before claiming a measured result. The offline reservation example illustrates the accounting separately from provider integration.
Put it into your application
Use the impact-limit configuration reference and governed action setup. Keep limit-writing privileges with the operator. An agent that can raise its own limit changes the boundary you are testing.
For unresolved exposure, continue with why a timeout holds capacity.