We are using a custom OAuth provider for auth in our Forge app. When a user attempts to use our app, we check for their credentials with this code, using the Forge resolver API:
const service = asUser().withProvider("service", "service-api");
if (!(await service.hasCredentials())) {
await whimsical.requestCredentials();
}
const response = await service.fetch("...");
If the user doesn’t have any credentials yet, the SDK throws an exception:
{
"message": "Authentication required",
"name": "NEEDS_AUTHENTICATION_ERR",
"stack": "",
}
This triggers the built-in alert to configure access:
Everything is fine so far, this is just how the SDK is built.
However, in the console metrics we see this show up as an error, and it triggers an alert because our request success rate has dropped, even though we just used the SDK as designed.
Is there a way to exclude these NEEDS_AUTHENTICATION_ERR errors from the metrics calculations? We’d like to use the alerts to warn us if there is a problem with our Forge app, but at the moment we can’t tell the difference between an issue on our end, or normal authentication behaviour.
5 Likes
Hi @DanielCompton,
You have a good point here. There isn’t an option to exclude them right now so I went ahead and raised a suggestion about this: [FRGE-1199] - Ecosystem Jira
Caterina
4 Likes
We are facing same problem when calling external API via api.fetch(). Each 401 code from the API is treated as an error in the metric. In my opinion this should be a warning (or it should be configurable).
Same here. I have voted for the issue. Our app is already cloud fortified, and this “error” drops the success rate … Can you exclude this from the measurements for the cloud fortified program?
1 Like
Same for us. These are errors produced by the way Forge handles authentication with external providers and we are getting drops in success rate because of that.
Does it even make sense?
@andi.muka @PeterAppsvio,
I read your frustration. Unfortunately, piling on here is the least effective way to get this problem solved. So I’ll ask the community to redirect their feedback to FRGE-1199 and to watch, vote, and comment there (as @clouless has done) so the appropriate team can understand the demand. To help encourage putting feedback into Jira, I’m going to lock this thread.
1 Like
