enso-org / enso

Enso Analytics is a self-service data prep and analysis platform designed for data teams.
https://ensoanalytics.com
Apache License 2.0
7.36k stars 323 forks source link

Widget response parse error in the IDE gives far too little information to be able to debug it #7822

Open radeusgd opened 1 year ago

radeusgd commented 1 year ago

I'm working on new Date-format-pattern widgets for #7461 and I'm sometimes making mistakes. When that happens, some widgets do not load due to bad format.

The IDE logs inform me about this:

[ERROR] app\gui\src\controller\graph\widget.rs:184 ErrorMessage { msg: "missing field `constructor` at line 1 column 464" }

Failed to deserialize widget data for argument 'self'
consume @ router.ts:62
YR.console.<computed> @ router.ts:36
imports.wbg.__wbg_error_ef9a0be47931175f @ pkg.js:3704
/// ... the rest of obfuscated JS stacktrace
real @ pkg.js:261

Unfortunately, this message does not give me enough detail to be able to nail down the problem and I have to try to guess it myself. I don't even know to which node/widget this message is related.

It should be possible to see in the error message the full content of the parsed widget response. Ideally, it would be good to be able to somehow also correlate it for which method the widget response was being parsed - to make it easier to locate where the problem is.

jdunkerley commented 1 year ago

This should be easier when we have the JS IDE up and running.

For now, we can test the Enso side using Standard.Visualization.Widgets.Widgets.get_widget_json. Once the JS widgets are added we should ensure that debugging this flow is possible.

somebody1234 commented 1 year ago

since i'm working on visualizations - i can probably try to figure out whether there's a nice way to validate data/recover from bad data.

one option would be to manually check the shape of data. on one hand this doesn't need to require a library, and is fast - on the other hand it'd be painful for people writing custom third-party visualizations, and we can't guarantee that we've caught all bad cases

another option is to include a validation library like typebox. it might be slow if the entire object needs to be validated all at once, but in exchange we can be sure that we are catching all bad cases. (also, realistically it's not like we'll be sending so much data that validation becomes slow - displaying the data is probably more of a bottleneck than validation.)

oh - another thing, (for the new visualizations) we could maybe consider displaying an error message when receiving data that is completely unrecoverable - e.g. a single number when we are expecting an entire object

thoughts?