Wrong value for X-Pagination-Total when limit passed to API is lower than total results #344

Closed
opened 2026-02-15 18:16:03 -05:00 by yindo · 1 comment
Owner

Originally created by @afmoleirinho96 on GitHub (Aug 21, 2025).

Checked other resources

  • I added a very descriptive title to this issue.
  • I searched the LangGraph.js documentation with the integrated search.
  • I used the GitHub search to find a similar question and didn't find it.
  • I am sure that this is a bug in LangGraph.js rather than my code.
  • The bug is not resolved by updating to the latest stable version of LangGraph (or the specific integration package).

Example Code

E.g - client.threads.search() when total results is 83 (83 threads) and size per page (limit is 50)

client.threads.search({
        limit: 50
});

Error Message and Stack Trace (if applicable)

No response

Description

When making API requests with pagination:

  • If the page size (limit) is greater than or equal to the total number of items, the response headers are correct (e.g. X-Pagination-Total: 83).
  • If the page size is smaller than the total number of items, the API incorrectly reports the page size as the total.

Example:

  • Request with limit= 50 when the true total is 83 returns headers:
  • X-Pagination-Total: 50
  • X-Pagination-Next: 51
  • Request with limit= 60 → X-Pagination-Total: 60 (instead of 83).

Expected behavior:
X-Pagination-Total should always reflect the true total count of items (83 in this case), independent of the page size requested.

Actual Behavior:
When limit < total, X-Pagination-Total incorrectly equals the limit.

PS: I’m 99% sure that the expected behavior was the previous one, but it started malfunctioning.

💡 Future thoughts and ideas 💡
Search results should come paginated, with total results, page size, page number - an actual pagination implementation, instead of relying on a response header.

System Info

Environment: Developing on top of Open Agent Platform
Node version: 20.17.0
Npm version: 10.8.2

Packages:
@langchain/langgraph-sdk: ^0.0.109
@langchain/core: ^0.3.72

Originally created by @afmoleirinho96 on GitHub (Aug 21, 2025). ### Checked other resources - [x] I added a very descriptive title to this issue. - [x] I searched the LangGraph.js documentation with the integrated search. - [x] I used the GitHub search to find a similar question and didn't find it. - [x] I am sure that this is a bug in LangGraph.js rather than my code. - [x] The bug is not resolved by updating to the latest stable version of LangGraph (or the specific integration package). ### Example Code E.g - client.threads.search() when total results is 83 (83 threads) and size per page (limit is 50) ```ts client.threads.search({ limit: 50 }); ``` ### Error Message and Stack Trace (if applicable) _No response_ ### Description When making API requests with pagination: - If the page size (limit) is greater than or equal to the total number of items, the response headers are correct (e.g. X-Pagination-Total: 83). - If the page size is smaller than the total number of items, the API incorrectly reports the page size as the total. **Example**: - Request with limit= **50** when the true total is 83 returns headers: - X-Pagination-Total: **50** - X-Pagination-Next: **51** - Request with limit= **60** → X-Pagination-Total: 60 (instead of 83). Expected behavior: `X-Pagination-Total` should always reflect the true total count of items (83 in this case), independent of the page size requested. Actual Behavior: When limit < total, X-Pagination-Total incorrectly equals the limit. PS: I’m 99% sure that the expected behavior was the previous one, but it started malfunctioning. 💡 Future thoughts and ideas 💡 Search results should come paginated, with total results, page size, page number - an actual pagination implementation, instead of relying on a response header. ### System Info Environment: Developing on top of Open Agent Platform Node version: 20.17.0 Npm version: 10.8.2 Packages: @langchain/langgraph-sdk: ^0.0.109 @langchain/core: ^0.3.72
yindo closed this issue 2026-02-15 18:16:03 -05:00
Author
Owner

@hinthornw commented on GitHub (Aug 22, 2025):

Hello! This is by design, since you probably don't want to be scanning the entire set of matching tuples just to get a count. I understand the naming is confusing (it was changed later to improve performance).

The server returns limit + 1 to indicate there are more pages to fetch.

If you want to get the total count, you can use the /count routes (https://langchain-ai.github.io/langgraph/cloud/reference/sdk/python_sdk_ref/#langgraph_sdk.client.ThreadsClient.count)

@hinthornw commented on GitHub (Aug 22, 2025): Hello! This is by design, since you probably don't want to be scanning the entire set of matching tuples just to get a count. I understand the naming is confusing (it was changed later to improve performance). The server returns limit + 1 to indicate there are more pages to fetch. If you want to get the total count, you can use the /count routes (https://langchain-ai.github.io/langgraph/cloud/reference/sdk/python_sdk_ref/#langgraph_sdk.client.ThreadsClient.count)
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: langchain-ai/langgraphjs#344