retry: fail loud when deadline_s is used off the main thread#711
Draft
kmontemayor2-sc wants to merge 5 commits into
Draft
retry: fail loud when deadline_s is used off the main thread#711kmontemayor2-sc wants to merge 5 commits into
kmontemayor2-sc wants to merge 5 commits into
Conversation
retry(deadline_s=...) enforces the deadline with a SIGALRM timeout, which CPython only permits in the main thread of the main interpreter. Reached from a worker thread it raised the opaque "signal only works in main thread of the main interpreter" ValueError from signal.signal. Guard the deadline path: off the main thread, raise a RuntimeError that names the decorated function and points the caller at enforcing the deadline on the operation itself (e.g. a client-native timeout). Main-thread behavior is unchanged. Adds a test for the off-main-thread path. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Follow-up on the previous commit per review: drop the explanatory comment (the RuntimeError message is self-explanatory), drop the unnecessary type: ignore[type-var] on the wrapper (ty passes without it), and remove the unit test. Net change on this branch is just the guard. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
yliu2-sc
approved these changes
Jul 20, 2026
Co-authored-by: yliu2-sc <142346463+yliu2-sc@users.noreply.github.com>
svij-sc
reviewed
Jul 20, 2026
| @wraps(f) | ||
| def f_retry_with_deadline(*args, **kwargs) -> T: | ||
| if threading.current_thread() is not threading.main_thread(): | ||
| raise RuntimeError( |
Collaborator
There was a problem hiding this comment.
this reads as an odd RuntimeError.
Is this what we really want vs. somehting more descriptive of what the issue was? i.e. we failed __ after __x tries, n time, in ___ thread/process.
Collaborator
Author
There was a problem hiding this comment.
This change isn't about the timeout or retry failing. The code (as it stands) currently fails, and I'm adding a new error message that's hopefully more descriptive. the issue here is that we can't use deadline_s on non-main threads (python only lets you use sigalarm on main thread).
I can re-word this to be more descriptive.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
retry(deadline_s=...) enforces the deadline with a SIGALRM timeout, which CPython only permits in the main thread of the main interpreter. Reached from a worker thread it raised the opaque "signal only works in main thread of the main interpreter" ValueError from signal.signal.
Guard the deadline path: off the main thread, raise a RuntimeError that names the decorated function and points the caller at enforcing the deadline on the operation itself (e.g. a client-native timeout). Main-thread behavior is unchanged. Adds a test for the off-main-thread path.
This keeps the same behavior (failing if we use this var wrong) just provides better error mesasges :)
Scope of work done
Where is the documentation for this feature?: N/A
Did you add automated tests or write a test plan?
Updated Changelog.md? NO
Ready for code review?: NO