Email Async

[isabellalam12]

• create email async plans
• implement asynchronous email backend and UI
• swap to database-backed templates.

[isabellalam12]

• Remove TemplateSelector file #71
• Email Async  #67 👈 (View in Graphite)
• main

This stack of pull requests is managed by Graphite. Learn more about stacking.

[spiffyy99]

how big are these batches? are we planning on sending them all in one for a given month?

[spiffyy99]

This is a very interesting and technically cool approach, but i can't help but feel we might benefit from testing sending out some actual emails due to the complexity and how many parts can go wrong. That can probably be either a manual test run (especially at first) or through integration testing with a fake in-memory SMTP server such as https://github.com/gessnerfl/fake-smtp-server

The main thing i'm concerned about is not only the emails actually being sent out, but the retry logic. we'd want to verify that users don't get spammed with multiple emails unnecessariliy.

This can definitely be relegated to a future task though, no need for this PR.

[graphite-app]

The softDelete() method performs a hard DELETE instead of a soft delete. This contradicts the method name, the Javadoc in EmailTemplateRepo, and the design intent documented in TemplateManagementService (which states templates should be preserved for audit history). Additionally, the migration file lacks a deleted_at column needed for soft deletion.

Impact: This will permanently delete templates that are referenced by past emails, breaking audit trails and making it impossible to reconstruct what was sent. The delete protection logic in TemplateManagementService.deleteTemplate() prevents deletion of currently-referenced templates, but this protection doesn't help templates that were used in the past for already-sent emails.

Fix: Add a deleted_at TIMESTAMPTZ column to the email_templates table migration, and change the implementation to:

public int softDelete(final UUID id) {
    return jdbc.sql("UPDATE email_templates SET deleted_at = NOW() WHERE id = :id AND deleted_at IS NULL")
            .param("id", id)
            .update();
}

Also update findAll() to exclude soft-deleted rows:

public List<EmailTemplate> findAll() {
    return jdbc.sql("SELECT * FROM email_templates WHERE deleted_at IS NULL ORDER BY name")
            .query((rs, rowNum) -> parseResultSet(rs))
            .list();
}

Spotted by Graphite



Is this helpful? React 👍 or 👎 to let us know.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[graphite-app]

Migration file name mismatch with actual implementation

Documentation references V0004__Create_email_tables.sql but the actual migration file is V0005__Create_email_tables.sql. This will cause confusion during implementation and code reviews. The version number must match between docs and implementation for Flyway to work correctly.

Fix: Update reference to match actual file:

## 1a. Data model — `db/migration/V0005__Create_email_tables.sql`

Suggested change

	## 1a. Data model — `db/migration/V0004__Create_email_tables.sql`
	## 1a. Data model — `db/migration/V0005__Create_email_tables.sql`

Spotted by Graphite



Is this helpful? React 👍 or 👎 to let us know.