Component
Python SDK
Describe the Feature Request
branch.merge(), branch.rebase() and branch.validate() always run synchronously and cannot be asked to return a task instead. The server supports the non-blocking mode on all three; the SDK simply never passes the flag.
Server side, in backend/infrahub/graphql/mutations/branch.py, each of BranchMerge, BranchRebase and BranchValidate declares:
wait_until_completion = Boolean(required=False)
...
task = Field(TaskInfo, required=False)
and each resolver branches on it — execute_workflow (blocking) when true, submit_workflow plus a returned task id when false. The resolver default is True.
SDK side, in infrahub_sdk/branch.py, wait_until_completion appears only in create() (:92 async, :227 sync). merge, rebase, validate and delete hardcode their mutation query and never send the flag, so they always get the server's blocking default. MUTATION_QUERY_TASK = {"ok": None, "task": {"id": None}} already exists at :55 for exactly this purpose and is unused by those methods.
create() already demonstrates the shape to follow, including the Literal[True] / Literal[False] overloads that give callers a precise return type.
Describe the Use Case
Merging a large branch blocks the caller for as long as the merge takes. merge() compensates with timeout=max(120, self.client.default_timeout), but a floor is not a fix — a big enough merge still exceeds it, and the caller then sees a timeout for an operation that is proceeding normally server-side.
This is the mechanism behind #304 (infrahubctl branch merge should not time out for branches with a lot of changes). That issue asks for "similar behavior to how the schema load command works, where we can instruct the command to wait" — which is precisely wait_until_completion=False plus the returned task id. The capability is already there on the server; only the client plumbing is missing, so #304 cannot be solved cleanly without this.
It also matters to any non-interactive consumer that wants to trigger a merge and poll client.task for the outcome rather than holding an HTTP connection open. The task manager already has wait_for_completion(), retry() and cancel() to consume the returned id.
Additional Information
Consider delete() too — it takes the same server flag and has the same hardcoded query, though a slow delete is less likely to be a problem in practice.
Related: #304 (the motivating CLI symptom), #374 (the same flag mishandled on create, since fixed).
Found while auditing which SDK capabilities the opsmill.infrahub Ansible collection does not yet expose; the collection cannot offer a non-blocking merge for the same reason. Related collection issue: opsmill/infrahub-ansible#395.
Component
Python SDK
Describe the Feature Request
branch.merge(),branch.rebase()andbranch.validate()always run synchronously and cannot be asked to return a task instead. The server supports the non-blocking mode on all three; the SDK simply never passes the flag.Server side, in
backend/infrahub/graphql/mutations/branch.py, each ofBranchMerge,BranchRebaseandBranchValidatedeclares:and each resolver branches on it —
execute_workflow(blocking) when true,submit_workflowplus a returned task id when false. The resolver default isTrue.SDK side, in
infrahub_sdk/branch.py,wait_until_completionappears only increate()(:92async,:227sync).merge,rebase,validateanddeletehardcode their mutation query and never send the flag, so they always get the server's blocking default.MUTATION_QUERY_TASK = {"ok": None, "task": {"id": None}}already exists at:55for exactly this purpose and is unused by those methods.create()already demonstrates the shape to follow, including theLiteral[True]/Literal[False]overloads that give callers a precise return type.Describe the Use Case
Merging a large branch blocks the caller for as long as the merge takes.
merge()compensates withtimeout=max(120, self.client.default_timeout), but a floor is not a fix — a big enough merge still exceeds it, and the caller then sees a timeout for an operation that is proceeding normally server-side.This is the mechanism behind #304 (
infrahubctl branch mergeshould not time out for branches with a lot of changes). That issue asks for "similar behavior to how theschema loadcommand works, where we can instruct the command to wait" — which is preciselywait_until_completion=Falseplus the returned task id. The capability is already there on the server; only the client plumbing is missing, so #304 cannot be solved cleanly without this.It also matters to any non-interactive consumer that wants to trigger a merge and poll
client.taskfor the outcome rather than holding an HTTP connection open. The task manager already haswait_for_completion(),retry()andcancel()to consume the returned id.Additional Information
Consider
delete()too — it takes the same server flag and has the same hardcoded query, though a slow delete is less likely to be a problem in practice.Related: #304 (the motivating CLI symptom), #374 (the same flag mishandled on
create, since fixed).Found while auditing which SDK capabilities the
opsmill.infrahubAnsible collection does not yet expose; the collection cannot offer a non-blocking merge for the same reason. Related collection issue: opsmill/infrahub-ansible#395.