.withSender() method on clientBuilder not working as expected

[justisfaulkner]

As mentioned in a previous issue, we have the need to use our own internal fetch function with built in observability that conforms to the rest of our platform's API requests. We wrote a wrapper around our internal function so that it satisfy's Smarty's SDK interface, but the issue we're now finding is that the request is not being constructed properly through the SDK. Specifically the baseUrl and Authentication headers are missing.

If we do something like

const client = new smartyCore.ClientBuilder(authId, authToken) // valid static credentials
      .withLicenses([SMARTY_CORE_LICENSE]) // optional, but including for future safety
      .withSender(sender) // wrapped internal, observable fetch satisfying Smarty SDK's interface
      .buildUsStreetApiClient(); // US Street product

Then construct a valid lookup like

const lookup = new usStreet.lookup();

lookup.street = 'valid street'
lookup.city = 'valid city'
...
// additional fields resulting in a valid lookup object

Then send the lookup like

const response = client.send(lookup);

We're receiving errors when making the actual request because our internal sender with the built in o11y is not receiving the baseUrl or authId and authToken in the request that Smarty is constructing.

It seems like .withSender() is bypassing the entire authentication (SigningSender) and base URL (BaseUrlSender) layer chain that the SDK normally provides. I'm assuming the LicenseSender is being bypassed as well.

Without the base and auth, we're effectively only utilizing the SDK to construct our lookup which would be simple enough without the SDKs implementation. We could get around this by passing the baseUrl and Authentication into our wrapped custom sender, but that feels duplicative since we're already passing those fields when building the client.

There isn't any documentation on using a customer sender, Is this the expected functionality? If so, why? It seems to render a lot of the SDK functionality useless.

If this is expected, a simpler and more type safe implementation for us would likely be to make the calls directly without utilizing the SDK at all.

Please let me know if we're missing anything or our implementation is not correct.

Any insight you could provide would be great, thanks!