feat: Implement session step recording, history lifecycle#36
Conversation
…verIO code generation - Added `RecordedStep` and `SessionHistory` types for session tracking. - Introduced `withRecording` HOF and `appendStep` for step logging. - Extended browser and app session management to initialize and maintain session histories, including transition sentinels and lifecycle markers. - Developed WebdriverIO JavaScript code generator from recorded steps. - Registered MCP resources for session indexing and step inspection. - Added corresponding tests and updated design documentation.
…tool inputs - Preferring headless browsers
abcf3a4 to
630201b
Compare
…ort details - Added documentation for session step recording, MCP resources, and generated WebdriverIO JS scripts. - Updated file structure and descriptions to include recording, code generation, and MCP resource components. - Highlighted session recording as a feature in the README.
| }; | ||
| return `const browser = await remote(${indentJson(config)});`; | ||
| } | ||
| case 'navigate': |
There was a problem hiding this comment.
@Winify I see you have added multiple actions here still lot of them are missing are those going to be added in future?
There was a problem hiding this comment.
I did not want to capture every tool calling, just driver/browser interactions that induce change
What actions d you think could be good candidates?
There was a problem hiding this comment.
You are right, I added the sessions after the initial commit, and it became jumbled, will take a look
| return textContent ? (textContent as any).text : 'Unknown error'; | ||
| } | ||
|
|
||
| export function withRecording(toolName: string, callback: ToolCallback): ToolCallback { |
There was a problem hiding this comment.
All existing tools return errors like "Error closing session: ..." or "Error: ...", so this works today, but it is a brittle string-prefix check that will silently miss errors from any future tool that uses a different format (e.g. "Failed to...", "Unable to find...").
Suggestion: Use the MCP SDK's isError field if available, or introduce a convention: tools should set result.isError = true when returning errors, as the SDK supports this.
There was a problem hiding this comment.
I will take a look at this
I wanted to refactor the tools' response data for a while now, but somehow always fell short
|
Please take a look at these below points too
|
Do you think there will be long-lived sessions where it could pose a problem? I do not think it should be dangerous even with a couple sessions with couple hundred steps |
…etection and handling throughout the codebase
…tart_browser tools - Correctly capture the capabilities of the sessions
|
@mccmrunal I have added some fixes |
Great updates @Winify! Pulled the latest and went through all the changes , most of the concerns are resolved. I think we can move ahead for now . You can merge this. |
Proposed changes
navigation fully discoverable.
Types of changes
Checklist
Further comments
Reviewers: @webdriverio/project-committers