- add enum entries for other types of errors
- omit stack frames for outer error in dagit log view
It doesn't seem that helpful to actually see the error source (e.g. USER_CODE_ERROR) in the message. Seems more useful to follow-up with steps for recourse.
Please check your repository definition for X.
What class of problems are framework errors, as opposed to unexpected errors?
requesting review to get opinions on what to do with dialog context line. My current ordered preference is
- just drop the enum name
- only show on unexpected error to request for issue filing
what about yall?
Ya i think we can iterate to something better here. My thoughts for adding this or something like it:
ya I was thinking thats useful for us if they copy / screenshot and send it to us
but i do agree its not ideal and we can just match on the description text if we keep it
I think just dropping the enum name is fine. I'm curious how users would separate out the steps to resolve framework vs unexpected errors.
I guess because framework errors might be instance configuration errors?
I think it's not a blocker, but I have a natural aversion to having anything in the product talk about "users" and calling anything "user-provided" code. If there's a way to be specific about the error boundary (e.g. this solid name or this schedule definition), we could avoid this distinction.