Consider making the IdP Link and Unlink webhooks transactional

[glen-84]

Consider making the IdP Link and Unlink webhooks transactional

Description

Is there any reason why these hooks are non-transactional? If you want to sync the data to an external system, a failure would result in missing data in the external system.

Use case:

Storing link data in our database, in case we want to switch back to an in-house solution later. I suppose this data would also be available in exports, so it's not critical, but I think that it might make more sense for them to be transactional.

Have you considered making the transactionality (not a word) a flag/setting per hook? (a checkbox [x] Transactional)

• [Category] Webhooks #1543

Community guidelines

All issues filed in this repository must abide by the FusionAuth community guidelines.

[robotdan]

Is there any reason why these hooks are non-transactional?

In theory we could make these transactional. The link can be completed via API, or as the result of the completion of an OAuth2 grant - so failing it due to a webhook failure may be confusing to the user and difficult to communicate why we could not complete the authentication request.

We could consider it - additional latency is always bad in these authentication flows so the UX could suffer. In general any time you make a webhook transactional it is "buyer beware" in that adding more latency in general makes for a bad user experience and poor system performance. So if that is the only reason, perhaps we could revisit this decision.

Have you considered making the transactionality (not a word) a flag/setting per hook? (a checkbox [x] Transactional)

I think you are saying webhooks may not all have equal importance, and I may choose to say I need an event to be received by Webhook A in order to continue, but Webhook B could fail and it is ok. So you could then mark the event as required (or transactional) per webhook, and then when FusionAuth decides if the event was successful (enough to continue) we would take into account each success or failure (per webhook) and only consider failures from those that indicated they want that event to be required (transactional)

Is that roughly what you are asking?

[glen-84]

so failing it due to a webhook failure may be confusing to the user and difficult to communicate why we could not complete the authentication request

Sounds like #1725.

Is that roughly what you are asking?

This was quite a while ago. I may have meant an option per webhook type, and not per webhook instance. Per instance might be even better though. But yes, whether a webhook is transactional or not depends on the use case.

Note that I am no longer with the company that are using FusionAuth, so this issue is no longer important to me.