[aThorp96]: > One thing I noticed is that completed ResolutionRequests currently act as per-Run cached storage in some paths: PipelineRuns can re-read them for tasks that haven't started yet, and PipelineRun/TaskRun can share the same ResolutionRequest to avoid resolving the same remote Task twice. Hmm, I don't think I was aware of this, but it certainly would add complexity to the lifecycle. I did find allusion to a ResolutionRequest having multiple ownerRefs, but the field itself is never updated to include the respective taskRefs. Before implementation, we should clarify exactly what the lifecycle of ResolutionRequests are in relation to their PipelineRun and TaskRun. Also, the ResolutionRequest API is used by other non-tekton services to resolve other Tekton types like PipelineRun definitions, so we should keep in mind that we can't assume a given ResolutionRequest must be owned by a Run object; we have to either get that ownership from the ownerRef field or from the context of a Run's reconciliation.

Context: GitHub issue tektoncd/pipeline#10692 (open, 5 comments, reported 2026-09-03): ### Feature request When a PipelineRun references a Pipeline using a resolver, and the Pipeline references Tasks using resolvers, the PipelineRun starts once the ResolutionRequests for the Pipeline and each Task are completed. At this point, the ResolutionRequests are complete and serve no purpose (as far as I can tell). They can be deleted while their parent PipelineRun executes without side effects. Especially since all of a PipelineRun's Task's ResolutionRequests have their PipelineRun as their owner; if a pipelineRun references a large but quick task and afterwards runs a small but lon