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
Start with one product action and one customer:
- Select the environment your app will use.
- Choose the product action, meter, feature, parameter, or usage control.
- 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
- product action, 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 one real app request. Then inspect decision evidence and Runtime Activity.