Add support for full and partial call stacks, improved error handling in DashR #87

rpkyle · 2019-04-28T04:51:02Z

This PR proposes multiple improvements to error handling and debugging in DashR:

Adds a debug mode to DashR apps
Introduces full/partial call stacks if app is served via app$run_server(debug=TRUE)
While in debug mode, catches errors as warnings, allowing app execution to continue
Introduces logic to return an HTML version of the call stack and error message for use by dash-renderer and the recently released in-browser dev tools

Here is an example of an error before the proposed changes:

...and after:

Eventually, it should also be possible to conditionally implement line number support for R code loaded via source().

Closes #16 and #86.

alexcjohnson · 2019-04-28T22:52:58Z

Nice, that's certainly an improvement!

Introduces logic to return an HTML version of the call stack and error message for use by dash-renderer and the recently released in-browser dev tools

Does that work now? What does it look like? Also, am I reading it right that it's returning code 200 in the new version? Can we change it back to 500 (which is also what dash-py uses for errors)?

R/dash.R

rpkyle · 2019-05-04T18:26:22Z

@alexcjohnson

Nice, that's certainly an improvement!

😌

Introduces logic to return an HTML version of the call stack and error message for use by dash-renderer and the recently released in-browser dev tools

Does that work now? What does it look like? Also, am I reading it right that it's returning code 200 in the new version? Can we change it back to 500 (which is also what dash-py uses for errors)?

Not yet, but I think we're close.

Right, 500 would make more sense. For HTML version of the call stack, I'll need to emulate what werkzeug is doing on the Python side, no? Since fiery lacks that sort of R debugging integration, I believe this would be best accomplished by sending a response up to the renderer with the proper headers, but I'm not sure.

Any hints you can offer there would be much appreciated 🙂. I think the frontend code that handles this sort of thing is here:

https://github.com/plotly/dash-renderer/blob/master/src/components/error/FrontEnd/FrontEndError.react.js

rpkyle · 2019-05-04T18:29:33Z

Also, it looks like Carson raised a related issue with Thomas Lin Pedersen, but I don't think it went anywhere:

thomasp85/fiery#34

alexcjohnson · 2019-05-21T20:20:31Z

Right, 500 would make more sense. For HTML version of the call stack, I'll need to emulate what werkzeug is doing on the Python side, no? Since fiery lacks that sort of R debugging integration, I believe this would be best accomplished by sending a response up to the renderer with the proper headers, but I'm not sure.

I think all you need is to send back the error as response$body, and set response$status = 500L. The error should be an HTML string, but that could initially just be a super simple wrapping like '<!DOCTYPE HTML><html><body><pre>' + error_with_stack_trace + '</pre></body></html>' and we can play with styling it nicely in another PR.

alexcjohnson · 2019-05-21T20:25:35Z

R/dash.R

@@ -255,6 +254,9 @@ Dash <- R6::R6Class(
          }
        }

+        # set the callback context associated with this invocation of the callback
+        private$callback_context_ <- setCallbackContext(request$body)


This looks great. I think all you need to do to finish off the callback context part of this PR is set it back to NULL after the do.call below, and have callback_context throw an error if it finds NULL.

fixed in 6fc1cac

Oh sorry - what I meant was, down here when you access callback_context_

https://github.com/plotly/dashR/pull/87/files#diff-1881af3720f8f49fd3a44e51c9fb5a0dR489

At that point, if it's NULL, that means you're not in a callback so you shouldn't be able to access it, so throw an error.

fixed in 96e4672

alexcjohnson

💃 💃 💃

rpkyle · 2019-06-13T17:40:06Z

Right, 500 would make more sense. For HTML version of the call stack, I'll need to emulate what werkzeug is doing on the Python side, no? Since fiery lacks that sort of R debugging integration, I believe this would be best accomplished by sending a response up to the renderer with the proper headers, but I'm not sure.

I think all you need is to send back the error as response$body, and set response$status = 500L. The error should be an HTML string, but that could initially just be a super simple wrapping like '<!DOCTYPE HTML><html><body><pre>' + error_with_stack_trace + '</pre></body></html>' and we can play with styling it nicely in another PR.

fixed in cee5376

Ryan Patrick Kyle added 5 commits April 23, 2019 14:02

✨ initial support for stack tracing

689e309

🚚 add dependency on crayon 📦

cfe9c49

✂️ trim call stack from top also

897df31

renamed stack trace fn

0ad3b38

✨ capture errors as warnings in debug mode

0d526b4

rpkyle added the enhancement label Apr 28, 2019

rpkyle requested a review from alexcjohnson April 28, 2019 04:51

rpkyle self-assigned this Apr 28, 2019

Merge branch '0.0.7-dev' into 0.0.7-debug

6291553

alexcjohnson reviewed Apr 28, 2019

View reviewed changes

R/dash.R Outdated Show resolved Hide resolved

Ryan Patrick Kyle added 6 commits May 4, 2019 01:41

✨ initial support for dash-renderer v23

d84b964

resolved conflicts

0371634

🐛 fix missing parenthesis

73a429a

rename pruned to pruned_errors

35dedac

rename pruned to pruned_errors in utils.R also

53b70dd

✨ add options for dev_tools_ui and dev_tools_props_check

151e838

✨ initial support for callback context

140bf51

alexcjohnson reviewed May 21, 2019

View reviewed changes

Ryan Patrick Kyle added 3 commits June 11, 2019 17:34

throw error if request$body is NULL

6fc1cac

✋ warn if callback_context is undefined

96e4672

🔪 commented codeblock

e372c3c

alexcjohnson approved these changes Jun 13, 2019

View reviewed changes

Ryan Patrick Kyle added 2 commits June 13, 2019 13:37

✨ add support for debug mode tracebacks

cee5376

✋ only send tracebacks in debug mode

b0de5a0

✏️ fix comment

4103fdc

Ryan Patrick Kyle added 2 commits June 13, 2019 13:45

🙈 remove browser

fca2474

Merge branch '0.0.7-debug' of github.com:plotly/dashR into 0.0.7-debug

be94c47

rpkyle merged commit f521fd4 into 0.0.7-dev Jun 13, 2019

rpkyle deleted the 0.0.7-debug branch June 13, 2019 17:52

rpkyle mentioned this pull request Jun 18, 2019

Support for debugging DashR errors needs improvement #86

Closed

rpkyle mentioned this pull request Oct 16, 2019

Need support for including line number references in stack traces when available #132

Closed

rpkyle changed the title ~~[WIP] Add support for full and partial call stacks, improved error handling in DashR~~ Add support for full and partial call stacks, improved error handling in DashR Jan 16, 2020

rpkyle removed their assignment May 4, 2020

rpkyle mentioned this pull request Jun 3, 2020

dash callback_context in R? #208

Closed

rpkyle mentioned this pull request Oct 12, 2020

189 - Add Pattern Matching Callbacks for Dash R #228

Merged

1 task

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Add support for full and partial call stacks, improved error handling in DashR #87

Add support for full and partial call stacks, improved error handling in DashR #87

rpkyle commented Apr 28, 2019 •

edited

Loading

alexcjohnson commented Apr 28, 2019

rpkyle commented May 4, 2019 •

edited

Loading

rpkyle commented May 4, 2019

alexcjohnson commented May 21, 2019

alexcjohnson May 21, 2019

rpkyle Jun 11, 2019

alexcjohnson Jun 11, 2019

rpkyle Jun 12, 2019

alexcjohnson left a comment

rpkyle commented Jun 13, 2019

Add support for full and partial call stacks, improved error handling in DashR #87

Add support for full and partial call stacks, improved error handling in DashR #87

Conversation

rpkyle commented Apr 28, 2019 • edited Loading

alexcjohnson commented Apr 28, 2019

rpkyle commented May 4, 2019 • edited Loading

rpkyle commented May 4, 2019

alexcjohnson commented May 21, 2019

alexcjohnson May 21, 2019

Choose a reason for hiding this comment

rpkyle Jun 11, 2019

Choose a reason for hiding this comment

alexcjohnson Jun 11, 2019

Choose a reason for hiding this comment

rpkyle Jun 12, 2019

Choose a reason for hiding this comment

alexcjohnson left a comment

Choose a reason for hiding this comment

rpkyle commented Jun 13, 2019

rpkyle commented Apr 28, 2019 •

edited

Loading

rpkyle commented May 4, 2019 •

edited

Loading