You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[HIGH] — Admin "suspend campaign" flow writes an AuditLog and resolves successfully, but never actually notifies the creator #6
Severity: High Type: Bug Scope: Admin, Notifications Labels:bug, security, Official Campaign
Description
AdminService.suspendCampaign (src/admin/admin.service.ts, lines ~17–58) writes the campaign status change to the database and inserts an AuditLog entry, then calls this.notificationsService.sendCampaignSuspensionEmail(...). The implementation of sendCampaignSuspensionEmail (src/notifications/notifications.service.ts, lines ~159–173) has a TODO: replace with real mailer call marker and currently only emits a logger line — no email is queued, no in-app notification is created, and the recipient field is a synthetic creator-${creatorId}@platform.internal that cannot receive mail.
Result: an admin can confidently suspend a campaign, see the API return 200, and the creator receives nothing — meaning a campaign can be frozen with the creator unaware, blocking support requests and refunds.
Recommendation
Replace the stub with a real email template + Bull enqueue: render suspend-campaign-email.ts, push to QUEUE_EMAIL, and also create a Notification row for in-app delivery.
Add an integration test (AdminService.suspendCampaign + an injected mock NotificationsService) that asserts sendCampaignSuspensionEmail is invoked and the payload contains the real user.email (resolved through prisma.user.findUnique).
Surface the suspension asynchronously: have the controller return 202 if notification enqueuing fails so admins see the partial failure instead of a silent success.
Hi maintainer, I'd like to work on this issue. My approach is to replace the current notification stub with a production-ready notification flow by resolving the creator's actual email, rendering the suspension email template, enqueueing it through the email queue, and creating an in-app notification. I'll add integration tests to verify the correct recipient and notification payload, and ensure notification failures are surfaced back to the admin (e.g. via a 202 response) instead of appearing as a silent success.
Activity
Just-Bamford commentedon Jun 20, 2026
Hi maintainer, I'd like to work on this issue. My approach is to replace the current notification stub with a production-ready notification flow by resolving the creator's actual email, rendering the suspension email template, enqueueing it through the email queue, and creating an in-app notification. I'll add integration tests to verify the correct recipient and notification payload, and ensure notification failures are surfaced back to the admin (e.g. via a 202 response) instead of appearing as a silent success.
grantfox-oss commentedon Jun 20, 2026
🦊 GrantFox — @Just-Bamford has been assigned to this issue as part of the Official Campaign campaign!
Next steps:
Closes #6)Good luck! Track your progress on GrantFox.
grantfox-oss commentedon Jun 22, 2026
🎉 This issue has been marked as completed on GrantFox as part of the Official Campaign campaign!
@Just-Bamford's PR #35 was approved and merged by @Alqku.
🏆 @Just-Bamford: You earned 35 FoxPoints for this contribution! Your current tier: Explorer (468 total points). Track your full progress on GrantFox.
👏 Great work, @Just-Bamford! Keep contributing to OrbitChainLabs.