mirror of
https://github.com/zitadel/zitadel.git
synced 2026-10-26 16:10:11 -05:00
Temuri Takalandze
5ca0b54ca3
# Which Problems Are Solved Actions v2 targets with `PAYLOAD_TYPE_JWT` or `PAYLOAD_TYPE_JWE` never fire when the execution is triggered by an event. The target endpoint receives no request at all, and the only symptom is a repeated server log: ``` level=error msg="error calling target" instanceID= target=<target-id> error="ID=QUERY-Opoh7 Message=Errors.WebKey.NoActive Parent=(sql: no rows in result set)" ``` Targets with `PAYLOAD_TYPE_JSON` on the same events work, because that path never signs the payload. The async River worker builds its context with `ContextWithExecuter`, which sets `authz.CtxData` but not the instance. `payloadJWT` then resolves the signing key through `Queries.GetActiveSigningWebKey`, which looks it up by `authz.GetInstance(ctx).InstanceID()`. That value is empty, so the query runs against `instance_id = ''` and returns no rows, even when the instance has an active web key. Because the error is returned before the HTTP call and targets commonly run with `interruptOnError` false, it is only logged and the job is still reported as processed, so the failure is silent. # How the Problems Are Solved `ContextWithExecuter` now takes the instance ID from the aggregate it already receives, the same way `HandlerContext` does directly above it. # Additional Changes - `Test_handleEventExecution` called `Work` with an instance already on the context, which does not match how River invokes the worker. It now passes a plain `context.Background()`. - The signing key function used by the worker test resolves the key for the instance on the context, mirroring `Queries.GetActiveSigningWebKey`. Together with the change above, the existing JSON/JWT/JWE case now fails without the fix. - Adds a unit test for `ContextWithExecuter`. # Additional Context - Closes #11985 - Reproduced on a self hosted v4.15.3 instance: REST webhook target, `PAYLOAD_TYPE_JWE`, execution bound to the `user` event group. The instance had an active web key (`projections.web_keys1.state = 2`) and the same target delivered normally with `PAYLOAD_TYPE_JSON`. - Verified locally: `go test ./internal/execution/...` passes with the fix, and `Test_handleEventExecution/multiple` plus `TestContextWithExecuter` fail with it reverted, reproducing `no active signing web key for instance ""`.