langchain-ai/langgraphjs
1
0
Fork 0
mirror of https://github.com/langchain-ai/langgraphjs.git synced 2026-07-22 17:15:25 -04:00
Code Issues 108 Packages Projects Releases 20 Wiki Activity

[Typescript SDK] Pagination issues and possible implementation for total results support to .search methods #348

New Issue
Closed
opened 2026-02-15 18:16:05 -05:00 by yindo · 1 comment
yindo commented 2026-02-15 18:16:05 -05:00
Owner
Copy Link
Copy Source

Originally created by @afmoleirinho96 on GitHub (Aug 22, 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

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

Error Message and Stack Trace (if applicable)

No response

Description

Follow up on unsolved https://github.com/langchain-ai/langgraphjs/issues/1556, given that it was wrongly marked as 'solved' and I cannot re-open a ticket.

Disclaimer: I'm using https://www.npmjs.com/package/@langchain/langgraph-sdk (Typescript) not Python one, like previous response from @hinthornw suggested. I would kindly ask to not close the ticket before a solution is accepted both ways/discussion ends.

Two concrete issues here on the response provided https://github.com/langchain-ai/langgraphjs/issues/1556#issuecomment-3215912602 :

  1. SDK mismatch (Python vs TypeScript)
  • The example points to the Python SDK’s .count, but the TypeScript SDK doesn’t expose .count.
  • That leaves TS clients with no single-call way to render real pagination controls (page count / total results).
  1. Double round-trip is expensive
  • For every .search I now need to make a second .count call to show totals.
  • This adds latency, cost, and complexity on every list view and search UX, especially in UIs that paginate or show “83 results”.

What would fix this (any of the below would work):

  1. Best DX: Add an opt-in flag to .search (e.g., includeTotal: true or count: "exact") and return structure:
// **1
type SearchResult<T> = {
  data: T[];
  pageSize: number;
  nextCursor?: string;
  total?: number; // present when includeTotal is true
};

This option also prevents breaking changes for other versions/developers that just get the data from .search and are not expecting to receive now an object instead of array with the search results.

  1. Other possible Best DX - implement proper pagination with model mentioned above **1.
    However this wouild have breaking changes, given that instead of results as array, it would be now an object.

  2. If you don’t want to change .search’s response body: Keep the existing payload, but add a reliable header that returns the actual total when requested:

  • Keep your “has more” signal as-is (limit+1).
  • Add back a header for the true total (e.g X-Pagination-Total-Results or X-Paginational-Count).

Otherwise, there's no way to know full results in Typescript SDK other than putting an absurd limit (preventing pagination from working).

TL;DR

There’s currently no way (aside from capping .search with a Math.max(limit)) to know the true total count of results for endpoints like threads, assistants, etc.

Adding a .count method to the TypeScript SDK would still force an extra API call after every .search.

The total should be available directly from the .search response—either:
• via a reliable response header (as it worked before), or
• included in the .search result payload itself.

This avoids unnecessary double requests and keeps pagination ergonomics consistent across SDKs.

TL DR:
There’s currently no way (aside from capping .search with a Math.max(limit)) to know the true total count of results for endpoints like threads, assistants, etc.
Adding a .count method (like it is done in Python SDK) to the TypeScript SDK would still force an extra API call after every .search.
The total should be available directly from the .search response—either:

  • included in the .search result payload itself.
    1. By passing a property to have search as paginated results
      or
    2. Change the endpoint to paginated results with proper response **1
  • via a reliable response header (as it worked before).

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 22, 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 client.threads.search({ limit: 50 }); ### Error Message and Stack Trace (if applicable) _No response_ ### Description Follow up on unsolved https://github.com/langchain-ai/langgraphjs/issues/1556, given that it was wrongly marked as 'solved' and I cannot re-open a ticket. **Disclaimer**: I'm using https://www.npmjs.com/package/@langchain/langgraph-sdk (Typescript) not Python one, like previous response from @hinthornw suggested. I would kindly ask to not close the ticket before a solution is accepted both ways/discussion ends. Two concrete issues here on the response provided https://github.com/langchain-ai/langgraphjs/issues/1556#issuecomment-3215912602 : 1. SDK mismatch (Python vs TypeScript) - The example points to the Python SDK’s .count, but the TypeScript SDK doesn’t expose .count. - That leaves TS clients with no single-call way to render real pagination controls (page count / total results). 2. Double round-trip is expensive - For every .search I now need to make a second .count call to show totals. - This adds latency, cost, and complexity on every list view and search UX, especially in UIs that paginate or show “83 results”. What would fix this (any of the below would work): 1. Best DX: Add an opt-in flag to .search (e.g., includeTotal: true or count: "exact") and return structure: ```ts // **1 type SearchResult<T> = { data: T[]; pageSize: number; nextCursor?: string; total?: number; // present when includeTotal is true }; ``` This option also prevents breaking changes for other versions/developers that just get the data from .search and are not expecting to receive now an object instead of array with the search results. 2. Other possible Best DX - implement proper pagination with model mentioned above **1. However this wouild have breaking changes, given that instead of results as array, it would be now an object. 3. If you don’t want to change .search’s response body: Keep the existing payload, but add a reliable header that returns the actual total when requested: - Keep your “has more” signal as-is (limit+1). - Add back a header for the true total (e.g X-Pagination-Total-Results or X-Paginational-Count). Otherwise, there's no way to know full results in Typescript SDK other than putting an absurd limit (preventing pagination from working). TL;DR There’s currently no way (aside from capping .search with a Math.max(limit)) to know the true total count of results for endpoints like threads, assistants, etc. Adding a .count method to the TypeScript SDK would still force an extra API call after every .search. The total should be available directly from the .search response—either: • via a reliable response header (as it worked before), or • included in the .search result payload itself. This avoids unnecessary double requests and keeps pagination ergonomics consistent across SDKs. TL DR: There’s currently no way (aside from capping `.search` with a Math.max(limit)) to know the true total count of results for endpoints like `threads`, `assistants`, etc. Adding a `.count` method (like it is done in Python SDK) to the TypeScript SDK would still force an extra API call after every .search. The total should be available directly from the .search response—either: - included in the .search result payload itself. 1. By passing a property to have search as paginated results or 2. Change the endpoint to paginated results with proper response **1 - via a reliable response header (as it worked before). ### 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:05 -05:00
yindo commented 2026-02-15 18:16:06 -05:00
Author
Owner
Copy Link
Copy Source

@dqbd commented on GitHub (Aug 27, 2025):

Hello! .count methods have landed in the latest SDK release!

@dqbd commented on GitHub (Aug 27, 2025): Hello! `.count` methods have landed in the latest SDK release!
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
bug
checkpointer
docs-needed
documentation
enhancement
good first issue
good writeup
help wanted
invalid
langgraph-supervisor
open-swe-auto
platform
prebuilt
pull-request
Mirrored from GitHub Pull Request
 question
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
yindo
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: langchain-ai/langgraphjs#348
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?