Using Bull Queue for scheduling Access Token refresh

@mebeingken or anyone else that is knowledgeable in Ken’s Bull Queue extension. It’s been a while since I used the extension and I’ve forgotten how to use it. :slight_smile:

I’m trying to set up a continual refresh of Access tokens once a user has connected their Google/Microsoft account.

The high level flow I’m trying to build is:

  1. User authenticates via OAuth
  2. Access token and Refresh token are stored in oauth table in database
    image
  3. I want to schedule a job that will refresh the access token to execute ~10 mins before the expiry time (60 mins from last refresh). When this refreshes the Access Token it should create another job to refresh the token again, so that every time it executes it’s creating the next job.

I’m not sure if this is possible in the current Bull Queue extension as I do not see any mention about the Repeatable job type in Ken’s documentation. Has anyone does something similar and could provide steps on how to implement it?

Hey Keith,

Repeatable jobs is definitely not added, but I’m happy to do this for you given your support. If you can wait a week-ish, I’ll make it happen.

1 Like

Awesome! I’m happy to wait.

Do you think that Repeatable jobs are the right direction forward?

I’m curious if anyone else has managed to accomplish token refreshes in other ways. I think @psweb might be doing it based on his responses in this post, but I’m not sure it is running on a schedule.

This goes back a few years, but I was tracking oAuth tokens manually as well. I took the approach of only refreshing the Access token (using the refresh token) when I needed it by checking the expires_at value…if expired, do the refresh routine before the api, otherwise just call the api.

But your use case might be different. I usually see if a scheduled job will work first as they are easier to build/test/debug.

Yeah, that might be a better direction.

I’m back to trying to build the same app I started on Bubble, but needed to move it to mobile/desktop clients. A big portion of the app is email. Long term, I think I’ll subscribe for updates, but initially I’m going to query for new emails periodically, so if I can have the client run a flow that checks if the token is still valid before checking for emails, that might work.