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
- sink: Sync lister informers before serving traffic Previously, we had a race where the EL would start serving traffic before the lister caches were synced. This leads to the intermittent resolution i... — committed to dibyom/triggers by dibyom 3 years ago
- sink: Sync lister informers before serving traffic Previously, we had a race where the EL would start serving traffic before the lister caches were synced. This leads to the intermittent resolution i... — committed to dibyom/triggers by dibyom 3 years ago
- sink: Sync lister informers before serving traffic Previously, we had a race where the EL would start serving traffic before the lister caches were synced. This leads to the intermittent resolution i... — committed to dibyom/triggers by dibyom 3 years ago
- sink: Sync lister informers before serving traffic Previously, we had a race where the EL would start serving traffic before the lister caches were synced. This leads to the intermittent resolution i... — committed to dibyom/triggers by dibyom 3 years ago
- sink: Sync lister informers before serving traffic Previously, we had a race where the EL would start serving traffic before the lister caches were synced. This leads to the intermittent resolution i... — committed to dibyom/triggers by dibyom 3 years ago
- sink: Sync lister informers before serving traffic Previously, we had a race where the EL would start serving traffic before the lister caches were synced. This leads to the intermittent resolution i... — committed to tektoncd/triggers by dibyom 3 years ago
@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