fix(git_utils): raise and log on git push failure
@venkat82checks…fix/push-branch-raise-on-failure → next3 files · +55 −7updated 1mo agoloading diff…
@venkat82checks…fix/push-branch-raise-on-failure → next3 files · +55 −7updated 1mo ago@venkat82checks…fix/push-branch-raise-on-failure → next3 files · +55 −7updated 1mo agoWorkflow xg8mfm9r (staging, create-app twilio) built 119 passing actions end-to-end, but failed at the final step with a confusing 422 {field: head, code: invalid} from POST /repos/ComposioHQ/mercury/pulls. The actual cause was not the PR-create call — it was the preceding git push, which failed but was silently discarded. The 119 committed-locally actions were then lost with the ECS container, and the 422 sent the investigation down a GitHub-side rabbit hole.
Root cause in code:
execute_command (cortex/common/utils.py) returns (stdout, sentinel) on non-zero exit — it does not raise._run_command / _run_command_with_token (cortex/common/git_utils.py) forward the tuple unchanged._push_branch (cortex/common/git_utils.py:154) discards the return value entirely — no return-code check, no logging.create_pr then calls _create_pr immediately after, so a silent push failure surfaces only as 422 head:invalid._push_branch now captures (out, err) from the subprocess, logs both at ERROR on failure, and raises RuntimeError with the underlying stderr/output so the workflow fails fast with a clear message.Pushed branch X to origin) for observability.bugbot_fix._push_changes to also catch RuntimeError (in addition to the existing subprocess.CalledProcessError) so its False-return contract is preserved.test_push_branch_raises_on_failure to pin the new behavior and guard against regression.uv run pytest cortex/tests/test_common/test_git_utils.py -v — all 21 tests pass (20 pre-existing + 1 new).make fmt && make chk — clean.GITHUB_ACCESS_TOKEN to an intentionally invalid value in a staging env, trigger a create-app run, verify the workflow fails at _push_branch with a clear git push failed for branch … message in Datadog instead of a later 422 from /pulls._run_command/_run_command_with_token at large, because other callers (e.g., _check_if_diff) rely on the current soft-failure semantics. Only _push_branch's contract changes.xg8mfm9r — that container was already gone by the time the root cause was visible. But it would have turned the next-run experience from "confusing 422 forensics" into "clear push error in run_log," and makes the silent-failure class of bug impossible in the PR-creation path.