Skip to content

fix: tolerate stale trigger_type values in settings response#261

Merged
LeonardoVieira1630 merged 1 commit into
fix/offchain-notifications-sdk-1.2.0from
fix/settings-tolerate-stale-trigger-types
May 27, 2026
Merged

fix: tolerate stale trigger_type values in settings response#261
LeonardoVieira1630 merged 1 commit into
fix/offchain-notifications-sdk-1.2.0from
fix/settings-tolerate-stale-trigger-types

Conversation

@LeonardoVieira1630

Copy link
Copy Markdown
Member

Summary

SettingsService.getUserPreferences now drops user_notification_preferences rows whose trigger_type isn't in the current NotificationTypeId enum. Legacy or hand-inserted DB values can no longer break the API response.

Why this matters

The GET /users/by-channel/:channel/:channelUserId/notification-preferences response is validated by Fastify against z.nativeEnum(NotificationTypeId) (apps/subscription-server/src/schemas/settings.schema.ts). The DB column user_notification_preferences.trigger_type is just string(100) — there is no enum constraint at the DB level — so any single row with a value outside the current enum makes the whole response fail with FST_ERR_RESPONSE_SERIALIZATION → 500.

This happened in prod because the enum was renamed in 870b35a (offchain-voting-reminder-75offchain-voting-reminder-50). Anyone who saved preferences before the rename still has the old value in the DB, and any GET for that user blows up with a 500. Downstream effect:

  • Telegram users see error loading notification settingssubscription-server returns 500 with ResponseSerializationError.
  • Slack users hit the same broken endpoint when opening settings/DAOs.

The write side is untouched and stays strict (z.nativeEnum in the body schema), so we never persist garbage. We only relax the read path, which already had to deal with whatever the DB contained. The consumers (base-settings.service.ts) were already defensively ignoring unknown trigger types on their side, so the filter at the service boundary is consistent with how the data is consumed.

This is also resilient to future renames or manual inserts — no migration needed, no constraint to add, no risk of a single bad row breaking the UI for a user.

Test plan

  • pnpm vitest run in apps/subscription-server — 30/30 passing, includes new case drops rows whose trigger_type is no longer in the current enum
  • pnpm tsc --noEmit in apps/subscription-server — clean
  • Deploy to prod and confirm /anticapture → settings / list DAOs works for users with legacy offchain-voting-reminder-75 rows

🤖 Generated with Claude Code

SettingsService.getUserPreferences now filters out preference rows whose
trigger_type is not in the current NotificationTypeId enum, so legacy or
manually inserted values in user_notification_preferences cannot break the
GET /users/by-channel/:channel/:channelUserId/notification-preferences
response.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
@vercel

vercel Bot commented May 27, 2026

Copy link
Copy Markdown

The latest updates on your projects. Learn more about Vercel for GitHub.

Project Deployment Actions Updated (UTC)
flow-editor Ready Ready Preview, Comment May 27, 2026 4:56pm
notification-system-dashboard Ready Ready Preview, Comment May 27, 2026 4:56pm

Request Review

@LeonardoVieira1630 LeonardoVieira1630 merged commit f86eb2a into fix/offchain-notifications-sdk-1.2.0 May 27, 2026
7 checks passed
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.

2 participants