Manual merge stable into release-1.10

[polmichel]

Supersedes #9529, which was blocked on merge conflicts.

Summary

Merges stable into release-1.10. This forward-ports the repository-lock-narrowing work (only guarding clone/fetch/worktree mutations, running object import after the lock is released) plus the CommitNotFoundError hardening.

Conflicts resolved

• backend/infrahub/git/integrator.py — both sides edited the same import region. stable widened from infrahub import config to config, lock; release-1.10 added AnonymousSession and InfrahubContext. Kept all three imports.
• backend/infrahub/git/tasks.py — both sides edited the same import region. stable added CommitNotFoundError; release-1.10 added GitRepositoryNodeQuery. Kept both.

Both were mechanical import collisions. The rest of the refactor (infrahub/git/sync.py, RepositorySyncer/RepositoryAdder/RepositoryFileImporter, the sync → collect_pending_imports split, lock test adapter) auto-merged. Verified the auto-merge is correct: all kept imports are used, every .sync( call site uses the new component API (no stale old-API calls), and release-1.10's GitRepositoryNodeQuery usages live in separate functions from the refactored sync path.

Conflicts raised for review

None — both conflicts were mechanical.

Generated files regenerated

None — the merge touched no generated files.

Validation

• py_compile, ruff check, ty check — all pass on the changed git module.
• backend/tests/unit/adapters/test_lock.py — 6/6 pass.
• Not run locally (need a live stack): backend/tests/component/git/{test_git_repository,test_git_rpc,test_sync_lock_scope}.py and the integration suite — CI covers these.

---

Summary by cubic

Merges stable into release-1.10, forward‑porting narrower Git repository locking and CommitNotFoundError hardening. Imports now run outside the repo lock; missing commits are fetched once during init under the lock.

• Refactors

  • Narrow repository lock to only clone/fetch/worktree mutations; run object import after lock release via RepositorySyncer, RepositoryAdder, and RepositoryFileImporter.
  • Split sync into collect_pending_imports (under lock) and an import loop (outside lock); pin the exact commit during the locked phase before importing.
  • Isolate per-branch git failures while collecting imports so other branches still sync.

• Bug Fixes

  • create_commit_worktree raises CommitNotFoundError when a commit is missing locally; InfrahubRepository.init fetches once under the repository lock and retries.
  • Tasks catch CommitNotFoundError alongside RepositoryError to tag/skip instead of aborting; worker notifications include the pinned commit via RefreshGitFetch.
  • Added a recording lock test adapter to verify imports occur after the lock is released.

^{Written for commit 1c0ad67. Summary will update on new commits.}

[cubic-dev-ai]

1 issue found

Confidence score: 3/5

• There is a concrete regression risk in backend/infrahub/git/repository.py: an uncaught staging pull failure can terminate sync early, which may skip applying imports already collected from other branches.
• The issue is high-confidence and medium-high severity (7/10, confidence 9/10), so this is more than a minor edge-case and could affect user-visible sync completeness.
• Pay close attention to backend/infrahub/git/repository.py - ensure staging pull errors are handled so sync can continue or fail in a controlled way without dropping previously gathered imports.

Prompt for AI agents (unresolved issues)

Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.


<file name="backend/infrahub/git/repository.py">

<violation number="1" location="backend/infrahub/git/repository.py:194">
P1: Uncaught staging pull failure can abort sync before applying already-collected imports from other branches.</violation>
</file>

<sub>Shadow auto-approve: would not auto-approve because issues were found.

Re-trigger cubic</sub>

[cubic-dev-ai]

P1: Uncaught staging pull failure can abort sync before applying already-collected imports from other branches.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At backend/infrahub/git/repository.py, line 194:

<comment>Uncaught staging pull failure can abort sync before applying already-collected imports from other branches.</comment>

<file context>
@@ -121,26 +176,36 @@ async def sync(self, staging_branch: str | None = None) -> None:
-                    f"An update was detected but the commit remained the same after pull() ({commit_after}).",
-                    repository=self.name,
-                    branch=self.default_branch,
+        commit_after = await self.pull(branch_name=self.default_branch)
+        if isinstance(commit_after, str):
+            return [
</file context>

Suggested change

	commit_after = await self.pull(branch_name=self.default_branch)
	try:
	commit_after = await self.pull(branch_name=self.default_branch)
	except (RepositoryError, CommitNotFoundError, GitCommandError, ValueError) as exc:
	log.warning(
	"Failed to pull staging source branch for import, skipping it.",
	repository=self.name,
	branch=self.default_branch,
	exc_info=exc,
	)
	return []

[polmichel]

This could be an issue in the future if the code changes that's true. But for now, there is no other branch to collect import from when reaching this code.

• If self.internal_status == RepositoryInternalStatus.STAGING.value is True, there is no import collected before reaching the point.
• If self.internal_status == RepositoryInternalStatus.ACTIVE.value, then this code returns early.

[cubic-dev-ai]

Got it — thanks for the clarification.

[codspeed-hq]

Merging this PR will not alter performance

✅ 12 untouched benchmarks

---

_{Comparing pmi-merge-stable-into-release-1.10 (1c0ad67) with release-1.10 (cb093c7)}