As of now, there is no way to override default error handling logic for new content sources as per this page:
https://docs.arcxp.com/alc/en/content-source-api?sys_kb_id=7af21b2147f0c210a87626c2846d43e4&id=kb_article_view&sysparm_rank=5&sysparm_tsqueryId=173e4ca0c3ec5210a046930a050131a4
This created a lot of useless messages in production logs like below:
ERROR error fetching content in fetch content source: Error: Result not found.
What we would like to have is some sort of "handleError" callback, that would allow to override default error handling behaviour - like log more informative message or override text, that is returned with HTTP response body.
Guest
Thanks for your reply, Fatih.
You mentined:
"We require customers to throw errors when using fetch method, when the content source execution should fail,"
What we're concerned with is logging, which is happening in Pagebuilder's code (not controlled by customer), when customer is throwing errors from their custom content sources. As of now, this logging gives no valuable console output:
Example:
ERROR error fetching content in fetch content source: {customer message}
Such messages create additional overhead on our log managing system and create a lot of duplicated error messages (considering, that customer is doing it's own error logging in content sources). So, it would be good to be able to override such behaviour. Moreover, some of such messages we would like to switch to other logging levels, because some 404 errors we would like to handle as warnings - current PB implementation does not allow this.
Just stress out:
I'm mentioning default logging, which PB does INTERNALLY, and this is not controlled by any customer code. What we would like to have - is some way to controll it.
Hi,
Thanks for submitting this idea. I want to expand what you mean a bit more.
This makes sense for managed "resolve" method since Engine handles the network request, and the response handling (like non-200 status codes, redirects, 404s), which you have less control on what the error returned.
Implementing your content source logic using "fetch" method gives you 100% control on how the network requests are constructed, using your own favorite library, as well as handling the response and the final outcome, including different http response codes you may receive (redirects, 4xx, 5xx codes), as well as logical errors like no results found or other. We require customers to throw errors when using fetch method, when the content source execution should fail, or should result redirects. This means you can construct your own error messages when throwing these error objects, or console.log the lines for log-only output. We have some examples of both error and redirect errors in this ALC doc.
Wouldn't this capability describe what you are suggesting?