Client specification header makes server send stale information

[edoardo-liotta]

Describe the bug

While running the tutorial for running open-source Unleash server + Java client, I saw that the toggle status did not change accordingly to my changes on the Unleash UI. After debugging, I found the request the SDK does to the Unleash server to update the toggle status (partially documented also here) and replicated it in Postman. Apparently, the server is indeed returning obsolete status, BUT if I didn't send the Unleash-Client-Spec header, then the server provides me with the up-to-date status. Setting the header back makes the server return the obsolete status again.

So, it looks like Java client only does what the server tells. Is there any additional header/configuration I should set in addition to the basic one described in the "Get started" tutorials, in order for the client to send some header which will tell the server to get up-to-date info?

Steps to reproduce the bug

1. Run an open-source version of Unleash via docker-compose up -d
2. Set up a feature toggle with any strategy (the default should do, as I'm not sure whether the gradual rollout is implemented in the Java client)
3. Set up a Java client following the tutorial, using the default insecure token and http://localhost:4242/api/ as Unleash URL, and activating synchronousFetchOnInitialisation
4. Have the Java client look for the feature toggle created before
5. Change the status of the toggle in the UI
6. Wait for the fetchTogglesInterval time to pass
7. Have the Java client look for the feature toggle again

Expected behavior

I expected the configuration to be updated. The server actually returns the previous configuration.

Logs, error output, etc.

No response

Screenshots

Additional context

No response

Unleash version

Unleash 5.2.2 (Open Source)

Subscription type

Open source

Hosting type

Self-hosted

SDK information (language and version)

io.getunleash:unleash-client-java:8.2.0

[thomasheartman]

Hi, @edoardo-liotta, and thanks for opening the issue! 👋🏼 Thanks also for including such clear steps to reproduce it.

I wasn't able to reproduce it using cURL on my end. I used the most recent Unleash server image (5.2.8) and curl to fetch toggles. I don't seem to get stale data when including the 4.2.2 header.

Your postman screenshots indicate that you have more headers than what are shown. What are the remaining three headers?

However, I am able to reproduce it when running the OkHttp example in this repo. But in that case, it seems to be because the Unleash server returns a 304, indicating that there hasn't been an update. Is that consistent with what you're seeing?

[edoardo-liotta]

Ciao, the three remaining headers are Postman-Token (calculated upon request), Host (calculated upon request) and User-Agent (PostmanRuntime/7.32.3). Your very last sentence is consistent with what I experience. The server does return a 304, although the contents were indeed updated on the server via the UI. My tests with Postman indicate that the server DOES know about the update, but for some reason, they are not being returned. I couldn't reproduce the actual 304 but the meaning is indeed the same. I can't quite get whether this is a server-side or a client-side issue. A test with the React SDK would hint me into the fact that it's a client issue (the update is shown on the front-end in near-real time).

[thomasheartman]

Thanks for the clarification! I think this is a client issue. At least, we've not had any reports of similar issues for other SDKs, and in all the others SDKs that I have tested myself, it's been working correctly.

Our primary Java maintainer is on holiday at the moment, but I'll take it to the team and we can prioritize discovery and a fix for the issue.

[sighphyre]

Hey @edoardo-liotta, so we did a bit of digging here, it seems the 6.x range of the SDK did indeed have this bug where this wouldn't update correctly, the examples that @thomasheartman was running bumped into this issue. We can't reproduce it on the 8.x range though. And I also can't reproduce this with postman against v5.2.2 of Unleash itself with the client spec header.

Would you mind doing some sanity checking of your setup for us? In particular, docker is a bit difficult with versions, can you confirm from the Unleash UI that you are actually running 5.2.2 (you should see this in the footer of the UI). Can you also double check that you don't have multiple versions of the JavaSDK loaded into your class path? I just want to eliminate a stale, buggy version coming back to bite us here

Also, you mention a tutorial, could you point me to the tutorial you're following? It turns out we have a lot of tutorials and I just want to confirm they're up to date

[edoardo-liotta]

The Unleash server is indeed 5.2.2 (was asked in the "New bug" screen). You may be right in the Java SDKs. I have 1.8 in my PATH. which should I have? The test Java project I am testing the SDK into is running under Java 11. By the way, using Docker wouldn't make sure to use an exact, pinpointed version of the Java SDK? Nevermind, I just mixed up things.

The tutorial I was following is this, and the Java SDK info are from here.

[sighphyre]

Hey @edoardo-liotta, I just want to confirm the version of the Unleash Java SDK version you used for this. We're aware of this bug in version 6.x of this SDK, the latest is unleash-client-java-8.2.0, which shouldn't have this bug

[edoardo-liotta]

I can confirm I used Unleash Java SDK 8.2.0 for my tests. From my build.gradle.kts: implementation("io.getunleash:unleash-client-java:8.2.0")

[andreas-unleash]

Hi @edoardo-liotta , can you please verify that unleash-client-java:8.2 is the ONLY version of unleash-client-java in your classpath?
Unfortunately I am not able to reproduce. If you would be kind enough to create a public repo that reproduces your issue, I will be happy to look at it.

[chriswk]

I have one more question. Are you using the default http agent, or have you changed to the OkHttp? We saw OkHttp have some issues with 304s and how it does its response handling in 6.0.

[edoardo-liotta]

We do use the OkHttp client in other contexts, but in our Unleash tests we didn't change anything related to its setup. We moved to using it because we had lots of issues in AWS with the Apache HTTP client. I'm sorry I couldn't take the time to set up a public repo, as we were testing within an existing project - I need to strip out everything that's un-shareable.

[daveleek]

Hello @edoardo-liotta. Were you able to reproduce this in a public repo that we could look at? Or maybe you managed to get this issue solved?

[daveleek]

We'll close this for now, but feel free to reopen or open a new issue if there are more things you want us to take a look at here!