Hi @anna-gn my initial response would be that we don't want this to happen. What's the need for this request?

Connection Id is something internal for Unleash and shouldn't be overridden. You can find this documented here: https://docs.getunleash.io/reference/sdks#sdk-identification-headers

Hi @gastonfournier, I assume that without this fix our metrics won't be correctly attributed to our client apps and users.
The documentation says:

The same connection ID should be used for each request when an SDK instance polls the API

More on our use case:
to be able to use a custom storage implementation, we create our own Poller instance, for which we generate a connectionId, since it's required by the initializer:

Connection Id is something internal for Unleash and shouldn't be overridden.

As an alternative, would it be better to provide an overriding API for the poller, other than in the client initializer? In our case, it will also work if we could just override the poller storage.

metrics won't be correctly attributed to our client apps and users

Client app should be identified by their appName, not the clientConnectionId. In a single App you can have multiple instances running of the app, each should have a unique connectionId. We can't guarantee that if we allow users to override it.

As an alternative, would it be better to provide an overriding API for the poller, other than in the client initializer? In our case, it will also work if we could just override the poller storage.

Yes, this could be on possible solution IMO. An alternative would potentially be that we expose the assigned connection id so you can use it, but maybe your proposal seems a bit simpler, reducing the API surface that you have to implement.

I'll bring this to the team