proofgeist/fmdapi

Providing portalRanges to list() results in error

Closed this issue · 3 comments

When running:

const records = await client.list({
      layout: "Test:API",
      limit: 1,
      portalRanges: {
         test: {
            offset: 1,
            limit: 5,
         },
      },
 });

The following error occurs:

/root/fmdapi/dist/client.js:90
                for (const [portalName, value] of Object.entries(params.portalRanges)) {
                                                         ^
TypeError: Cannot convert undefined or null to object

This stems from the request function line 172, where the assertion checked is not the one then used to gather the Object entries:

        if (query.portalRanges) {
            for (const [portalName, value] of Object.entries(
               params.portalRanges as PortalRanges,
            )) {

I can't see anywhere that the portalRanges could be passed directly to request, rather than as being part of a query... I think it's potentially a quick fix.

In fact, I think this whole bit may be slightly broken as the keys are back-to-front, PortalName._limit rather than _limit.PortalName. I wonder if there is something I'm missing?

In any case, this fixes list, but not sure if it breaks something else:

    // line 168
    if (query) {
         const { portalRanges, ...queryParams } = query;
         const searchParams = new URLSearchParams(queryParams);
         if (portalRanges) {
            for (const [portalName, value] of Object.entries(
               /** @TODO */
               portalRanges as any as PortalRanges,
            )) {
               if (value) {
                  value.offset &&
                     searchParams.set(
                        `_offset.${portalName}`,
                        value.offset.toString(),
                     );
                  value.limit &&
                     searchParams.set(
                        `_limit.${portalName}`,
                        value.limit.toString(),
                     );
               }
            }
         }
    // ...

@traverse1984 This is an undocumented feature according to their API, but I believe I have found the fix. Thanks for pointing it out! Look for a new release soon