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
Following up on the comments inside of #8212, both error codes currently return a generic HTTP 403 with the same user-facing message. However, based on testing, these codes represent distinct scenarios that should be handled (or rather explained) separately to improve debugging and developer feedback.
Code
Reason
50007
User has blocked the application
50278
Cannot send messages to this user
Instead of mapping both codes to the identical "Access Denied" reason, the API should instead provide more granular feedback, rather than forcing developers to manually cross-reference the two different error codes to figure out what went wrong.
Steps to Reproduce
Note
Both steps assumes you are doing POST /channels/{:channel_id}/messages, and the channel_id being the one given from POST /users/@me/channels {"recipient_id": "user_id"}
Attempt to send a DM to a user who has blocked the application
Be given the HTTP 403 code alongside error code 50007
Attempt to send a DM once more to a user who has server DMs disabled or/and not in any mutual servers, but the bot unblocked
Be given the HTTP 403 code alongside error code 50278
Both of these methods grant the same text of reasoning
Expected Behavior
The API response message should tell the difference between the two scenarios. For example, explicitly stating "User has blocked the application" for 50007 and "Cannot send messages to this user" for 50278.
Current Behavior
Both error codes return the exact same generic text message which is Cannot send messages to this user. We must manually handle the codes (50007 and 50278) to figure out what actually happened, rather than relying on an accurate, descriptive reason from the API response itself.
Screenshots/Videos
No response
Client and System Information
python v3.14.0-final
discord.http v3.1.2
aiohttp v3.13.3
system_info Windows 11 (10.0.26200)
Description
Following up on the comments inside of #8212, both error codes currently return a generic
HTTP 403with the same user-facing message. However, based on testing, these codes represent distinct scenarios that should be handled (or rather explained) separately to improve debugging and developer feedback.Instead of mapping both codes to the identical "Access Denied" reason, the API should instead provide more granular feedback, rather than forcing developers to manually cross-reference the two different error codes to figure out what went wrong.
Steps to Reproduce
Note
Both steps assumes you are doing
POST /channels/{:channel_id}/messages, and thechannel_idbeing the one given fromPOST /users/@me/channels {"recipient_id": "user_id"}HTTP 403code alongside error code50007HTTP 403code alongside error code50278Both of these methods grant the same text of reasoning
Expected Behavior
The API response message should tell the difference between the two scenarios. For example, explicitly stating "User has blocked the application" for
50007and "Cannot send messages to this user" for50278.Current Behavior
Both error codes return the exact same generic text message which is
Cannot send messages to this user. We must manually handle the codes (50007 and 50278) to figure out what actually happened, rather than relying on an accurate, descriptive reason from the API response itself.Screenshots/Videos
No response
Client and System Information