LocalResource reports Available after its commit is gone from the target branch #29

Found during the provider-runtime v1.7.0 upgrade's Observe audit (#28). Traced in code, line by line at 19577e9. Not reproduced by a test or a live run yet.

Symptom

A LocalResource that has committed once keeps reporting Available / up to date after its commit disappears from the target branch. The file is never re-committed, and nothing recovers on its own. The only ways out are editing the status by hand or recreating the CR.

Triggers:

• the target repository is recreated;
• the target branch is force-pushed or rewritten;
• the target branch is deleted. IsFuncInGitCommitHistory returns a zero hash and a nil error on "couldn't find remote ref" (internal/clients/git/git.go:444-446).

An empty target repository doesn't take this path: the clone errors, and Observe returns that error.

Trace (internal/controllers/localresource/localresource.go)

1. :196-198: if status.targetCommitId is set, Observe copies it into the external name before reading the remote.
2. :201-228: IsFuncInGitCommitHistory clones the target branch. Its callback marks "previously committed" only when a commit footer names this namespace/name, and matches when the footer's spec hash equals the current one.
3. :229-243: three branches.
   • Zero hash with a prior commit → exists:true, upToDate:false, so Update runs.
   • A matching hash with a prior commit → adopt that commit.
   • Anything else → the else at :241, which only logs at debug level.
4. :245: the existence check reads the external name, which is still the stale targetCommitId from step 1. It is non-empty, so the check passes.
5. :252-257: Available, ResourceExists:true, ResourceUpToDate:true.

The runtime therefore calls neither Create nor Update.

Contrast with Repo

repo.go:178-188 checks that its recorded commit is still in the target history. If it isn't, Repo errors when enableUpdate: false (:210, deliberate, pinned by TC12/TC13) or answers upToDate:false so Update re-pushes. LocalResource has no equivalent check for its recorded commit.

Open question (product)

Should LocalResource re-commit after the target is rewritten? It has spec.syncEnabled where Repo has enableUpdate.

If yes, the likely fix: when targetCommitId is set but no footer commit for this resource is found, answer upToDate:false (Update, gated by syncEnabled), or ResourceExists:false. Create converges (:542-549), so neither duplicates a commit. It needs a test that rewrites the target branch; the existing "Recreate" cases (localresource_test.go:743, :839-871) recreate the CR, not the target.

Related, low impact, not traced to an outcome

The history callback's match (:219-224) accepts a commit whose spec hash matches even when its footer names a different namespace/name. The hash (internal/controllers/common/footer/footer.go:25-33) covers the source, the target URL/path/branch and the placeholders, not the CR's identity, so two LocalResources with identical specs could match each other's commit.

🤖 Generated with Claude Code

https://claude.ai/code/session_016RAxvjZaJueRyPRKkxVde4