I have a use case where a user might need to change the status of an item back and forth. In this screenshot, clicking save triggers a webhook on this selected item
I noticed that when I change the status to On Hold the first time, it does indeed trigger the webhook. However, when I change the status to Pending a few minutes after, it doesn’t trigger the webhook. I don’t even see anything queued up.
I took a look at the audit logs and I can see that the webhook flag (do_submit) isn’t even being set
Here’s the first webhook trigger:
Is there some timeout that’s occurring in between me triggering the webhook? Are there any workarounds for this?
I think the issue is stemming from the usage of DB. (synced data) vs CloudCode (online data).
My theory is that the first time do_submit is set, it saves, syncs up and then fires the webhook as expected.
Secondly, in this case, when the second do_submit is set in the app, the synced DB. has not yet updated with the change CloudCode made, namely do_submit = null;, so the synced DB.save() still sees do_submit === true and so it does not see the second assignment as an update to the object because the value is still the same in the synced DB.. In other words, the second assignment of do_submit is seen as a “no-change” because it is setting do_submit to true while it was still true.
I would suggest having a check in the app to see if there is currently a “do_submit” in-progress with an OnlineDB call and instruct the user to wait a minute before firing another change. If offline flow is expected, then perhaps implement a dedicated object that can be created for each “do_submit” action, this way they will all get processed when the user comes online.
Let me know if any of the above is unclear or if you have any further questions.
Thanks Willem! We ended up staying with this method. The user would leave the item On Hold for days or hours so this should be fine. I’ll keep this in mind for any future implementations though.