Distinguish between local and remote exceptions when stopping ephemeral app #2071
Conversation
mwaskom
force-pushed
the
michael/improve-ephemeral-remote-error-exit
branch
from
f417784
to
db4c1df
Compare
|
@prbot approve |
![modal-pr-review-automation[bot]](https://avatars.githubusercontent.com/in/335990?s=60&v=4){kind=small}
| @@ -94,6 +97,15 @@ def reduce_traceback_to_user_code(tb: TracebackType, user_source: str) -> Traceb | |||
| return tb | |||
|
|
|||
|
|
|||
| def traceback_contains_remote_call(tb: Optional[TracebackType]) -> bool: | |||
There was a problem hiding this comment.
maybe it's cleaner to set a magic attribute on the exception or something? we create this exception in code somewhere, i think.
There was a problem hiding this comment.
I looked into that but I'm not convinced it's simpler. We construct the traceback with these special task-id-containing filenames server-side as a TracebackDict when then gets deserialized into an actual traceback object client-side. For ephemeral apps, all we have is the run_app context manager that yields out to a script contexts; but if we catch an exception there we don't know whether it was triggered locally or after a remote call. Then there's already some special exception type wrapping / unwrapping in synchronicity too when we go through Function.remote...
mwaskom
force-pushed
the
michael/improve-ephemeral-remote-error-exit
branch
from
db4c1df
to
0d087a4
Compare
Currently, we re-raise remote exceptions inside the local client process, which causes us to report the app stop event as being caused by a "local exception". That's confusing and sets users off on the wrong debugging path. This inspects the traceback to determine whether the stack contains a hop out to a remote modal function call and then attributes the error accordingly.
Needs a server-side change too.