Skip to main content

Scenario Email Optional Implementation

Overview

This document describes the implementation that makes email notifications optional for scenarios based on their source (user-created vs radar-generated).

Problem Statement

Previously, ALL completed scenarios would trigger email notifications to users. This was problematic for radar-generated scenarios, which are automated background processes that shouldn’t spam users with emails.

Solution Architecture

Flow Diagram

Changes Made

1. Frontend - Chat Tools (app/api/chat/tools.ts)

Change: Added source parameter to createScenario tool
Backward Compatibility: Defaults to 'user' if not specified

2. Radar Feed Directive (app/api/radar/silvia-simulation/route.ts)

Change: Updated system directive to instruct LLM to pass source

3. Lambda API Handler (aws/scenarios/lambdas/api/handler.py)

Changes:
  1. Accept source parameter from request body
  2. Store in DynamoDB consultation item
  3. Pass through SQS message
Backward Compatibility: Defaults to 'user' if not provided

4. Lambda Agent Processor (aws/scenarios/lambdas/agent_processor/handler.py)

Change: Conditionally send emails based on source
Backward Compatibility: Defaults to 'user' (sends email) if not specified

Testing Checklist

Manual Testing

  • Create user scenario from UI → Should receive email
  • Create user scenario from chat → Should receive email
  • Radar generates scenario → Should NOT receive email
  • Check DynamoDB to verify source field is stored
  • Check CloudWatch logs for email skip message

Edge Cases

  • Scenario created before this change (no source field) → Should receive email (backward compatible)
  • Scenario with invalid source value → Should receive email (defaults to ‘user’)
  • Multiple radar scenarios generated → Should not receive multiple emails

Deployment Notes

Prerequisites

  • No database migrations needed (DynamoDB is schemaless)
  • No infrastructure changes needed
  • Fully backward compatible

Deployment Order

  1. Deploy Lambda functions (API handler + Agent processor)
  2. Deploy Next.js application (frontend changes)
  3. No downtime required

Rollback Plan

If issues occur:
  1. Revert Lambda deployments
  2. Revert Next.js deployment
  3. All scenarios will default to sending emails (safe fallback)

Monitoring

Key Metrics

  • Email send rate (should decrease after deployment)
  • Radar scenario completion rate
  • User scenario completion rate
  • Email API success rate

CloudWatch Logs

Search for:
  • "Skipping email notification for radar-generated scenario" - Radar scenarios
  • "Sending email notification for consultation" - User scenarios

Benefits

  1. Better UX: Users no longer receive spam emails from automated radar scenarios
  2. Cost Savings: Fewer emails sent = lower email service costs
  3. Clean Separation: Clear distinction between user-initiated and automated scenarios
  4. Extensible: Easy to add more source types in the future (e.g., ‘scheduled’, ‘webhook’)
  5. Backward Compatible: Existing scenarios and workflows unchanged

Future Enhancements

Potential improvements:
  • Add email preferences per source type in user settings
  • Track source in analytics/metrics
  • Add source filter in scenarios UI
  • Support batch email digest for radar scenarios