This topic was automatically generated from Slack. You can find the original thread here.
Hey guys,
We use Gmail with Pipedream Connect and run into auth / refresh issues on long-running Gmail triggers. We’re trying to understand why this happens (for example token lifetime, how Connect refreshes Gmail, or anything specific to how triggers behave).
What do you recommend to make these setups more stable—anything we should design for on our side, or any platform features we should lean on?
One more thing: if auth fails on a long-lived Gmail trigger, should we always expect the end user to sign in to Gmail again, or does Pipedream offer another way to get things working again without that?
Thanks.
Certainly! Here’s a detailed answer to your questions about Gmail triggers, authentication, and stability in Pipedream Connect: — ### Why do Gmail triggers run into auth/refresh issues on long-running workflows? Gmail (and most Google APIs) use OAuth 2.0 for authentication. - When you connect Gmail to Pipedream, an OAuth access token is issued with a limited lifetime (typically 1 hour). - Pipedream stores a refresh token, which it uses to obtain new access tokens automatically when the old one expires. Common reasons for auth/refresh issues: - Refresh token revoked or expired: If the user revokes access, changes their Google password, or Google detects suspicious activity, the refresh token can become invalid. - Refresh token quota exceeded: Google limits the number of refresh tokens per user/app combination. If a user connects the same Gmail account to many Pipedream workflows, older refresh tokens may be invalidated. - Scopes or consent changes: If you change the requested OAuth scopes, Google may require the user to re-consent, invalidating old tokens. - Long periods of inactivity: Sometimes, if a workflow or trigger is not run for a long time, Google may expire the refresh token. — ### How does Pipedream Connect handle Gmail token refresh? - Automatic refresh: When a trigger or action runs and the access token is expired, Pipedream attempts to use the refresh token to get a new access token. - Failure handling: If the refresh token is invalid or revoked, Pipedream cannot refresh the token and the workflow will fail with an authentication error. — ### Best practices to make Gmail triggers more stable 1. Minimize the number of connections: Try not to connect the same Gmail account to too many workflows, as this can cause refresh token invalidation. 2. Monitor for auth errors: Set up error monitoring or notifications for your workflows so you’re alerted if a trigger fails due to authentication. 3. Prompt for re-authentication: If you detect repeated auth failures, prompt the end user to reconnect their Gmail account in Pipedream. 4. Design for re-auth flows: Build your app logic to handle cases where a trigger fails due to auth, so you can gracefully notify users or retry after re-auth. 5. Document and communicate: Let your users know that, for security reasons, Google may require them to periodically re-authenticate. — ### What happens if auth fails on a long-lived Gmail trigger? - User action is required: If the refresh token is invalid, the only way to restore connectivity is for the end user to re-authenticate (sign in to Gmail again via Pipedream). - No silent recovery: Pipedream cannot recover from a revoked/expired refresh token without user intervention. — ### Platform features to lean on - Error notifications: Use Pipedream’s built-in error notifications to alert you or your users when a workflow fails due to auth. - Re-authenticate in UI: Users can always reconnect their Gmail account in the Pipedream UI to restore access. - Component props: Use the gmail app prop in your components to ensure you’re using Pipedream’s managed OAuth flow. — ### Summary Table | Issue Type | Can Pipedream auto-recover? | User Action Needed? | |-------------------------------|:---------------------------:|:----------------------- | Access token expired | Yes | No | | Refresh token expired/revoked | No | Yes (re-authenticate) | | OAuth scopes changed | No | Yes (re-authenticate) | | Too many connections | No | Yes (re-authenticate) | — ### What should you do? - Design for re-auth: Always assume that, at some point, user re-authentication will be required for long-lived integrations. - Notify users: When a trigger fails due to auth, notify the user and provide instructions to reconnect their Gmail account in Pipedream. - Monitor workflows: Use Pipedream’s error monitoring to catch auth failures early. — If you need more help or want to discuss your specific setup, please visit Pipedream. Let me know if you need more technical details or code examples!
When retrieving accouns via the API, if the ‘dead’ parameter is true, then the user will definitely have to reconnect the account. This can happen for a number of reasons including access simply being revoked on the app’s side (whether by the user or by Google itself)
Hey We are on the Connect plan and use the Pipedream SDK to manage auth and workflow triggers for our users.
We ran into an issue with connected accounts and external triggers (sources) and wanted to confirm a couple of things:
What we observed:
A user’s connected Gmail account token became invalid (revoked / expired).
Once the account was dead, an external trigger (source) that was deployed using that account stopped sending webhook events entirely no error webhooks either. We had to go into the Pipedream source page manually to see the error.
The user then re-authenticated (created a new connected account). However, the existing deployed trigger still showed the old invalid token error on the source page. It did not pick up the new account automatically.
Questions:
When a connected account goes dead, is it correct that deployed triggers/sources using that account will not send any webhook events (not even error payloads)?
After a user re-authenticates (new account created), does the existing deployed trigger need to be deleted and re deployed with the new account’s authProvisionId? Or is there a way to update the trigger in place?
Is there a webhook or callback we can subscribe to for account health changes (healthy → dead), so we can proactively notify our users instead of discovering it when triggers go silent?
How does this healthy flag works? I mean what are the chances that healthy can be false but dead can be false??
This does not happen often, but we want to handle it gracefully for our users when it does. Any guidance would be appreciated.
Thanks!
That sounds very likely as there would be no events to be emitted;
I’m not able to verify right now, but you may be able to update the trigger’s auth prop (the one of type: “app”) with the new authProvisionId by calling the update component endpoint. If not, redeploying is best;
I don’t think we have this, though our team is aware of the need of better observability here;
I’ll verify this with the team to give you a concrete answer, but as far as I know, when the account is unhealthy but not dead, the auth process is still periodically retrying.
How long does Pipedream retry before marking an account dead? We run a sweep every 6 hours to sync health state. Want to make sure that’s frequent enough to catch accounts that go dead. Is there a rough timeframe for the healthy: false → dead: true transition?
We’re planning to use dead (not healthy) as the trigger for notifying our users to reconnect, since healthy: false might self-heal. Does that sound right to you, or are there cases where healthy: false lingers indefinitely without going dead (meaning the user would actually need to reconnect but dead never flips)?
| Access token expired | Yes | No | | Refresh token expired/revoked | No | Yes (re-authenticate) | | OAuth scopes changed | No | Yes (re-authenticate) | | Too many connections | No | Yes (re-authenticate) | — ### What should you do? - Design for re-auth: Always assume that, at some point, user re-authentication will be required for long-lived integrations. - Notify users: When a trigger fails due to auth, notify the user and provide instructions to reconnect their Gmail account in Pipedream. - Monitor workflows: Use Pipedream’s error monitoring to catch auth failures early. — If you need more help or want to discuss your specific setup, please visit