Skip to content

WIP: Executor: more errors than you require#26

Draft
johncmerfeld wants to merge 3 commits intodevelopmentfrom
exec/granular-errors
Draft

WIP: Executor: more errors than you require#26
johncmerfeld wants to merge 3 commits intodevelopmentfrom
exec/granular-errors

Conversation

@johncmerfeld
Copy link
Collaborator

This is a conversation starter. There's a few things in it that we should absolutely do:

  • Guarantee that Earthmover errors print an entire stacktrace, even if the bundle says not to
  • Send the full lightbeam stacktrace in the error payload the same way we now do with earthmover errors
  • Stop logging descriptor mappings; they're too big

But the real change is seeing how granular we can get with interpreting Earthmover errors. I put forth an aggressive take on this. I think some of these error codes would help the user out and all of them would help us with monitoring / support. I use the term "hints" because sifting through stderr is always going to be somewhat vibes based. But since Earthmover is under our roof, it's overly cautious to treat these strings as unstable. Presuming I test this code robustly, what I want to know is: do you agree? As I say, some of these would warrent some additional UI ("your load failed and it's because you uploaded an Excel file!") and some of them just reduce the depth of investigation required for routine issues.

Separately, I wonder if there's a better way to process lightbeam send errors, and whether we're too lenient with them right now...

@johncmerfeld johncmerfeld self-assigned this Feb 16, 2026
@johncmerfeld johncmerfeld added enhancement New feature or request question Further information is requested labels Feb 16, 2026
# TODO: there's a potential for a hierarchy of errors here but I don't think it buys us anything
class EarthmoverWrongFileError(ExecutorError):
def __init__(self, stacktrace=None):
super().__init__("earthmover_txt", stacktrace)
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Note to self: wrong code

# Like if we say "input_file_error" I worry that ascribes too much certainty when we are not always certain
# could be easily swayed the other way though

# TODO: there's a potential for a hierarchy of errors here but I don't think it buys us anything
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"Details" messages to the user can live in these error definitions. Right now we're using a default "ensure you're using an unmodified version of the vendor file" message which could just become the fallback

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could leave these all as earthmover_run but with different messages, although I like having separate error codes as well

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

enhancement New feature or request question Further information is requested

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant