Skip to content

fix: scope getDynamicEmail to referenced placeholder (fixes #53)#56

Open
rishishanbhag wants to merge 1 commit into
bug0inc:mainfrom
rishishanbhag:fix/get-dynamic-email-scoping
Open

fix: scope getDynamicEmail to referenced placeholder (fixes #53)#56
rishishanbhag wants to merge 1 commit into
bug0inc:mainfrom
rishishanbhag:fix/get-dynamic-email-scoping

Conversation

@rishishanbhag

Copy link
Copy Markdown

Summary

Fixes #53 by scoping getDynamicEmail to the dynamic email placeholder the step set actually references, instead of always preferring the global inbox whenever executionId is set.

Problem

When runSteps was called with an executionId, getDynamicEmail() always returned {{global.dynamicEmail}} — even if the steps only used {{run.dynamicEmail}}.

Root cause:

  • generateGlobalValues() always creates a {{global.dynamicEmail}} when an email domain is configured and executionId is present.
  • getDynamicEmail used globalValues?.["{{global.dynamicEmail}}"] || localValues["{{run.dynamicEmail}}"], so the global value was always truthy and the run-scoped fallback was never used.
  • As a result, {{email.extract(...)}} (e.g. {{email.otp:get the OTP}}) queried the wrong inbox — the shared global address instead of the run-specific one filled in earlier in the same runSteps call.

Solution

Introduced a reference-based preference computed from the raw steps and assertions before placeholder substitution:

Step set references | dynamicEmailPreference | Inbox used for {{email.extract(...)}} -- | -- | -- {{global.dynamicEmail}} | "global" | Shared execution inbox Only {{run.dynamicEmail}} | "run" | Fresh per-call inbox (fixes the bug) Neither | "auto" | Global if available (preserves cross-call OTP flows)

Changes

src/data-cache.ts

  • Added DynamicEmailPreference type and computeDynamicEmailPreference() to scan steps/assertions for {{run.dynamicEmail}} and {{global.dynamicEmail}}.
  • processPlaceholders() now returns dynamicEmailPreference alongside processed steps and values.
  • getDynamicEmail() accepts a third preference argument and routes to the correct inbox.

src/index.ts

  • Threads dynamicEmailPreference from processPlaceholders into getDynamicEmail in the per-step loop.
  • Removed the stale ~~~ This logic needs to be fixed ... comment.

src/__tests__/data-cache.test.ts

  • Added tests for computeDynamicEmailPreference, updated getDynamicEmail tests for all three preference modes, and added processPlaceholders coverage for run-only, global, and no-reference step sets.

Resolve {{email.extract(...)}} against run-scoped inbox when steps only
use {{run.dynamicEmail}}, while preserving global inbox for cross-call OTP flows.
@rishishanbhag

rishishanbhag commented Jun 11, 2026

Copy link
Copy Markdown
Author

Hey @panda-sandeep @unclebay143 , would you mind reviewing this when you get a chance? Fixes #53

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

bug: getDynamicEmail always returns global email when executionId is provided

1 participant