I’m running into an issue with a backend workflow. I’ve had to do a manual OAUTH 2 integration with the Bubble API Connector which is working fine. As a part of that, I save a refresh token and “expires at” values. Expires at are coming in as Epoch values.
As certain events come in as webhooks, they could come in when the user doesn’t have a valid access token since they expire every 6 hours. The webhook creates fine, but to get more detail, I need to run a check on whether their access token is valid before fetching the data from an external API.
My problem is that Bubble seems to be ignoring the “only when” condition and running the refresh anyways.
The flow I has is the following:
User’s access token “expires at” is converted from Epoch (s) to UNIX (ms) by multiplying by 1000 when it’s created. This works fine.
Webhook comes in, and it creates the thing. This is fine.
Schedule an API Workflow is run to get the new access token, “only when expires at is less than or = to current time:extracted to UNIX”
Baffled as to why the access token workflow is run regardless of the true/false of the “only when” check. I manually put in some text boxes and the same only when statement in on a conditional box and it all calculates correctly. Is there something I’m missing in terms of how only when is used?
My guess is that the condition itself is always returning true, so it’s always scheduling the API workflow. I would replicate the conditional in a regular workflow so you can use the debugger to check the actual values. Use the same method of converting to UNIX (ms) and UNIX and see what the values are and if they always result in the conditional being true.
Good suggestion! I tried that and it’s evaluating the result correctly. The only difference between the front-end workflow and the back-end workflow is the front-end one uses “Current User” and the back-end one uses “Search For Users:first item” based upon the webhook data to find the right user. Is there another way to do this?
In the webhook there’s an “owner_id”, I have that saved as a field on the user. So the Search looks for the User that has that owner_id (which is unique by User).
Well, that should work. I’m sure you’ve confirmed the owner_id is in fact being updated on the user record. I highly doubt this is a bug in Bubble and that the workflow is mistakenly being run. I still think the condition is always returning true, you just have to figure out why.
Maybe there’s an issue with the search where there is a trailing space on owner_id? Try using trim maybe? These things are so hard to figure out without debugging capability on the backend.
Only other suggestion I have is to create a debugging field manually. Before the step where you schedule the API, create a new data type (called “debug_it”) or something like that. Log the owner id and the expiration date by creating a new thing. Then you can check the values there.
Great suggestion on the “debug item”! On doing this, I noted that the fields for the user ID and the token expiration weren’t populating.
Turns out the issue was the data type privacy settings. Once I set the workflow to run while ignoring the privacy settings, the fields seemed to populate, but I also created an “expired” field that was set to yes/no on the same calculation that I was using for the only when condition. This isn’t populating!
OK, well that’s a good clue as to what’s going on.
One quick thing you can try is to make the conditional an explicit step in the workflow. So the workflow would look like this:
Create a new debug_refresh (just like you have above) except set expired=no
2)Make a change to debug_refresh. Thing to change = <however you’d search the debug_refresh record, I don’t know how you’ve set up the data type> Set expired = yes Only when search for debug_refresh’s expired <= current date/time:extract Unix.
If that isn’t updating properly, then I think you’ve proven that somehow the comparison between your expires_at and current date/time isn’t evaluating correctly and that’s probably the root cause as to why it was always firing the back end workflow in the first place. Is there a way you can simulate that exact comparison somehow in a front end workflow so you can use the debugger to see exactly what’s going on? Maybe just use a custom state and cut/paste the value from the debug record into the default of the custom state and see if that works as a test?
Sounds to me like you are referring to the webhook data rather than the data saved in your database as the users expiry date. Should make sure you reference the expiry date that is in your database. Plus the webhook expires at is just a number of seconds…typically you need to add that value to the current date/time (current date/time +seconds (expires at value))
Another note, when performing the get new access token, don’t put it into a API workflow, put it into a custom event in the backend workflows so that it will execute and complete before the next steps in the series of actions you would be using it in.
Be sure to checkout the Stripe Integration Course when you are ready to integrate Stripe payments to start monetizing your application via product sales or subscriptions.
Thanks guys. I’ve the suggested changes and have a token expiring here soon so I’ll give it another test.
Related to this… I have to admit I haven’t utilized Custom Events, but I’m intrigued as it seems to force things to happen before the next action happens which I’m clearly seeing isn’t the case with Scheduled API Workflows. Main question on these… is there a way to run a custom event on a list of items? So basically, let’s say I have to create a bunch of things off a list and I don’t want the next action in the workflow to fire until all of those things are created. Could you point me to a good resource on how that might happen with a custom event?
If you have a way for the actions in the custom event to reference the list yes because you can do any action in a custom as you can in a API workflow, but the custom event ‘type’ setting only allows for one entry.
Thanks @joeyg and @boston85719 , all seems to be working now. For whatever reason, the Server Log doesn’t show the expired value, but the things that are being created in the debug process are. Either way, seems that it’s working now as expected.
