Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

referenced_message appears inconsistently for type 6 (CHANNEL_PINNED_MESSAGE) system messages #2255

Closed
LikeLakers2 opened this issue Nov 18, 2020 · 1 comment
Labels

Comments

@LikeLakers2
Copy link
Contributor

LikeLakers2 commented Nov 18, 2020

Description
Hi there. It was noted over in #2252 and in #2053 that message_reference would appear for messages of types 6 (CHANNEL_PINNED_MESSAGE) and 12 (CHANNEL_FOLLOW_ADD). I had also noted that type 6 messages would include a referenced_message field, with the data of the message being pinned (except when the message had been deleted).

Talking with @advaith1 right after my PR was submitted, we found an additional quirk with type 6 messages: They will only have a referenced_message field if the message being referenced is also being returned.

To elaborate: If you are pulling down a channel's message history, and one of the message is a message of type 6 (CHANNEL_PINNED_MESSAGE), it will only include a referenced_message field if the message being referenced is also being returned as part of the history that you requested. If it is not part of the history being returned, the API will not bother to fetch the message. This also means that if the system message is being returned through the Get Channel Message endpoint, the system message will not include a referenced_message field. Examples of this weirdness can be found here, under the files marked 1 and 2 in the TOC.

This is in stark contrast to reply-type messages (type 19), as they will always include the referenced_message field, even if the message would not otherwise be returned, and even if it is from several years back. You can see this in the files marked 3, 4, and 5 in the gist linked above.

This is an oddity as the referenced_message field only appears for type 6 messages in the exact situations where you wouldn't need it -- but in other situations, it requires a separate Get Channel Message request in order to see what the pinned message was.

Steps to Reproduce

  1. Pin a message.
  2. Use the Get Channel Message endpoint to grab the resulting CHANNEL_PINNED_MESSAGE system message. It will not have a referenced_message field.
  3. Use the Get Channel History endpoint to grab the resulting CHANNEL_PINNED_MESSAGE system message, but not the message that was pinned. It will not have a referenced_message field.
  4. Do the same as in 3, but additionally get the message that was pinned. It will have a referenced_message field.

Expected Behavior
I would expect type 6 messages to include a referenced_message field at all times (except when the message is deleted).

Current Behavior
Type 6 messages will only include a referenced_message field if the message being referenced was also loaded and returned separately -- the exact situation where you wouldn't need the referenced_message field.

Screenshots/Videos
https://gist.github.com/LikeLakers2/a10f6f7883947576eb734b6efa570b02

Client and System Information
N/A, though the above info was found using v8 of the REST API.

@night
Copy link
Member

night commented Apr 9, 2021

referenced_message is only intended for replies. This will be fixed in the next API deploy.

@night night closed this as completed Apr 9, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants