RetryStrategyOptions - strange new errors in webhooks

[mateo]

Hi there!
For a few days, we have been getting those errors across all our internal and our clients’ internal apps."

Webhook HTTP request failed with exception The 'RetryStrategyOptions' are invalid.\nValidation Errors:\nThe field MaxRetryAttempts must be between 1 and 2147483647.

When we read this error, it indicates that there shouldn’t be a 0 value in the “Execution Options” section of the webhook step in the field “max number of retries on failure”

If this is the problem:

1. Why can we save the app with 0 in there?
2. Why was it working fine for months?
3. Why can’t we say that if an error occurs, DO NOT try to do it again?

If it is not a problem, is anyone here who might know what’s the actual problem?

Thanks!

[sak]

I also have this issue. It’s been going on for the past few days.

[mateo]

It is getting serious. I can see that across all my apps. I know the quick fix is to increase this value but I do not want to do this because in case of na error those bots might create a huge mess… I cannot believe that I am the only one affected here. Are you aware of this at all?

[MultiTech]

The real problem is that they made a critical change WITHOUT TELLING US.

Exacerbated by the fact that webhook automation task steps DON’T produce an error when the webhook is in error;

• Even when a webhook fails, the task in the automation shows green

---

So if you didn’t know things were failing… you wouldn’t be alerted to that fact.

Gotta love silently failing systems.

[Boleslav]

I have same issue.

[FEI]

My problem is slightly different from yours, but there’s definitely a problem with the AppSheet webhook. Currently, the Max number of retries on failure setting can’t be set to 0. However, if it’s set to anything other than 0, the webhook will start to experience other issues. However, in Monitor, only successful executions are visible. In reality, AppSheet keeps experiencing incorrect retries. Setting the Max number of retries on failure setting to 1 results in duplicate operations in the backend.

[Trevor_Ryland]

Appsheet engineer here - I apologize for the trouble. This was an unintended regression, stemming from what should have been invisible changes to the underlying code when a webhook is invoked, and not a deliberate change in behavior. We’ve identified the cause and have prepared a fix, which is planned to be deployed on Monday (9/8).

[mateo]

Awesome @Trevor_Ryland, thank you for letting us know!

[Suvrutt_Gurjar]

@Trevor_Ryland ,
May we know if the fix was deployed yesterday.

Apologies if you have already communicated it in some other post that I might have missed.

[Trevor_Ryland]

The fix went live on 9/9 (sorry again for the delay).

[Suvrutt_Gurjar]

Thank you @Trevor_Ryland for the update.

[mateo]

That’s coooool