Chat API: page_size parameter is ignored when direction=past

Bug
,
1

I’m reporting a bug with the Discourse Chat plugin’s API. When querying for past chat messages, the page_size parameter is ignored, and the endpoint always returns the maximum number of messages.

Steps to Reproduce:

  1. Make an API call to the chat messages endpoint (e.g., /chat/{channel_id}/messages.json).

  2. Use the following parameters in the request:

    • target_message_id: [ID of a recent message]

    • direction: past

    • page_size: 5 (or any number less than 50)

Expected Behavior: The API should return a JSON object containing a maximum of 5 messages that were sent before the specified target_message_id.

Actual Behavior: The API returns 50 messages, ignoring the page_size=5 parameter. It appears to be hardcoded to the maximum page size in this scenario.

Thanks for looking into this!

2 Likes
2

Reading through the implementation this appears somewhat deliberate:

Perhaps @loic has some thoughts here.

2 Likes
3

I spent some time trying to replicate it, but I wasn’t able to do so.

I checked Chat::MessagesQuery, Chat::ListChannelMessages and the controller action through our specs and manually on a local instance too. The page_size parameter is taken into account as expected, as well as the direction parameter.

@Nima1 are you sure to use the proper endpoint? It should have api in it, like so: /chat/api/channels/3/messages?target_message_id=40&direction=past&page_size=5.

Another thing I haven’t checked is if it behaves differently on stable. Is your instance up-to-date with the tests-passed branch?

2 Likes
4

Thanks for looking into this.

My apologies, I forgot to mention a crucial detail: this issue only occurs in channels with threading enabled. That’s likely why you couldn’t replicate it.

The page_size parameter is ignored when I fetch messages from a specific thread. For example, when I use this endpoint with page_size=5:

/chat/api/channels/64/threads/1526/messages?target_message_id=19205&page_size=5

The API returns the default 50 messages instead of the requested 5, even though plenty of messages are available in the thread. It seems the problem is specific to the threads API endpoint.

2 Likes
5

Found the bug! I was already refactoring that service a bit, so I included the fix in it:

4 Likes
6

This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.