fix(notify): immediate Discord notifications silently lost on int snowflake target

[mruwnik]

Problem

meta_notify_user returned {"success": true, "channel_type": "discord"} but no Discord DM ever arrived — every immediate Discord notification since ~2026-05-30 was silently dropped. The worker crashed on all 3 celery attempts with:

AttributeError: 'int' object has no attribute 'isdigit'
  scheduled_tasks.py send_via_discord → discord_data.py discord_channel_for_target → target.isdigit()

Root cause — int/str mismatch across the celery boundary

1. User.serialize() keys discord_accounts by the int snowflake (account.id).
2. notify_user picks that int and passes it as the celery task target; JSON serialization preserves it as int.
3. The worker classifies channel-vs-DM via target.isdigit(), which assumes str → AttributeError, task fails, message lost (no retry, no dead-letter, no DB record).

Why only the immediate path broke: scheduled notifications round-trip through ScheduledTask.notification_target (a String column), so the int is coerced to str by the DB. The immediate path (added 2026-05-29) skips the DB; the .isdigit() classification landed 2026-05-30. Each commit was fine alone — together they broke every immediate Discord send. Slack/email use string identifiers throughout and were unaffected.

Fix (layered)

• Source — get_notification_channel coerces the Discord id to str (slack/email were already str).
• Classification — discord_channel_for_target / discord_target_is_channel accept str | int and normalize; the one canonical place that classifies a snowflake.
• Dispatch — send_via_discord str()s the target before send_dm/send_to_channel (the collector API wants str).

Related fix — get_user public contract

User.serialize() and the _get_current_user Person fallback emitted discord_accounts keyed by int. JSON object keys are always strings, so in-process callers saw {123456789: …} while MCP clients over the wire saw {"123456789": …}. Both now coerce to str, so the shapes match.

Honesty fix — success → queued

The immediate-send return now reports {"queued": true, "scheduled": false, …} instead of success: a fire-and-forget enqueue is not a delivery confirmation and shouldn't imply one. There is no row/metric to read back. Scheduled sends keep success (a notification row is durably committed). Clients should branch on the shared scheduled key.

Tests

• int-target classification (discord_target_is_channel) and dispatch (send_via_discord) no longer crash and route correctly
• int → str channel coercion in get_notification_channel
• str-keyed User.serialize() and the get_user Person fallback
• the queued immediate-send return shape ("success" not in result)

All passing; verified across test_meta, test_meta_notify, test_users, test_notification_targets, test_scheduled_tasks, test_teams (no regressions).

🤖 Generated with Claude Code