🐛 Fail unmatched callback queries as faults instead of soothing them

Juanpe Araquerequested to merge
unbound-callback-fault into main

What does this MR do and why?

The catch-all callback fallback still answered any callback query no registered handler matched with a hardcoded English "This feature will be available soon! Stay tuned! 😄🚀" and closed the invocation as a success. That message dates from early development, when unfinished features legitimately had dead buttons. Today every shipped button is bound to a handler (prod shows zero unmatched callbacks in the last 14 days), so reaching the fallback means one of two things — we shipped a button with no handler, or a client forged the callback data — and both are faults, not features to wait for.

The fallback now raises a new UnboundCallbackError carrying the callback data (bounded to 64 bytes by the Bot API — the message is the only evidence of which button, or which forged payload, produced the fault). Because the fallback already runs through callback_with_metrics, raising buys the whole standard fault path for free: the correlated error line, one Fault=1 sample with error_type=mitup_bot.exceptions.UnboundCallbackError, and the user redirected to the main menu with the translated unexpected-error notice instead of the untranslated stay-tuned copy.

Screenshots or screen recordings

Not applicable — the user-visible change is that an unmatched button now shows the standard "something went wrong" redirect instead of the English-only stay-tuned alert.

How to set up and validate locally

  1. Run uv run mb test tests/bot/handlers/test_registry.py
  2. The reworked tests pin: the fallback raises with the data in the message and speaks to Telegram not at all; driven through the wrapper, the invocation emits exactly one Fault=1 naming the class, writes the correlated error line, and sends the generic redirect.

MR acceptance checklist

This checklist encourages the authors, reviewers, and maintainers of merge requests (MRs) to confirm changes were analyzed for high-impact risks to quality, performance, reliability, security, observability, and maintainability.

  • Any new or modified functionality is covered by tests. If not, tests have been added to ensure its coverage.
  • This modification has been tested in a local environment and proof has been presented and evaluated.
  • The documentation has been updated accordingly
  • The code in the MR has been validated (run uv run mb validate)
  • If new strings have been added to messages, the source language has been updated (run uv run mb locales update-source)

Merge request reports