Workbench
Test runtime decision shapes in Console before or alongside app traffic.
Workbench lets you test a Valqio decision shape from Console. Use it to verify configuration before your application sends live runtime traffic, and to replay interesting decisions when you are debugging.
Workbench is not a replacement for app traffic. App traffic proves the SDK values, runtime key, idempotency keys, request IDs, and product response path are correct.
Run modes
| Mode | What it does | When to use it |
|---|---|---|
| Preview only | Evaluates the decision shape without consuming usage. | Check whether a subject, action, meter, plan, or limit resolves as expected. |
| Consume usage | Runs a consuming decision path. | Test the same class of mutation your app will perform before a controlled rollout. |
| Check concurrent status | Reads concurrent usage state. | Inspect whether a concurrent limit is already occupied. |
| Acquire concurrent lease | Reserves one concurrent slot. | Test guarded work that needs a temporary lease. |
| Release concurrent lease | Releases a previously acquired lease. | Verify cleanup after a concurrent workflow ends. |
| Replay original | Replays a prior logged decision. | Compare an old outcome with current configuration. |
Mutating modes should be used deliberately. Keep Workbench tests small, use obvious test subjects, and inspect the resulting evidence.
What to test first
Choose a control and customer:
- Select the environment your app will use.
- Choose the meter, feature, parameter, usage control, or limit.
- Enter the customer subject key.
- Run Preview only.
- Confirm the allow or deny reason.
- If the shape is correct, run the equivalent app request.
- Compare Workbench evidence with app traffic evidence.
When Workbench passes but the app fails
Look for differences in:
- environment key
- runtime API key scope
- data plane URL
- subject type or subject key
- action key, owning control, meter, or usage-control key
- quantity
- idempotency key
- generated client readiness
Workbench proves configuration. App traffic proves integration.
What Workbench shows
Use the result details to debug before changing product code:
- outcome and reason
- usage state and served values
- generated action context
- request and response payloads
- replay differences from a prior decision
- raw diagnostics when a decision needs deeper investigation
After a Workbench run, use the same subject, action, quantity, request ID shape, and idempotency strategy in a real app request. Then inspect decision evidence and Runtime Activity.