I believe this is a behavior that should be handled by the resolver debugger, even in the scenario that your resolver configuration is broken which was the case you saw no debugger output. I am bringing this up with the team to be scoped and planned. We're flagging this idea as the future consideration in the ideas portal for now.
No, none of that happens. The page doesn't change in any way when you hit the Fetch button - it just silently fails and you need to check in dev tools to see the HTTP status, but that's not very helpful since we don't know which resolver was matched. More details at the end of https://arcpublishing.atlassian.net/servicedesk/customer/portal/2/ACS-22312
I want to clarify what you are seeing. The Resolver debugger shows a browser (javascript) pop-up that say "could not fetch resolver" but then, it shows the resolver response in the debugger area. The response of the resolver contains the resolver that is matched but failed and the message/reason of the failure (example: your api call returned 404). Isn't this what you are seeing? If not, can you elaborate and help us understand the behavior better?
Rob W
Thank you for providing the ACS ticket Rob,
I believe this is a behavior that should be handled by the resolver debugger, even in the scenario that your resolver configuration is broken which was the case you saw no debugger output. I am bringing this up with the team to be scoped and planned. We're flagging this idea as the future consideration in the ideas portal for now.
No, none of that happens. The page doesn't change in any way when you hit the Fetch button - it just silently fails and you need to check in dev tools to see the HTTP status, but that's not very helpful since we don't know which resolver was matched. More details at the end of https://arcpublishing.atlassian.net/servicedesk/customer/portal/2/ACS-22312
Hey Rob,
I want to clarify what you are seeing. The Resolver debugger shows a browser (javascript) pop-up that say "could not fetch resolver" but then, it shows the resolver response in the debugger area. The response of the resolver contains the resolver that is matched but failed and the message/reason of the failure (example: your api call returned 404). Isn't this what you are seeing? If not, can you elaborate and help us understand the behavior better?