When troubleshooting page issues in Arc XP, it is often difficult to understand which API calls are being executed, which components are using them, and whether responses are successful or failing.
Today, similar API calls can look identical, parameters are not always clearly visible, and it’s hard to see how a failed API impacts specific components on a page. This makes debugging slow and requires switching between multiple tools or logs.
It would be extremely helpful to have clearer visibility into:
• Which APIs are called for a page
• What parameters are used in each API call
• Which components depend on each API
• Clear success/failure indicators for each call
This would significantly reduce time spent debugging and improve confidence when diagnosing platform or content issues.
Paul Stanciuc
Hi Paul, and Jack,
Not noted in the idea or description but highly confident that you're talking about PageBuilder. Correct me if this assumption is wrong.
Here is what we got currently:
PageBuilder Engine has a development feature call request tracing, which is an opt-in feature controlled by an environment variable. It's disabled on Arc XP environments, but its intent is to be used in local development environment. Once enabled, your engine logs will become overly verbose, and show you all http calls from content sources. This can make your console/terminal output really difficult to navigate, but if you are using a log analysis tool, or an agent to analyze them, it's really really useful for it.
Separately it records all calls in that Engine session into
calls.jsonlocal file which also can be processed by an agent or a script, or tooling to visualize, analyze what's failing, what's hitting cache, what's failing to write to cache (you can catch cache health issues too).See documentation about request tracing capability: How to Request Tracing in Content Sources with PageBuilder Engine
This should answer most of what you asked, but doesn't fully give you the "component" side of the story, also not in Arc XP environments (you can guess that verbosity level will have both performance, and cost issues, so it needs to be designed differently to work in a high-volume environment) like a more OOTB debugger tool. So I'll keep this feature request open, for future consideration to consider making request tracing experience more native.
I second this. The lack of visibility is making it incredibly difficult to debug and investigate issues and correlate any change that is occurring in any environment.
Please run this up the chain to be added to the roadmap :-)