log a backtrace for tuning issues#879
Conversation
|
|
||
| wrn_msg <- tibble::new_tibble( | ||
| list(location = loc, type = "warning", note = wrn_msg), | ||
| list(location = loc, type = "warning", note = wrn_msg, trace = list(wrn_traces[[1]])), |
There was a problem hiding this comment.
Note that traces are a tibble subclass.
Each row in the output of this function is a given place in evaluating a resample fold, e.g. Fold1 preprocessor 1/1, model 1/1 (predictions).
It's possible to have more than one warning appear in a given model fit or prediction or metric calculation, so we collapse messages (see above) into one string in that case. For traces, we could just pass all of list(wrn_traces), but that would mean that, to be type-stable, we'd have to list(list(err_cnd$trace)) for errors.
Said another way, right now, to extract the second logged trace, you could write collect_notes()$trace[[2]]. If we supplied all of the warning traces in this line and changed the format for errors to be type-stable, you'd have to write collect_notes()$trace[[2]][[1]]. This [[-fu feels contrary to the point of the collect_*() functions.
This approach banks on the fact that it's likely not useful to have a backtrace for each warning that occurs in a single call to e.g. predict.xgb(); the first is sufficient to help you drop into the right environment to track down an issue.
There was a problem hiding this comment.
I'd go with clarity over completeness here and only use the first trace as suggested. If we later realize that this does not get us to a useful debugging point often enough, we can still extend it.
this had been skipped locally due to R version
|
I LOVE IT! I had it in my personal todo to tell you tomorrow that I wanted you to look at saving the trace back! |
|
|
||
| wrn_msg <- tibble::new_tibble( | ||
| list(location = loc, type = "warning", note = wrn_msg), | ||
| list(location = loc, type = "warning", note = wrn_msg, trace = list(wrn_traces[[1]])), |
There was a problem hiding this comment.
I'd go with clarity over completeness here and only use the first trace as suggested. If we later realize that this does not get us to a useful debugging point often enough, we can still extend it.
Co-authored-by: Hannah Frick <hfrick@users.noreply.github.com>
|
This pull request has been automatically locked. If you believe you have found a related problem, please file a new issue (with a reprex: https://reprex.tidyverse.org) and link to this issue. |
Was too excited to wait until Monday to finish this PR.😝
This PR aims to provide a better entry point to debugging tuning issues. Closes #873, but takes a slightly different approach than what's recommended there. Instead of surfacing one additional error context header (i.e.
Error in log(): ...), this PR proposes attaching a traceback to errors and warnings and then logging it in thenotescolumn. The example from that issue:Created on 2024-03-23 with reprex v2.1.0
This is likely more aimed at advanced users (and developers), but I think will be a gamechanger for quickly
debug()ging into the right functions or spotting the right bit of context that tips me off to what the actual issue is.