Irritating warning Already signed out

[exaSR]

Steps to reproduce:
List the minimal actions needed to reproduce the behavior.

1. Open and use multiple connections in a sequence, closing them after use
2. Perform at least one operation on each connection

(see example code below)

Expected behavior:
Each connection is independent, performs as expected and does not trigger any unexpected warnings

Actual behavior:
Each connection is independent, performs as expected.
However, querying the second connection results in a log-warning:

Nov 16, 2023 1:31:42 PM com.influxdb.client.internal.AuthenticateInterceptor intercept
WARNING: Authorization interception failed. Already signed out.

As far as my debugging attempts got me, the reason is that the same AuthenticateInterceptor object is reused for multiple connections, and its signout flag is set when the first connection is closed, but is never reset for the second connection...

Specifications:

• Client Version: 6.10.0
• InfluxDB Version: 2.7.0 (yes; outdated, but the enforced change in join syntax is painful)
• JDK Version: openjdk-17.0.8
• Platform: Fedora 38

Example Code:
The actual code is connecting to different organizations and different users, so any recommendation to just reuse the client is not helpful.

public void produceWarning() {
    InfluxDBClientOptions options = new InfluxDBClientOptions.Builder()
            .url(influxUrl)
            .org(influxOrg)
            .authenticateToken(token)
            .build();

    InfluxDBClient client = InfluxDBClientFactory.create(options);
    client.getBucketsApi().findBuckets();
    client.close();

    InfluxDBClient client2 = InfluxDBClientFactory.create(options);
    // this one produces the warning
    client2.getBucketsApi().findBuckets();
    client2.close();
}

[powersj]

@bednar - looks like we are re-using the AuthenticateInterceptor causing problems with re-use. Can you confirm?

[bednar]

The issue is caused by reusing the OkHttpClient.Builder. The AuthenticateInterceptor is attached to the OkHttpClient.Builder, and when InfluxDBClientOptions is used for creating multiple client instances, they all end up using the same interceptor. We need to devise a method to ensure a unique OkHttpClient.Builder for each client instance in cases where the user has not specified their own.

[ycherabai]

any updates?

[bednar]

@ycherabai, unfortunately not. However, would you be interested in assisting with this? We welcome all PRs and would be glad to review your contribution.