Fix silent failures in %aceptar/%rechazar and make Aprobar/Rechazar buttons survive. - #15
Merged
Merged
Conversation
…uttons survive restarts Two independent bugs, both matching a report of clicking "Aprobar" on an %envio-eventos submission with no visible effect and nothing in bot.log: 1. _aceptar_mensaje/_rechazar_mensaje logged the action and dropped the row from bot.data_mod *before* actually sending to the destination channel. Any failure in that send (over the 2000-char limit, missing permissions, a transient network error, an author no longer resolvable via bot.get_user - previously unguarded, unlike get_mod_pending) silently lost the post: the audit log already said "aceptado"/"rechazado" and the item was already gone from the pending queue, with no visible error anywhere (the only trace was an exception logged by discord.py's default View.on_error, easy to miss since nothing in this module calls logger.* on this path). Now the destination send is attempted first, wrapped in try/except; only a successful send logs the action and removes the row, and a failure posts a visible error to the mod channel instead. 2. ApproveRejectView used timeout=None, which only stops a button from visually expiring - it does NOT make it survive a bot restart, since the view instance (holding author/message_id in its constructor closure) is gone once the process restarts, with nothing left to route the click to. Replaced with discord.ui.DynamicItem-based Aprobar/Rechazar buttons whose custom_id encodes the message_id and which resolve the cog via interaction.client.get_cog(...) and the author via bot.data_mod at click time - reconstructed fresh via from_custom_id() regardless of how long ago the message was sent. Registered once via bot.add_dynamic_items() in bot.py. Also: bot.py's logging previously only wrote to bot.log (a single FileHandler), so running the bot attached to a terminal/screen session showed nothing there - added a StreamHandler alongside it. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
cmaureir
changed the title
cmaureir
added a commit
that referenced
this pull request
Aug 19, 2026
…uttons survive restarts (#15) Two independent bugs, both matching a report of clicking "Aprobar" on an %envio-eventos submission with no visible effect and nothing in bot.log: 1. _aceptar_mensaje/_rechazar_mensaje logged the action and dropped the row from bot.data_mod *before* actually sending to the destination channel. Any failure in that send (over the 2000-char limit, missing permissions, a transient network error, an author no longer resolvable via bot.get_user - previously unguarded, unlike get_mod_pending) silently lost the post: the audit log already said "aceptado"/"rechazado" and the item was already gone from the pending queue, with no visible error anywhere (the only trace was an exception logged by discord.py's default View.on_error, easy to miss since nothing in this module calls logger.* on this path). Now the destination send is attempted first, wrapped in try/except; only a successful send logs the action and removes the row, and a failure posts a visible error to the mod channel instead. 2. ApproveRejectView used timeout=None, which only stops a button from visually expiring - it does NOT make it survive a bot restart, since the view instance (holding author/message_id in its constructor closure) is gone once the process restarts, with nothing left to route the click to. Replaced with discord.ui.DynamicItem-based Aprobar/Rechazar buttons whose custom_id encodes the message_id and which resolve the cog via interaction.client.get_cog(...) and the author via bot.data_mod at click time - reconstructed fresh via from_custom_id() regardless of how long ago the message was sent. Registered once via bot.add_dynamic_items() in bot.py. Also: bot.py's logging previously only wrote to bot.log (a single FileHandler), so running the bot attached to a terminal/screen session showed nothing there - added a StreamHandler alongside it.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Two independent bugs, both matching a report of clicking "Aprobar" on an %envio-eventos submission with no visible effect and nothing in bot.log:
_aceptar_mensaje/_rechazar_mensaje logged the action and dropped the row from bot.data_mod before actually sending to the destination channel. Any failure in that send (over the 2000-char limit, missing permissions, a transient network error, an author no longer resolvable via bot.get_user - previously unguarded, unlike get_mod_pending) silently lost the post: the audit log already said "aceptado"/"rechazado" and the item was already gone from the pending queue, with no visible error anywhere (the only trace was an exception logged by discord.py's default View.on_error, easy to miss since nothing in this module calls logger.* on this path). Now the destination send is attempted first, wrapped in try/except; only a successful send logs the action and removes the row, and a failure posts a visible error to the mod channel instead.
ApproveRejectView used timeout=None, which only stops a button from visually expiring - it does NOT make it survive a bot restart, since the view instance (holding author/message_id in its constructor closure) is gone once the process restarts, with nothing left to route the click to. Replaced with discord.ui.DynamicItem-based Aprobar/Rechazar buttons whose custom_id encodes the message_id and which resolve the cog via interaction.client.get_cog(...) and the author via bot.data_mod at click time - reconstructed fresh via from_custom_id() regardless of how long ago the message was sent. Registered once via bot.add_dynamic_items() in bot.py.
Also: bot.py's logging previously only wrote to bot.log (a single FileHandler), so running the bot attached to a terminal/screen session showed nothing there - added a StreamHandler alongside it.