Add email-bounce suppression and complaint-handling tests for src/services/notifications/bounceStore.ts

[1nonlypiece]

📌 Description

src/services/notifications/bounceStore.ts and the email provider handle bounces
and retries, but there is no test asserting the suppression contract: that an
address with a hard bounce is suppressed from further sends, that a soft bounce
is retried up to a cap then suppressed, and that a complaint immediately
suppresses. Without this, the system could keep mailing a poisoned address and
harm deliverability.

Goal: prove the bounce/complaint suppression rules so future sends to a
suppressed address are blocked.

🎯 Requirements and Context

• A hard bounce records suppression; a subsequent send to that address is skipped
  with a typed reason.
• A soft bounce retries up to the configured cap, then suppresses.
• A spam complaint suppresses immediately regardless of bounce history.
• Suppression is queryable so the notification pipeline can short-circuit.

🛠️ Suggested Execution

1. Create a branch

git checkout -b test/email-bounce-suppression

2. Implement changes

• Add src/tests/notifications.bounceStore.test.ts driving bounce/complaint
  events through the store and provider.

3. Test and commit

• Run bun test src/tests/notifications.bounceStore.test.ts.
• Edge cases: hard bounce, soft-bounce cap, complaint, send short-circuit.

Example commit message

test: email bounce and complaint suppression contract tests

✅ Guidelines

• Minimum 95% coverage of the bounce-store paths.
• Document the suppression state machine.
• Timeframe: 96 hours.

🏷️ Labels

type-testing · area-backend · MAYBE REWARDED · GRANTFOX OSS · OFFICIAL CAMPAIGN

💬 Community & Support

• Join the Disciplr contributor Discord: https://discord.gg/xvNAvMJf
• Introduce yourself before starting to avoid duplicate work.

[YfengJ]

Hi maintainers, I would like to take this issue if it is available.

Planned approach:

• add src/tests/notifications.bounceStore.test.ts covering hard-bounce suppression, soft-bounce retry cap then suppression, immediate complaint suppression, and send short-circuit behavior for suppressed addresses
• drive the tests through the existing bounce store/provider boundary so the notification pipeline contract is documented without changing unrelated mail flow
• keep this test-focused; only adjust bounce-store behavior if the new contract tests expose a real gap
• run bun test src/tests/notifications.bounceStore.test.ts and nearby notification tests before opening a PR

Could you please assign this to me if that plan matches the expected scope?

[Killerjunior]

@Killerjunior has applied to work on this issue as part of the Stellar Wave Program's 6th wave.

Hi maintainer, I have read and understood the issue requirements and checked the necessary documentation. I’m confident I can work on this task effectively and deliver a proper solution.

ℹ️ Repo Maintainers: To accept this application, review their application or assign @Killerjunior to this issue.

[aabxtract]

@aabxtract has applied to work on this issue as part of the Stellar Wave Program's 6th wave.

I would love to work on this, I’m a skilled full stack developer and I deliver ASAP

ℹ️ Repo Maintainers: To accept this application, review their application or assign @aabxtract to this issue.

[grantfox-oss]

🦊 GrantFox — @aabxtract has been assigned to this issue as part of the Official Campaign campaign!

Next steps:

1. Open a Pull Request referencing this issue (e.g., Closes #678)
2. Your PR will be reviewed by the Disciplr-Org maintainers

Good luck! Track your progress on GrantFox.

[drips-wave]

Congratulations, @aabxtract! 🎉 Your application was accepted by the repo's maintainers, and the issue is due on June 30, 2026.

🧑‍💻 @aabxtract: Please resolve the issue such that the repo's maintainers have enough time to review your contribution before the due date. You'll earn Points for completing the issue on-time, which will make you eligible for a share of the Stellar Wave Program's reward pool.

Warning

When opening a PR, please link it to this issue to ensure it gets tracked accurately. Points are awarded when this issue is marked as completed by the maintainer.

🤠 Repo maintainers: Please keep an eye on the contributor's progress and review their work before the due date. You can manage this issue, including adjusting its complexity and points, here.

🌊 Happy Wave 🌊