> ## Documentation Index > Fetch the complete documentation index at: https://docs.testsprite.com/llms.txt > Use this file to discover all available pages before exploring further. # Dependency Chains > How TestSprite figures out the run order for your tests, and when a test is Blocked instead of ready to run. Dependency graph view of producer/consumer relationships ## What Dependency Chains Are When tests share [dynamic variables](/web-portal/core/api/dynamic-variables), they form a chain of producers and consumers: | Endpoint | Produces | Uses | | :- | :- | :- | | POST /users | `user_id` | — | | POST /orders | `order_id` | `user_id` | | GET /orders/`{id}` | — | `order_id` | | DELETE /orders/`{id}` | — | `order_id` | A producer always runs before the tests that use its values, and TestSprite orders the run accordingly. [Auto Cleanup](/web-portal/core/api/auto-cleanup) follows the same dependencies in reverse: children first, then parents. ## How TestSprite Runs Your Tests Independent tests run in parallel; tests that depend on others wait until the values they need are available. A 50-test plan with several dependency layers finishes in roughly the time of its slowest layer, not 50× the average. ## Test Status During a Run | Status | Meaning | | :- | :- | | Queued | Waiting for an earlier step to finish; not yet executed | | Running | Currently making the HTTP call | | Passed | Finished, assertions held | | Failed | Finished, assertions didn't hold | | Blocked | An earlier test failed; this test was never run because the value it needs isn't available | **Blocked is not Failed.** A Blocked test never ran, so it isn't a bug in your API. It's a symptom of a Failed test upstream; start triage there. ## Where to See the Dependency Graph Each test's [Data Flow section](/web-portal/core/api/dynamic-variables#the-data-flow-section-on-a-test) shows what it captures and consumes. A run's [Dynamic Variables](/web-portal/core/api/dynamic-variables) tab lists every variable with its **Source** (producer) and **Used by** (consumers). For one integration chain, its detail page shows the steps in run order. ## Circular Dependencies If two tests need values from each other, the chain can't be assembled. TestSprite reports "Could not assemble — circular dependency between X and Y", and you'll need to refine in chat. This is rare and usually points to an API design issue. ## Multiple Producers for the Same Variable If two tests produce the same variable name (e.g., both POST /users and POST /admins produce `user_id`), TestSprite picks one consistently for downstream consumers. To disambiguate: ```text Disambiguate theme={null} The user_id used by POST /orders should come from POST /users, not POST /admins. ``` ```text Rename theme={null} Rename the value produced by POST /admins to admin_user_id to avoid the conflict with POST /users. ``` ## When an Earlier Test Fails Anything that depends on a failed test's values is Blocked: ``` POST /users → assertion failed (status was 500) [Failed] POST /orders → needs user_id, can't run [Blocked] GET /orders/{id} → needs order_id, can't run [Blocked] DELETE /orders/{id} → needs order_id, can't run [Blocked] ``` The matching cleanup is marked Skipped too, since the record was never created. Fix the failing test (or your API), then [rerun the chain](/web-portal/core/api/api-rerun): TestSprite re-runs the failing test and its Blocked downstream tests. ## Edge Cases & Troubleshooting Open the Blocked test; the error trace names the missing variable. Search the Dynamic Variables tab for it to find the producer, which will be Failed. They already do. If runs look serial, your tests probably all share one upstream (typically a `user_id` from a single POST /users). Refine in chat to produce a small pool of users instead. That's a variable resolution issue, not a dependency issue. See [Dynamic Variables: Troubleshooting](/web-portal/core/api/dynamic-variables#edge-cases-and-troubleshooting). They probably don't share a variable name, so they're treated as independent. Refine in chat: "POST /sessions should produce user\_id, GET /me should use user\_id". This shouldn't happen. If it does, check the chain's order in the Integration Tests tab and refine in chat: "The chain order should be POST /users → POST /sessions → POST /orders". ## Where to Go Next Values produced by one test and used by another Records created during a run get removed afterward Multi-step chains where one test's output feeds the next Per-test and per-chain reruns This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.