Add wait for events argument to operations - #346
Merged
iLLiCiTiT merged 5 commits intoAug 21, 2026
Merged
Conversation
There was a problem hiding this comment.
Pull request overview
This PR exposes a wait_for_events flag across the batch-operations APIs so callers can choose whether the server should wait for related events before returning/marking operations complete, and wires that option through OperationsSession.commit().
Changes:
- Add
wait_for_eventsargument to batch/background operations methods and their_api.pyconvenience wrappers. - Propagate
waitForEventsinto the REST payload for operations endpoints. - Add a session-level default for
wait_for_eventsinOperationsSession, with an override oncommit().
Reviewed changes
Copilot reviewed 5 out of 5 changed files in this pull request and generated 2 comments.
Show a summary per file
| File | Description |
|---|---|
ayon_api/server_api.py |
Adds wait_for_events to ServerAPI batch/background operations and forwards it to REST calls. |
ayon_api/operations.py |
Adds wait_for_events defaults to OperationsSession and forwards it on commit. |
ayon_api/_api.py |
Exposes wait_for_events in top-level helper functions for batch/background/activities operations. |
ayon_api/_api_helpers/base.py |
Updates the _send_batch_operations interface to accept wait_for_events. |
ayon_api/_api_helpers/activities.py |
Adds wait_for_events to activities batch operations and passes it through. |
Suppressed comments (1)
ayon_api/_api.py:2724
- Similar to
send_batch_operations, adding*here makescan_fail,wait_for_events, andraise_on_failkeyword-only, which is a backward-incompatible API change for positional callers. If the library intends to preserve positional compatibility for existing code, this should be handled (or explicitly documented as a breaking change).
operations: list[dict[str, Any]],
*,
can_fail: bool = False,
wait_for_events: bool = False,
raise_on_fail: bool = True,
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
Comment on lines
1623
to
1627
| operations: list[dict[str, Any]], | ||
| *, | ||
| can_fail: bool = False, | ||
| wait_for_events: bool = False, | ||
| raise_on_fail: bool = True, |
Comment on lines
1639
to
1643
| can_fail (bool): Server will try to process all | ||
| operations even if one of them fails. | ||
| wait_for_events (bool): The operations are marked as done before | ||
| related events are triggered on server. | ||
| raise_on_fail (bool): Raise exception if an operation |
Member
There was a problem hiding this comment.
"Wait for events to be processed on server" does sound clearer?
iLLiCiTiT
deleted the
enhancement/345-expose-waitforevents-on-background-operations
branch
August 21, 2026 12:48
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
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.
Changelog Description
Operations do define
wait_for_eventsargument to be defined.Additional review information
The option is available for a very long time, it was added before
raise_on_failso it does not require any additional validations (1.10.3). By default it is set toFalsewhich seems to be matching the server default.Testing notes:
Resolves #345