Skip to content
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

Better error handling during wait*() and Run.__init__() #118

Merged
merged 11 commits into from
Jan 14, 2025

Conversation

kgodlewski
Copy link
Contributor

This PR addresses a problem, where it's impossible to react gracefully and consistently to errors that occur during Run.__init__(), namely run creation.

With our current design it's impossible for the user (the user being our CLI as well mind you) to handle trivial errors like invalid API key passed to Run, if a custom error handler is registered.

This change is on the functional and UX front.
What it does:

  • return bool from _wait() and friends. True means "everything was processed", False means: "timeout or run is now being closed"
  • honor the timeout argument almost(*) properly
  • make Run.close() and Run.terminate() block until the process actually terminates, if called from a different thread that initiated the close operation. This helps with race conditions / cluttering stdout with logs in order which is not meaningful.

(*) almost, because we apply the timeout to a single iteration of the wait loop. A future PR will address that.

@kgodlewski kgodlewski requested a review from PatrykGala January 10, 2025 15:28
@PatrykGala PatrykGala force-pushed the kg/run-error-handling-fixes branch from b6e03cd to 46c08e5 Compare January 14, 2025 10:27
Copy link
Collaborator

@PatrykGala PatrykGala left a comment

Choose a reason for hiding this comment

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

Create a variable starting: True.
The default error callback checks with a lock whether it's True or False. If it's True, it performs a terminate; if it's False, it calls the callback.

It's hacky, but shouldn't be problematic for now
This applies to cases when we close a Run from
a different thread. It's better to wait until
the worker process terminates, as it makes it easier to print out a
final error message in case of an error, instead of having it mixed
together with logging from different threads.
In case of an error callback from ProcessLink,
push the message to errors queue instead of calling `Run.terminate()`
directly. This helps avoiding deadlocks.
@kgodlewski kgodlewski force-pushed the kg/run-error-handling-fixes branch from 46c08e5 to f19ef1c Compare January 14, 2025 11:42
@kgodlewski kgodlewski force-pushed the kg/run-error-handling-fixes branch from f19ef1c to de8d69d Compare January 14, 2025 11:45
@kgodlewski kgodlewski requested a review from PatrykGala January 14, 2025 11:48
@kgodlewski kgodlewski merged commit 879bc65 into main Jan 14, 2025
9 checks passed
@kgodlewski kgodlewski deleted the kg/run-error-handling-fixes branch January 14, 2025 12:49
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants