ApiClient default HttpClient fails to connect if protocol version is not HTTP_1_1

[holgerstolzenberg]

Checklist

• I have looked into the README and have not found a suitable solution or answer.
• I have looked into the documentation and have not found a suitable solution or answer.
• I have searched the issues and have not found a suitable solution or answer.
• I have upgraded to the latest version of OpenFGA and the issue still persists.
• I have searched the Slack community and have not found a suitable solution or answer.
• I agree to the terms within the OpenFGA Code of Conduct.

Description

I am using the SDK to connect to an OpenFGA instance. I am using Java 21 (Liberica) and operate in a Spring Boot context.

Taken the following code:

@Bean
  public OpenFgaClient openFgaClient(
      final ClientConfiguration clientConfiguration, final ObjectMapper objectMapper) {
    try {
      // FIXME report to ofga project
      final var httpBuilder = HttpClient.newBuilder().version(HTTP_1_1);
      final var apiClient = new ApiClient(httpBuilder, objectMapper);

      final var client = new OpenFgaClient(clientConfiguration, apiClient);
      log.info("OpenFGA client: {}", client);
      return client;
    } catch (final FgaInvalidParameterException cause) {
      throw new BeanCreationException("Failed to create OpenFgaClient", cause);
    }
  }

everything works. The thing that made it working for me was setting the underlying HttpClients protocol to HTTP_1_1.

if you replace final var client = new OpenFgaClient(clientConfiguration, apiClient); with final var client = new OpenFgaClient(clientConfiguration); - using the default ApiClient and then do whatever call to OpenFGA the connection will not get established. Instead the SDK blocks the call unlimited until the server cancels the call by timeout.

This is due to to an unrestricted call of the CompletableFuture in the function exchangeToken():
https://github.com/openfga/java-sdk/blob/main/src/main/java/dev/openfga/sdk/api/OpenFgaApi.java#L1165

Expectation

Not sure actually. Just wanted to bring that to the table. Maybe HTTP_1_1 should be set as default, as you can find a lot of issues regarding HTTP/2 and Java in the wild.

At least the call should not block indefinitely but rather use the configured timeouts.

Reproduction

GIVEN
  you use the Java SDK
TO
  connect to a OpenFGA instance
USING
  the default ApiClient without customisation of the HTTP protocol
EXPECT
  the SDK to block until the server terminated the connection

OpenFGA SDK version

0.7.1

OpenFGA version

v1.8.0

SDK Configuration

Via Java SDK, see provided code snippets

Logs

There are no logs. The client just blocks until the server closes the connection after the server side timeout.

References

None.

[jimmyjames]

Apologies for the late reply, but @holgerstolzenberg are you able to reproduce this using the example in the repo? That uses the default Http client and client credentials. I wonder what else may be factoring in here, perhaps the spring context?

[holgerstolzenberg]

No worries. So I do have some new findings. I tried the example you linked with JDK-17 (Liberica) set up.

I can confirm the issue is still happening, but only with OIDC enabled. Disabling OIDC on the server and using no credentials on the client the calls for e.g. listing stores succeed.

I have to mention that in my test setup I run OpenFGA and Keycloak behind a Traefik reverse proxy. I did a quick test connecting to OFGA directly and it also worked with disabled OIDC. I had no time to setup Keycloak without Traefik, so that might play a role here.

Still - even if the error should be related to Keycloak and/or Traefik, I would expect the client to fail with a more specific error instead of blocking indefinitely. I saw the other issue with the connect timeout not honoured, I suspect this might also be an internal issue when connecting to the OIDC provider.

Yet changing the default behaviour to HTTP 1.1 is a good step as it mitigates the issue.

I am not sure how to proceed with this, currently have no time to really dig deeper, but maybe the findings give you some hint on where to look at.