-
Notifications
You must be signed in to change notification settings - Fork 43
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Error handling - identify which block in which pipeline triggers an exception #128
Comments
Per a pointer from @russellb, I'm going to take a look at this one today and will report my progress here. I don't have write access to assign to myself though. |
…/type wrapping instructlab#128 Signed-off-by: Gabe Goodhart <[email protected]>
instructlab#128 Signed-off-by: Gabe Goodhart <[email protected]>
In #155, @russellb asked for before/after examples for the fix. What's currently proposed is to catch exceptions from
This case isn't actually so problematic because the context is logged - |
…ption instructlab#128 Signed-off-by: Gabe Goodhart <[email protected]>
…ration instructlab#128 Signed-off-by: Gabe Goodhart <[email protected]>
instructlab#128 Signed-off-by: Gabe Goodhart <[email protected]>
github: add stale bot to dev docs repo
See #118 for the background
In general, I think when there is an error with a block, we don't make it easy to know which block in which pipeline caused it
A
config_path
not found case looks likeWhich isn't so bad, because you just have to find the block with that path
But in other cases it might not be so easy to identify which block is causing an error - if we catch exceptions and add the pipeline+block name, that would be a big improvement
The text was updated successfully, but these errors were encountered: