Breaking Change in v2.20.4

[jspizziri]

This chunk of code which was introduced in this commit and ultimately released in v2.20.4, is an undocumented breaking change (I realized that there's documentation for the new setting, I'm referring to the fact that it's nature as a breaking change is undocumented).

It requires the reconfiguration of the createClient call to pass new properties or differently formatted paths for cdnProxy.

Similarly, the changes made to the getEndpoint method here are also breaking.

[sunitaprajapati89]

useSegmentEndpoint is false by default which behaves the same as the previous versions. Tell us your use case to show how things are actually broken.

[jspizziri]

@sunitaprajapati89 ,

Issue 1 - fetchSettings

Previously you could create a client like so:

const segmentClient = createClient({
  proxy: 'https://some-domain.com/v1/batch',
  cdnProxy: 'https://some-domain.com/v1/projects',
  writeKey: 'SOME_WRITE_KEY'
});

The resulting settings request would end up hitting the following settings endpoint:

https://some-domain.com/v1/projects/SOME_WRITE_KEY/settings

Now, you must set useSegmentEndpoints to true (again, as you say it defaults to false) in order to achieve the same effect. If you look at the change to the fetchSettings function in the diff I linked you'll see this. However, to make it easier I'll include a screenshot below (unfortunately linking to the specific line in the diff doesn't seem to be working, but I've left a comment tagging you directly in the diff).

In all, this issue can be somewhat avoided by setting useSegmentEndpoints: true, however when you do this, the next issue compounds on top of this one.

Issue 2 - useSegmentEndpoint: true results in endpoint override

In versions prior to v2.20.4, the proxy that was passed in via config was simply respected, and returned as the endpoint from the getEndpoint function. However, that is no longer the case. When you pass useSegmentEndpoints: true (which is now required to get the settings endpoint to behave the way it had before) along with a proxy, the endpoint gets overridden with a /b. So you need to set useSegmentEndpoints: false in order for this to work the way it had before. I've commented on the diff as before and here's the screenshot:

It's very important to note that Issue 1 & 2 are interconnected.

[jspizziri]

@sunitaprajapati89 could this issue get reopened given I've provided the requested information?

[sunitaprajapati89]

Thank you for the detailed explanation — you’ve raised a very valid point. You're essentially using your own domain and endpoints, so it makes sense to pass the full custom cdnProxy and proxy URLs.

We acknowledge that this is a breaking edge case we overlooked. The previous implementation had inconsistencies between cdnProxy and proxy behavior, and while the new design introduces a change, we believe it brings more clarity and consistency going forward.

We’ll be adding a note in the release documentation to highlight this breaking change so others can avoid confusion as well.

[jspizziri]

@sunitaprajapati89 thanks for your response.

So to be clear, it sounds like there are no plans to fix the breaking change, is that the correct understanding?

[sunitaprajapati89]

@jspizziri : Yes, your understanding is correct as I mentioned the changes we did, it brings more clarity and consistency going forward.