ars9
0e47623a6b
- POST /exec now accepts environmentId (UUID) and credentials (alias → UUID) instead of raw payloads; resolves entities via EnvironmentService and CredentialService before passing data to browserService.exec - exec_code MCP tool updated with same schema: environmentId + credentials map - CredentialModule imported into BrowserModule and McpModule - docs(scenario): rewrite script runtime section for single context argument - docs(mcp): update exec_code description to reflect new parameter shapes - style: reorder imports across server source (formatter)
87 lines
2.4 KiB
Markdown
87 lines
2.4 KiB
Markdown
# Scenario execution
|
|
|
|
When a scenario run is created, the server creates one `ScenarioRunStep` per scenario step.
|
|
|
|
- Step runs are ordered by `step.order`.
|
|
- First step run starts as `pending`; the rest start as `waiting`.
|
|
- Scheduler tick (`@Interval(1000)`) picks pending runs and processes steps in order.
|
|
- Steps in the same run share one Playwright browser/context/page.
|
|
|
|
## Execution model
|
|
|
|
Current scheduler behavior is exec-centric:
|
|
|
|
- `execCode` is required for a step to pass.
|
|
- `validateCode` is optional and runs after `execCode`.
|
|
- Legacy step type metadata may still appear in MCP payloads, but run execution is not branched by step type.
|
|
|
|
## Script runtime
|
|
|
|
`execCode` and `validateCode` execute as async JavaScript with a single `context` argument:
|
|
|
|
```js
|
|
async (context) => {
|
|
// your code here
|
|
}
|
|
```
|
|
|
|
Available in scope:
|
|
|
|
- `context.page`: Playwright `Page`
|
|
- `context.browser`: Playwright `BrowserContext`
|
|
- `context.env`: shallow copy of environment key/value map
|
|
- `context.getEnv(key)`: required environment value lookup (throws if missing)
|
|
- `context.getCredential(alias)`: credential payload assigned to the scenario alias
|
|
- `context.getStepOutput(order)`: prior step output by absolute order (`1`, `2`, ...) or relative (`-1` = previous step)
|
|
- `context.dumpDom(selector?)`: simplified DOM snapshot
|
|
- `context.log(...args)`, `context.warn(...args)`, `context.error(...args)`: structured step logs
|
|
- `context.runSnippet(name, ...args)`: execute stored snippet code with the same context
|
|
- `console`: proxied to run logs (`log`, `warn`, `error`, etc.)
|
|
|
|
`validateCode` additionally receives `result` in scope, which is the value returned by `execCode`.
|
|
|
|
## Validation contract
|
|
|
|
`validateCode` may return:
|
|
|
|
```js
|
|
return { success: true, description: 'ok' };
|
|
// or
|
|
return false;
|
|
```
|
|
|
|
Interpretation:
|
|
|
|
- Boolean: `true` = pass, `false` = fail
|
|
- Object: `success` controls pass/fail; `description` is persisted as step description
|
|
|
|
On validation failure, the step fails and the run is marked `fail`.
|
|
|
|
## Statuses
|
|
|
|
Run status:
|
|
|
|
- `pending`
|
|
- `in_progress`
|
|
- `pass`
|
|
- `fail`
|
|
|
|
Run-step status:
|
|
|
|
- `waiting`
|
|
- `pending`
|
|
- `in_progress`
|
|
- `pass`
|
|
- `fail`
|
|
- `cancelled`
|
|
|
|
## Example workflow
|
|
|
|
1. Create environment
|
|
2. Create credentials and snippets (optional but common)
|
|
3. Create scenario
|
|
4. Add ordered steps (`execCode`, optional `validateCode`)
|
|
5. Assign credentials to scenario aliases when needed
|
|
6. Run scenario
|
|
7. Wait for run completion and inspect run logs/outputs
|