Console Diagnostics Proposal

[skyrpex]

This issue will hold a discussion regarding Console Diagnostics. The idea is to improve observability and debuggability of Wing applications when using the Console.

The Diagnostics panel

My proposal consists of a new Diagnostics/Problems panel, similar to VSCode's Problems panel:

This panel will show a list of problems that affect any resource in the application during initialization. The runtime error will be shown in the panel and let the user navigate to the construct that failed, and to the source code.

Changes to existing panels

• The map view will show a small indicator for every construct that failed to initialize (red circle with exclamation mark), or that it's depending on a resource that failed (gray circle with a pause icon). Hovering the construct in the map view will display a popover with detailed information about the issue, and helpful links (e.g. link to focus on the related diagnostics error entry)
• The tree view will also show small indicators, and right clicking on the items will also provide helpful actions
• The inspector view should show some kind of error indicator if a failed construct is selected

Changes to Console Backend / Simulator

It may be required to refactor the simulator and/or the console backend. The current behavior during an initialization error consists of showing the Blue Screen Of Death while hiding the tree view, the map view and the inspector view. Ideally, we want all valid constructs up and running and not showing the BSOD anymore

[Chriscbr]

Displaying build-time errors could be tricky since the SDK currently doesn't produce the construct tree if preflight synthesis fails. Maybe some of these issues can be addressed if we add some kind of mechanism for raising multiple errors (https://github.com/winglang/wing/discussions/6073), or some kind of way to internally catch exceptions automatically during preflight so that they can be displayed.

What if we showed runtime errors through the proposed UI? For example, if a queue message can't be processed, then the errors can be highlighted with badges in the map, or on the diagnostics tab. (Errors could be individually dismissed, or you could clear them all by clicking the "Clear logs" button).

[skyrpex]

Exactly:

• Build-time errors still show some kind of BSOD (there's no way around that)
• Initialization (runtime) errors would be collected instead of throwing a BSOD

[eladb]

I don't think we really need an additional pane.

I think we need to add two features to the console:

1. When a select a node, I'd like the log view to filter to show only logs that were emitted from this node or any children of it.

2. When an app starts/stops/updates, it should emit status events for each resource (starting, error, stopping, started, stopped) and we should display an affordance on the node that represents this state.

Also- we should show initialization errors in the logs as red errors. I believe they are hidden now.

[skyrpex]

I don't think we really need an additional pane.

Fair enough.

When a select a node, I'd like the log view to filter to show only logs that were emitted from this node or any children of it.

There's an issue for that https://github.com/winglang/wing/issues/1413. Maybe we can implement this feature there.

When an app starts/stops/updates, it should emit status events for each resource (starting, error, stopping, started, stopped) and we should display an affordance on the node that represents this state.

👍🏻

Also- we should show initialization errors in the logs as red errors. I believe they are hidden now.

Good idea, I'll look into that.

[eladcon]

Is there some way to indicate progress while the app is loading? would the events be showed by default?

[skyrpex]

Is there some way to indicate progress while the app is loading? would the events be showed by default?

Part of the proposal is to start emitting status events for every resource: starting, error, stopping, started, stopped. These events would be visible through indicators in the map and the tree, mainly.