Different result of returning values from the API Cammunda 8.8

Camunda 8 Topics
1

Hello !

I’m using Camunda Self-Managed 8.8.
I’m getting very strange behavior when calling the API methods at http://172.16.79.185:8088/v2/jobs/search (orchestrator).
When using the same Bearer token, I receive different data results.
When sending the request through Swagger with the same body and token, I get several items from Camunda.

Pasted image 20251027114723
Pasted image 202510271147231232×1202 56.6 KB

Pasted image 20251027114734
Pasted image 202510271147341173×1124 99.4 KB

But when sending the same request — but through Postman or any other HTTP client — the API returns an empty list.

Pasted image 20251027120210
Pasted image 202510271202102517×1226 214 KB

Pasted image 20251027114646
Pasted image 202510271146462549×1211 230 KB

Pasted image 20251027120042
Pasted image 202510271200421570×1182 94 KB

Why does the api return a different result, even though the request had the same token and the same body? How do I understand what the error is (is it in the documentation)? Then how am I supposed to send a request if I want to do it with a code (unfortunately, when I send a code, it also returns an empty result), or what should I do so that I can send requests and receive data? Thank you in advance!

2

Hi @ilya.sector.1, welcome to the forum! Jobs are eventually consistent (you can read more by clicking the “Learn about endpoint consistency” link here). So my first question is how repeatable this result is within your cluster? If you query via Swagger, then via Postman, then back to Swagger with a fresh request, do you still get inconsistent data? How close together are you making these requests?

3

Hello @nathan.loding!
Requests for data with basic identical data 1. The token is the same 2. The filter is the same 3. The router is the same That is, you can see it in the screenshots above (there is full information about requests, the difference is only in the SessionID, CSRF is ok (it is not needed since I log in through Bearer). However - maybe (I’m not sure) I fixed it by specifying the orchestration-api client’s orkerstrator in the configuration. Can you tell me based on the screenshots that I posted earlier - why can this happen when depressing containers (and not changing configuration settings)? I just downloaded the files from the github and raised the full version via docker-compose. Thank you in advance!

4

@ilya.sector.1 - Camunda is eventually consistent, and because jobs are constantly moving through the system, there are many scenarios where slightly different responses are expected and by design. The answers to your questions depend on quite a few factors.

  • how repeatable this result is within your cluster?
  • if you query via Swagger, then via Postman, then back to Swagger with a fresh request, do you still get inconsistent data?
  • how close together are you making these requests?
5
  1. We have one cluster (it’s a test one) and it’s always the same through Swagger — it returns the list of UserTask.
  2. No. I only get data through Swagger; through Postman or curl, I get a result with 0 items.
  3. After 1 second, almost simultaneously — since the cluster is a test one, there are no sudden changes in the system state.
6

Hi Ilya,
can you verify that you use the same token in swagger and postman?
Maybe its visible in the network tab in the browser?
Is the token you use for a client that you configured?

Is it possible that the swagger uses your user authentication instead of a client JWT token you actually want to use?

7

The problem was solved – I added “orcherstration-api” to the security section of the Orchestrator configuration (yml), and it worked.

It’s strange that this wasn’t mentioned anywhere in the documentation, nor were other nuances like setting up audience in Key Clock.

8

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