[Enhancement] Provide more detailed error information

[justinkambic]

Feature summary

I want to have more detailed error information about why my script failed.

Why is this feature important?

Today, when a script fails, we only have resolution to the step level. This can be problematic, because a step can contain a lot of code. A mild example:

It would be much nicer if we could not only know which action failed (so we can display the correct status icon for any step actions that succeeded), but if we knew the action that failed we could also highlight the line(s) it generates so the user can know much more approximately where to look for their failure. This way they wouldn't need to rely solely on Playwright's error messages. Users will be able to isolate and fix problems with their scripts faster.

Linked resources

No response

Additional information

The solution that I have in mind involves breaking each action into its own granular Step on the backend, and then recomposing the results of each step into the original IR to return as a result to the client. Example:

{
  "name": "Step1",
  "actions": [
    { "name": "Action1", ... },
    { "name": "Action2", ... },
  ]
}

On the backend, we'd end up with something like:

{ "name": "Step1.0001", "actions": [{ "name": "Action1" }] }
{ "name": "Step1.0002", "actions": [{ "name": "Action2" }] }

After passing each of these "sub-steps" to Playwright and parsing the response, we'd reconstitute them back into "Step1", but we'd know which action caused any failure and could associate the correct "sub-step" status to each action once the action is re-composed. This will require significant modification to the way we handle the test procedure in our electron code.

[justinkambic]

So after some refinement breakout we have come across several possible solutions to pursue:

1. My idea of using some intermediary IR to communicate with Synthetics/Playwright while tracking which action failed isn't tenable for the Recorder as it exists today, because Synthetics does a number of procedures when executing a new step that we would not want to trigger on a per-action basis. Playwright also doesn't have a notion of steps/actions like we do. If we'd want to add this feature, it would be better to put it upstream in Synthetics and utilize it from the Recorder.
2. We can use the notion of code frames, where we'd get some string output showing where the failure in the code occurred and do some string parsing or AST parsing to display more information to the user.
3. We can do some extra code gen on the backend and find the portion of the step code we display that comes from the failure and extrapolate the failed action, and reflect that in the UI.
4. We can add the notion of a debugger to the Recorder, similar to the way that Playwright's inspector works and in the same vein as the work @kyungeunni did in her ON Week project to allow us to execute actions one by one and pause/trace/repeat them in the code. This will require some additional Playwright investigation to see how exactly their inspector works and determine what course we could take.