You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In an ideal world, SuperDB would never panic in supported user operations. But as long as panics may occur, it would seem preferable for the UX in Playground examples to be similar (if not better) than at the shell so the user can recognize what they've just experienced is worthy of bringing to our attention.
Details
At the time this issue is being opened, super is at commit f97e198.
Being able to repro this issue may be a moving target as panics get fixed over time. But a simple one that's available to us right now is an attempted SQL query consisting of a standalone SELECT; as described in #6004.
Consider what's shown in the following video. We start with a working SELECT 1;, but then back up and turn it to just SELECT;. Once we do that, the contents of the RESULT panel change to TypeError: Cannot read properties of undefined (reading 'exports'). If we go back and try to change back to our formerly-working SELECT 1; now the RESULT panel shows Error: Go program has already exited. All Playground examples rendered on the page now fail to produce results when the user interacts with them.
Repro.mp4
If we're lucky, the user may recognize something has gone very wrong, but depending on how much detail they may include in a Slack message or GitHub Issue, it may not be clear they ran into a panic and why.
As a general rule, my first instinct with Playground is to match shell behaviors as best we can, so if it's possible to simply show the same panic output in the RESULT panel that the user would have seen if they'd executed the same query+inputs at the shell, that would seem like a good improvement, since it would allow them to see the dump and copy/paste it to us. As for all the rendered examples now failing, I'm sensing we'd not want the Wasm to restart automatically since might make the panic text easily disappear. Instead would it be feasible to surface an obvious visual cue somewhere in the Playground widget indicating the browser page needs a refresh for the query engine to work again? Maybe temporarily "disable" the rendered Playground examples somehow so they're no longer interactive but the panic text could still be accessed for copy/paste?
In an ideal world, SuperDB would never panic in supported user operations. But as long as panics may occur, it would seem preferable for the UX in Playground examples to be similar (if not better) than at the shell so the user can recognize what they've just experienced is worthy of bringing to our attention.
Details
At the time this issue is being opened,
superis at commit f97e198.Being able to repro this issue may be a moving target as panics get fixed over time. But a simple one that's available to us right now is an attempted SQL query consisting of a standalone
SELECT;as described in #6004.Consider what's shown in the following video. We start with a working
SELECT 1;, but then back up and turn it to justSELECT;. Once we do that, the contents of the RESULT panel change toTypeError: Cannot read properties of undefined (reading 'exports'). If we go back and try to change back to our formerly-workingSELECT 1;now the RESULT panel showsError: Go program has already exited. All Playground examples rendered on the page now fail to produce results when the user interacts with them.Repro.mp4
If we're lucky, the user may recognize something has gone very wrong, but depending on how much detail they may include in a Slack message or GitHub Issue, it may not be clear they ran into a panic and why.
As a general rule, my first instinct with Playground is to match shell behaviors as best we can, so if it's possible to simply show the same panic output in the RESULT panel that the user would have seen if they'd executed the same query+inputs at the shell, that would seem like a good improvement, since it would allow them to see the dump and copy/paste it to us. As for all the rendered examples now failing, I'm sensing we'd not want the Wasm to restart automatically since might make the panic text easily disappear. Instead would it be feasible to surface an obvious visual cue somewhere in the Playground widget indicating the browser page needs a refresh for the query engine to work again? Maybe temporarily "disable" the rendered Playground examples somehow so they're no longer interactive but the panic text could still be accessed for copy/paste?