Notify users of auto-disabled connections

[terencecho]

Tell us about the problem you're trying to solve

With the additional feature of adding an option to auto-disable failing connections from this issue, we want to clearly define how the notification of a connection being auto-disabled should be surfaced.

For example, do we want an email or a pop-up? Do we want to confirm that the user has acknowledged this automated disablement of a connection? etc.

[terencecho]

Got some feedback from Natalie:

When we turn off a connection, we should show a message in the application on the connection status page to let them know that we have proactively disabled the connection because of repeated failures, and encourage them to reach out to Support to help resolve the connection issue. When they enable the connection again (or change anything about the connector configuration), that message should go away.
I think email is the correct way to implement an alert. There should be two - a warning and a notification. The warning could happen at the 50% mark.
Warning: the connector is at risk of being turned off, due to repeated failures. They should reach out to Support or change their config
Notification: the connector has been turned off, future syncs will not happen, due to repeated failures

[cgardens]

we do not currently have a way to send emails to users as far as i'm aware. @davinchia am I wrong on this? do we have sendgrid set up somewhere?

[cgardens]

@terencecho if you take a look at NotificationClient, we have some stuff in place to push information to users. The idea here was that a user could plug in different types of notification clients. Right now we just support slack, but adding email makes sense (for cloud).

Sending emails from OSS is hard because it requires having the user set up a mail server or using ours (which is very dangerous). We should skip supporting it in OSS for now.

Based on Davin's response about our email setup, you could set up an email NotificationClient and we could use that to send this ifnormation.

[michel-tricot]

@nataliekwong should probably be involved in that conversation

[nataliekwong]

We can use customer.io as a way to send emails to Cloud users, as all Cloud users are already in customer.io today. I agree on not sending emails to OSS users. Here is what I sent Terence, in a follow-up message:

As far as implementation, the in-app message would need to be done within product. For the emails, we can use Segment to generate calls that trigger emails (we can use our email tool customer.io for the actual sending of the emails).

For the initial implementation, I suggest we send this as a transactional email as it's a product-triggered notification and should not be able to be opted out from. We could allow for opt-out of connector turnoff notifications in the future (as you suggested, a toggle in the UI), but to start it would be mandatory.

Outside of this particular issue, I have gotten a few requests for an email notification feature as users don't want to go through the hurdle of setting up a webhook. If we were to develop that feature, we could continue to use customer.io to send those emails, or move all product-triggered emails to Sendgrid. Ideally we consolidate so that we have clear delineations on what kinds of emails are being sent and from where.

[davinchia]

We do use Sendgrid today to send the new user invite and workspace invite emails. See https://github.com/airbytehq/airbyte-cloud/blob/master/cloud-server/src/main/java/io/airbyte/cloud/server/email/Sendgrid.java. Log in is in lastpass.

I don't have an opinion on customer.io vs Sendgrid.

[terencecho]

I don't have enough context to have an opinion between customer.io vs sendgrid. But I think it makes sense to create an email implementation of NotificationClient and link it to either customer.io or sendgrid, which could be re-used for other email notifications for the future.

[cgardens]

Let's use customer.io then. Better to consolidate towards a single tool. Sounds like we have a clear owner of customer.io and buy in from GTM. Sendgrid is a bit of an orphan in our stack right now.

[terencecho]

Going to leave this issue open until the feature flag is turned on in cloud

[terencecho]

This has been deployed to production as of 5/2/22.