triggers: EventListener sometimes fails to resolve binding

Hi,

for our tekton deployment, sometimes we see EventListeners failing to process events with the following information in the log

{"level":"error","logger":"eventlistener","caller":"sink/sink.go:225","msg":"failed to resolve bindings: error getting TriggerBinding : triggerbinding.triggers.tekton.dev \"visit-management-system-vmsbackend-pr\" not found","knative.dev/controller":"eventlistener","/triggers-eventid":"pprlz","/trigger":"visit-management-system-vmsbackend-pr","stacktrace":"github.com/tektoncd/triggers/pkg/sink.Sink.processTrigger\n\tgithub.com/tektoncd/triggers/pkg/sink/sink.go:225\ngithub.com/tektoncd/triggers/pkg/sink.Sink.HandleEvent.func1\n\tgithub.com/tektoncd/triggers/pkg/sink/sink.go:129"}

The mentioned TriggerBinding however exists. Do you have an idea why this fails sometimes? Is there anything i can check?

Thanks, Fabian

EventListener

apiVersion: triggers.tekton.dev/v1alpha1
kind: EventListener
metadata:
  creationTimestamp: "2020-12-21T15:43:58Z"
  finalizers:
  - eventlisteners.triggers.tekton.dev
  generation: 1
  labels:
    beekeeper/scope: Namespace
  name: visit-management-system-vmsbackend
  namespace: site-itscb
  ownerReferences:
  - apiVersion: beekeeper.sap.it/v1alpha1
    kind: NeoJavaApplication
    name: visit-management-system-vmsbackend
    uid: e5d1c689-4531-482e-8d32-a783e0def219
  resourceVersion: "438851105"
  selfLink: /apis/triggers.tekton.dev/v1alpha1/namespaces/site-itscb/eventlisteners/visit-management-system-vmsbackend
  uid: 542a307f-b1cb-48e8-8173-09498e073441
spec:
  podTemplate: {}
  resources: {}
  serviceAccountName: tekton-triggers-listener
  triggers:
  - bindings:
    - kind: TriggerBinding
      ref: visit-management-system-vmsbackend-ci-master
    interceptors:
    - cel:
        filter: body.ref == 'refs/heads/master'
    name: visit-management-system-vmsbackend-ci-master
    template:
      name: visit-management-system-vmsbackend-ci-master
  - bindings:
    - kind: TriggerBinding
      ref: visit-management-system-vmsbackend-pr
    interceptors:
    - cel:
        filter: body.ref != 'refs/heads/master'
    name: visit-management-system-vmsbackend-pr
    template:
      name: visit-management-system-vmsbackend-pr
status:
  address:
    url: http://el-visit-management-system-vmsbackend.site-itscb.svc.cluster.local:8080
  conditions:
  - lastTransitionTime: "2021-01-13T11:05:21Z"
    message: Deployment has minimum availability.
    reason: MinimumReplicasAvailable
    status: "True"
    type: Available
  - lastTransitionTime: "2021-01-13T11:05:21Z"
    message: Deployment exists
    status: "True"
    type: Deployment
  - lastTransitionTime: "2021-01-07T17:12:03Z"
    message: ReplicaSet "el-visit-management-system-vmsbackend-c57b9949b" has successfully
      progressed.
    reason: NewReplicaSetAvailable
    status: "True"
    type: Progressing
  - lastTransitionTime: "2021-01-13T11:05:21Z"
    message: Service exists
    status: "True"
    type: Service
  configuration:
    generatedName: el-visit-management-system-vmsbackend

TriggerBinding

apiVersion: triggers.tekton.dev/v1alpha1
kind: TriggerBinding
metadata:
  creationTimestamp: "2020-12-21T15:57:59Z"
  generation: 1
  labels:
    beekeeper/scope: NeoJavaApplication-visit-management-system-vmsbackend
  name: visit-management-system-vmsbackend-pr
  namespace: site-itscb
  ownerReferences:
  - apiVersion: beekeeper.sap.it/v1alpha1
    kind: NeoJavaApplication
    name: visit-management-system-vmsbackend
    uid: e5d1c689-4531-482e-8d32-a783e0def219
  resourceVersion: "350591728"
  selfLink: /apis/triggers.tekton.dev/v1alpha1/namespaces/site-itscb/triggerbindings/visit-management-system-vmsbackend-pr
  uid: 8d13d32b-9c9b-4833-83c1-b9fd9b65bb24
spec:
  params:
  - name: revision
    value: $(body.head_commit.id)

Additional Info

  • Kubernetes version: v1.18.12
  • Tekton Pipeline version: v0.19.0
  • Tekton Triggers version: v0.10.2

About this issue

  • Original URL
  • State: closed
  • Created 3 years ago
  • Comments: 15 (12 by maintainers)

Commits related to this issue

Most upvoted comments

@dibyom awesome digging. this makes a ton of sense. if you implement 2, i would also remove the hack that fails when the el resolution fails

so when the pods get restarted, you get the error message for a while and then everything works? Or is the error continuous?

Hehe, happens to me all the time 😄

The log message was from today, the trigger, and the event listener was created last year. I do not know for how long the pod of the event listener existed tough.

Embedding sounds like a good idea, I ´ll definitely try this