fix(workflows): refresh org per execution and gate metadata OrgID#22311
fix(workflows): refresh org per execution and gate metadata OrgID#22311prashantkumar1982 wants to merge 2 commits intodevelopfrom
Conversation
Resolve workflow org at subscribe and at each execution start, thread it into SecretsFetcher and ExecutionHelper, and re-bind CRE for tracing and confidential execution. Add enrichRequestMetadataOrg for trigger register/unregister and capability calls; confidential-workflows sets OrgId and metadata OrgID only when VaultOrgIdAsSecretOwnerEnabled is on. Close gate limiters in tests via t.Cleanup. Co-authored-by: Cursor <cursoragent@cursor.com>
|
I see you updated files related to
|
|
✅ No conflicts with other open PRs targeting |
Co-authored-by: Cursor <cursoragent@cursor.com>
|
You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard. |
| Config: values.EmptyMap(), | ||
| } | ||
|
|
||
| if err = c.enrichRequestMetadataOrg(ctx, &capReq.Metadata, c.ExecutionOrgID); err != nil { |
There was a problem hiding this comment.
Why do we need to resolve it on every execution? I was just discussing with @ibrajer that we could do the opposite - resolve the org once and store it in the DB for all future executions and other workflows.
There was a problem hiding this comment.
The question is how tolerant are we for stale orgIDs.
Since we can re-link a workflow owner with a different orgID, it means orgIDs can go stale.
|




Resolve workflow org at subscribe and at each execution start, thread it into SecretsFetcher and ExecutionHelper, and re-bind CRE for tracing and confidential execution. Add enrichRequestMetadataOrg for trigger register/unregister and capability calls; confidential-workflows sets OrgId and metadata OrgID only when VaultOrgIdAsSecretOwnerEnabled is on. Close gate limiters in tests via t.Cleanup.
This is fixing a regression caused by a previous PR here: https://github.com/smartcontractkit/chainlink/pull/21715/changes#diff-d217f82a818cadc25ef1cfd01b67b55b5ce2b86a5256af94d3472de4d4a24f56L619-L632
Then, we only resolved OrgID during engine startup.