/api/views/search/status/{jobId} pagination does not work

[mikk150]

I want to use Graylog API to query logs from Graylog and show them in application

According to API, I should be able to use pagination to do that

Expected Behavior

/api/views/search/status/<jobId>?page=0&per-page=1000 should return first 1000 elements for job
/api/views/search/status/<jobId>?page=1&per-page=1000 should return next 1000 elements for job

Current Behavior

page and per-page query parameters are ignored

Possible Solution

Steps to Reproduce (for bugs)

1. Create a new search
2. Wait for search job to finish
3. Try to get search job status(and it's data) with pagination

Context

Your Environment

• Graylog Version: 7.1.5(in docker)
• Java Version: Eclipse Adoptium 21.0.11(in docker)
• OpenSearch Version: Whatever the 7.1.5 datanode(in docker) has
• MongoDB Version: 7.0 (in docker)
• Operating System: Host OS: Manjaro.. others Docker
• Browser version: Not relevant

Checklist

[] This issue fix need to be backported.
[] Does this issue have security implications?

[janheise]

@mikk150 Did you try using the https://go2docs.graylog.org/current/making_sense_of_your_log_data/simple_search_scripting_api.htm ? Is there a specific reason why you are using the views API which is more geared to supporting the frontend?

[mikk150]

It's very simple. Views api has claims to have pagination support, that I would like to use, and as far as I can see simple search does not

[janheise]

I guess there is a misunderstanding/misconception:

I want to use Graylog API to query logs from Graylog and show them in application

👍

According to API, I should be able to use pagination to do that

probably not the way you expect to do it, because:

We try to steer users away to using the views API because we consider it an internal API that we can change without giving notice or guaranteeing backwards compatibility. Not every search that can be defined via the internal API ends up in a pageable result by design.
Can you give an example of a search that you are creating, so that I can check if it's actually supposed to create/execute a search with a pageable result?

The scripting API supports "paging" by using the from/size limiters.

But my recommendation is, that you create queries that always result in limited result sets. We (currently and all the time) put in a lot of effort to create tools to reduce the ingested data into small, meaningful result sets so that a user does not need to browse/page larger result sets. And the databases in the back also limit paging functionality.