Static Generation Logs cluttered with Fetch API ERROR for Content Links that are optional.

[jsimondshiebing]

We have a NextJS site that implements this package and Static Site Generation to build out our pages at build time. We have some fields in AgilityCMS that are optional content references such as a related blog post list that appears at the bottom of a blog post. However in the static build using the getCustomInitialProps and getContentList model from the agility-next package we are seeing 404 errors that are cluttering our build logs.

Here's an example call we have that results in a 404 error on build:

let socialEmbedList
if (socialEmbed && socialEmbed.referencename) {
  socialEmbedList = await api.getContentList({
    referenceName: socialEmbed.referencename,
    languageCode,
    sort         : 'properties.itemOrder',
    direction    : api.types.SortDirections.ASC
  })
}

In this example we have an optional socialEmbed that appears on some blog posts but others don't have them. The content reference exists on all posts, and so we don't really have a value on the socialEmbed to check if the content within it exists or not, and so the following call will happen regardless of if it needs to or not.

The following error in the log appears when attempting to build these pages statically. Note that I replaced our Agility API endpoint URL with a placeholder but left the query parameters in case you needed them.

AgilityCMS Fetch API ERROR: Request failed for CONTENT-API-ENDPOINT?contentLinkDepth=1&expandAllContentLinks=true ... Error: Request failed with status code 404 ... Does the item exist?

[joelvarty]

In this case you might be best off wrapping that call in a try/catch. If there are no items in a list it will always return a 404 from the API, which is an error like you are seeing.

[jsimondshiebing]

@joelvarty the issue from what I've been able to find is an error itself is already being captured within the agility/content-fetch package (in hindsight this issue should have been opened up there instead of here).

return api(reqConfig).then(async (response) => {
  let data = response.data;
  //if our response is from cache, inject that property in the data response
  if (response.request.fromCache) {
      data['fromCache'] = true;
  }
  if (config.debug) {
      data['agilityResponseHeaders'] = response.headers;
  }
  return data;
}).catch(async (error) => {
  logError(`AgilityCMS Fetch API ERROR: Request failed for ${reqConfig.baseURL}${reqConfig.url} ... ${error} ... Does the item exist?`)
});

this catch calls a utility function within the package called logError which is simply a wrapper for console.error to apply styles to the string being passed in. Regardless of if it is in a try catch or not the console.error call is still being sent to the console as it isn't an an actual exception being thrown for our try catch to capture.

[joelvarty]

Yes indeed - we are looking at adding log levels to that SDK.
However, if you wrap your call in a try/catch it will allow you to continue rendering your page, which I think is what you were trying to accomplish?

[jsimondshiebing]

we aren't having issues with our page rendering or building thankfully, we are simply having issues with reading our build logs since these 404 errors on optional fields are cluttering it up so much. when there are hundreds of blog posts that don't have an optional content list assigned to them that's hundreds of false errors that get sent to the build logs that we have to sift through.

[joelvarty]

Ahhh! I understand now. Could you open an issue here: https://github.com/agility/agility-content-fetch-js-sdk/issues
We should have full Typescript support and enhanced logging soon.