When RelayProxyEndpointsWithoutEvents is used to configure an SDK's ServiceEndpoints, it throws an error-level log message explaining that only some URIs are set.
This logic was intended to surface a common mistake of only setting one URI when the developer meant to set all 3. In this case the error is incorrect as we're making this choice explicitly as a supported use-case: use Relay for streaming and polling, but send events to LaunchDarkly.
There are many ways to approach fixing this in a backwards compatible manner. Ideally, we'd have constructors that embody the supported use-cases.
To avoid introducing a new construction API, I've taken a minimal approach of adding a new setter/getter on the ServiceEndpoint struct to indicate if partial-specification of custom URIs was intentional or not.
This way, we can later check that the constructed ServiceEndpoints intentionally hasn't set the events endpoint and decide whether or not to log a message.
When
RelayProxyEndpointsWithoutEvents
is used to configure an SDK'sServiceEndpoints
, it throws an error-level log message explaining that only some URIs are set.This logic was intended to surface a common mistake of only setting one URI when the developer meant to set all 3. In this case the error is incorrect as we're making this choice explicitly as a supported use-case: use Relay for streaming and polling, but send events to LaunchDarkly.
There are many ways to approach fixing this in a backwards compatible manner. Ideally, we'd have constructors that embody the supported use-cases.
To avoid introducing a new construction API, I've taken a minimal approach of adding a new setter/getter on the
ServiceEndpoint
struct to indicate if partial-specification of custom URIs was intentional or not.This way, we can later check that the constructed
ServiceEndpoints
intentionally hasn't set the events endpoint and decide whether or not to log a message.