gmail connection is limited by expiration of oauth token

Creating a gmail connection requires adding an OAuth Client ID to the gmail API and registering syndesis accordingly (documented in the user guide). Publishing an integration involving gmail works as expected. However, subsequent republishings of the same integration or using the connection for other integrations frequently results in the published integration failing due to ‘401 unauthorized errors’.

The workaround is to remove the OAuth Client ID in the gmail API, recreate it and re-register the integration. The gmail documentation actually states:

This access token is passed to the Gmail API to grant your application access to user data for a limited time.

Is it possible that the token is quickly expiring and requires refreshing? If so, Is it possible to refresh the token automatically or lengthen the expiry time?

[TovaCohen]

Thanks Zoran and Paul. We have time to get the 7.2 release notes text exactly right. I created this FUSEDOC issue to make sure it gets done: https://issues.jboss.org/browse/FUSEDOC-2869.

For 7.1, I’ll add the following today, and publish it on the customer portal unless I hear otherwise. @gaughan can you confirm that I should do this?

I will the following note here: [https://access.redhat.com/documentation/en-us/red_hat_fuse/7.1/html/release_notes/onlinedistrib#OnlineDistrib-Important] (Important Notes).

Published integrations that connect to Gmail stop executing when their Gmail API access token expires. To enable the integration to execute, re-register your Fuse Online environment as a Gmail API client and enter the new client ID and secret ID in the Fuse Online Settings page. (and that would be a link to the instructions for doing that) In the next release, it is expected that Fuse Online will obtain a new access token when needed and you will not need to re-register.

[phantomjinx]

@zregvart

I can confirm from my experience that deleting the oauth credentials in the google API console and creating new ones was sufficient. (As long as the new credentials were applied as I described above)