Subscription returned as empty object

Version: chargebee-typescript@2.25.0

Using this

const response = await this.chargebee.subscription
  .list({
    'sort_by[desc]': 'created_at',
    customer_id: {
      is: customerId,
    },
  })
  .request();
return response.list;

it returns an array of empty objects of type Result

Example of console.info(response) from the request above:

ListResult {
  list: [ Result {}, Result {}, Result {}, Result {} ],
  next_offset: undefined,
  responseHeaders: {
    date: 'Thu, 26 Oct 2023 10:59:56 GMT',
    'content-type': 'application/json;charset=utf-8',
    'transfer-encoding': 'chunked',
    connection: 'keep-alive',
    'cache-control': 'no-store, no-cache, must-revalidate',
    expires: 'Thu, 01 Jan 1970 00:00:00 UTC',
    'strict-transport-security': 'max-age=31536000; includeSubDomains; preload',
    pragma: 'no-cache',
    vary: 'Accept-Encoding',
    server: 'ChargeBee'
  }
}

So it seems that subscriptions are getting read, but actual data is not projected.

Chargebee is being instantiated the way it is displayed in docs:

this.chargebee = new ChargeBee();
this.chargebee.configure({
  site: this.resolveName(),
  api_key: this.resolveApiKey(),
});

Am I doing something wrong? is it a bug?

[sebyddd]

Seeing the same issue when fetching Hosted Pages using the Typescript client. It appears to be a client-side parsing problem, specifically with the content field in the response. Direct API fetches via cURL yield the complete and correct response, indicating that the issue is isolated to the client's handling of the data.

[MerrittJ]

Also facing this issue with invoices and customers entities

        const items = await chargebeeClient.invoice
            .list({
                subscription_id: { in: [subscriptionId] },
            })
            .request();

returns

ListResult {
  list: [ Result {} ],
  next_offset: undefined,
  responseHeaders: {
    date: 'Thu, 18 Jan 2024 18:01:40 GMT',
    'content-type': 'application/json;charset=utf-8',
    'content-length': '3867',
    connection: 'close',
    'cache-control': 'no-store, no-cache, must-revalidate',
    expires: 'Thu, 01 Jan 1970 00:00:00 UTC',
    'strict-transport-security': 'max-age=31536000; includeSubDomains; preload',
    pragma: 'no-cache',
    'x-content-type-options': 'nosniff',
    vary: 'Accept-Encoding',
    server: 'ChargeBee'
  }

[yksolanki9]

Facing the same issue, any update on this?

[cb-sriramthiagarajan]

Hey folks, my apologies for the delay in response.

This looks like an issue with using console.log / info with the ListResult object directly. I can see the result being printed when I access an array item directly (like console.log(response.list[0]) instead of console.log(response.list)) and this also lets you access any property in the object directly (like response.list[0].subscription). So looping over the result and accessing individual objects should also work. Does this help?

One of the possible solutions to make the result work with console.log is to have util.inspect.custom method in our result object. We'll further evaluate in the future if this the right approach.

[skysteve]

There's something v weird happing with this library in general. If I debugger inspect I can see there's a lot of keys but if you do Object.keys() on the response only response headers shows up, which is likely why console log is broken. This also happens if you do JSON.stringify(reponse), you only get the response headers.

I'm not sure I understand the additional complexity of the model class vs just returning a JS object.

If I do the following it works

  const response = await chargebee.subscription.retrieve(subId).request();

  return JSON.parse(response.toString())

But it adds additional complexity and isn't very intuitive (I had to read the code in the model class above to figure this out). There's potentially another argument that .toString() shouldn't return a JSON string either but I'll save that debate for others.

I see there's a V3 SDK coming so fingers crossed this is addressed in that but in the meantime hopefully the .toString() hack works for others

[cb-sriramthiagarajan]

Thanks for the note @skysteve. Yeah, I agree that it's not very intuitive. And the good news is that we've fixed this (and some) in v3, which is currently in beta 😄

It'd be great if you all could give it a try and share any feedback. We have a Migration guide for v3 and the README in the next branch also has more info on the usage.