Client specification header makes server send stale information about unleash-client-java HOT 12 CLOSED

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?

from unleash-client-java.

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).

from unleash-client-java.

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.

from unleash-client-java.

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

from unleash-client-java.

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.

from unleash-client-java.

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

from unleash-client-java.

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")

from unleash-client-java.

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.

from unleash-client-java.

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.

from unleash-client-java.

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.

from unleash-client-java.

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?

from unleash-client-java.

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!

from unleash-client-java.