Skip to content

Add self-reply guard to functions:init scaffold#72

Merged
etbyrd merged 2 commits into
mainfrom
scaffold-self-reply-guard
May 11, 2026
Merged

Add self-reply guard to functions:init scaffold#72
etbyrd merged 2 commits into
mainfrom
scaffold-self-reply-guard

Conversation

@etbyrd
Copy link
Copy Markdown
Member

@etbyrd etbyrd commented May 11, 2026

Summary

  • Lift the placeholder sender address in the scaffolded handler into a named REPLY_FROM constant with a clear TODO marker so new authors do not miss the replace-me step.
  • Add a self-reply guard at the top of the email.received branch so a forwarded outbound reply does not trigger an infinite reply loop.
  • Add a recipient-routing comment block above client.send pointing at event.email.headers.to for multi-address fan-out patterns.

Test plan

  • pnpm lint
  • pnpm typecheck
  • pnpm test (168 passed, including 4 new assertions covering the REPLY_FROM const + TODO, the self-reply guard predicate, the recipient-routing comment, and the single-occurrence placeholder count)

@greptile-apps
Copy link
Copy Markdown

greptile-apps Bot commented May 11, 2026

Greptile Summary

This PR hardens the functions:init scaffold against infinite-reply loops by lifting the placeholder sender address into a named REPLY_FROM constant and adding a self-reply guard that uses a substring check (.includes()) to correctly match both bare addresses and RFC 2822 display-name forms.

  • The REPLY_FROM constant replaces two duplicated string literals in the client.send() call; a TODO comment immediately above the declaration ensures new authors notice the required replace-me step before deploying.
  • The self-reply guard (event.email.headers.from?.includes(REPLY_FROM)) is placed before the SDK call so that a forwarded outbound reply short-circuits cleanly with { ok: true, skipped: "self-reply" }.
  • A recipient-routing comment block above client.send surfaces the event.email.headers.to fan-out pattern, and to?: string is added to the EmailReceivedEvent interface to match.

Confidence Score: 5/5

Safe to merge — changes are confined to a code-generation scaffold with no runtime library logic, and the new guard defaults users into the safer shape.

The only behaviorally significant addition is the self-reply guard predicate. It uses .includes() rather than strict equality, which is the correct choice for raw RFC 2822 header values, and the accompanying comment documents why. The four new tests pin the exact predicate shape (including a not.toContain assertion against the strict-equality form) and verify the placeholder appears exactly once. No existing tests were modified and the scaffold changes are isolated to template string generation.

No files require special attention.

Important Files Changed

Filename Overview
cli-node/src/oclif/commands/functions-init.ts Adds REPLY_FROM constant, self-reply guard using .includes() for RFC 2822 compatibility, and recipient-routing comment; replaces duplicated string literals with the constant
cli-node/tests/oclif/functions-init.test.ts Adds 4 new test assertions covering the REPLY_FROM constant, TODO marker, self-reply guard predicate shape, recipient-routing comment, and single-occurrence placeholder count

Reviews (2): Last reviewed commit: "Make self-reply guard match RFC 2822 dis..." | Re-trigger Greptile

Comment thread cli-node/src/oclif/commands/functions-init.ts Outdated
event.email.headers.from is the raw header value, so it may carry a
display name like "Alice <alice@example.com>". Switch the guard to a
substring check so both bare and display-name forms match.
@etbyrd etbyrd merged commit 512b6fc into main May 11, 2026
9 checks passed
@etbyrd etbyrd deleted the scaffold-self-reply-guard branch May 11, 2026 17:38
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.

1 participant