it contains Tasks that don't exist: Couldn't retrieve Task ""

[jihwong]

Expected Behavior

Expect pipelinerun to run normally

Actual Behavior

Running again is normal, and this error occasionally occurs.

Discover through webhook logs. Creating a resolutionrequest normally will result in three "knative.dev/operation":"CREATE" records. But the cluster-564cb716f353f3b29acf2eeae11d0d07 has six records

#k logs -n tekton-pipelines tekton-pipelines-webhook-696cb8f894-kvwg8 |grep 6c189aca7abcb406496e8aa9bbb5fd5d|grep CREATE|wc -l
3

#k logs -n tekton-pipelines tekton-pipelines-webhook-696cb8f894-kvwg8 |grep 564cb716f353f3b29acf2eeae11d0d07 |grep CREATE|wc -l
6

resolutionrequests (There are usually three records, but an error occurs when the second record is created)

#k get resolutionrequests -n NAMESPACE |grep XXX
cluster-564cb716f353f3b29acf2eeae11d0d07   PipelineRun   XXX   True                 2023-03-20T15:26:16Z   2023-03-20T15:26:16Z
cluster-5ed0564a1b690a9c48c1da7294932a56   PipelineRun   XXX   True                 2023-03-20T15:26:15Z   2023-03-20T15:26:15Z

pipelinerun.status content

status:
  completionTime: "2023-03-20T15:26:16Z"
  conditions:
  - lastTransitionTime: "2023-03-20T15:26:16Z"
    message: 'Pipeline NAMESPACE/PIPELINERUN_NAME can''t be Run; it contains
      Tasks that don''t exist: Couldn''t retrieve Task "": error requesting remote
      resource: resolutionrequests.resolution.tekton.dev "cluster-564cb716f353f3b29acf2eeae11d0d07"
      already exists'
    reason: CouldntGetTask
    status: "False"
    type: Succeeded

Additional Info

• Tekton Pipeline version:
  v0.41.0

[l-qing]

Yes, this is a bug. The relevant code is here:

pipeline/pkg/resolution/resource/crd_resource.go

Lines 51 to 61 in a088215

	// Submit constructs a ResolutionRequest object and submits it to the
	// kubernetes cluster, returning any errors experienced while doing so.
	// If ResolutionRequest is succeeded then it returns the resolved data.
	func (r *CRDRequester) Submit(ctx context.Context, resolver ResolverName, req Request) (ResolvedResource, error) {
	rr, _ := r.lister.ResolutionRequests(req.Namespace()).Get(req.Name())
	if rr == nil {
	if err := r.createResolutionRequest(ctx, resolver, req); err != nil {
	return nil, err
	}
	return nil, resolutioncommon.ErrRequestInProgress
	}

I think we can ignore the already exists error and wait for the next reconciliation. Such as:

func (r *CRDRequester) Submit(ctx context.Context, resolver ResolverName, req Request) (ResolvedResource, error) {
	rr, err := r.lister.ResolutionRequests(req.Namespace()).Get(req.Name())
	if rr == nil {
		if err := r.createResolutionRequest(ctx, resolver, req); err != nil && !apierrors.IsAlreadyExists(err) {
			return nil, err
		}
		return nil, resolutioncommon.ErrorRequestInProgress
	}

In my environment, fixing it this way can avoid that error. Not sure if there will be any other issues.

[jihwong]

Yes, this is a bug. The relevant code is here:

pipeline/pkg/resolution/resource/crd_resource.go

Lines 51 to 61 in a088215

	// Submit constructs a ResolutionRequest object and submits it to the
	// kubernetes cluster, returning any errors experienced while doing so.
	// If ResolutionRequest is succeeded then it returns the resolved data.
	func (r *CRDRequester) Submit(ctx context.Context, resolver ResolverName, req Request) (ResolvedResource, error) {
	rr, _ := r.lister.ResolutionRequests(req.Namespace()).Get(req.Name())
	if rr == nil {
	if err := r.createResolutionRequest(ctx, resolver, req); err != nil {
	return nil, err
	}
	return nil, resolutioncommon.ErrRequestInProgress
	}

I think we can ignore the already exists error and wait for the next reconciliation. Such as:

func (r *CRDRequester) Submit(ctx context.Context, resolver ResolverName, req Request) (ResolvedResource, error) {
	rr, err := r.lister.ResolutionRequests(req.Namespace()).Get(req.Name())
	if rr == nil {
		if err := r.createResolutionRequest(ctx, resolver, req); err != nil && !apierrors.IsAlreadyExists(err) {
			return nil, err
		}
		return nil, resolutioncommon.ErrorRequestInProgress
	}

In my environment, fixing it this way can avoid that error. Not sure if there will be any other issues.

Thank
I modified it in my environment and ran it for a while to see if it worked properly