Document the events that trigger each webhook

[mooreds]

Sometimes we do this, sometimes we don't. See https://fusionauth.io/docs/v1/tech/events-webhooks/events/jwt-refresh#jwt-refresh for an example where we do not.

[bryanlandia]

@jaywood128 @mooreds It's also unclear the order of firing of events and where the transaction boundaries are.

Could you provide or point to some documentation of order of firing, and where the boundaries of transactions/database writes are ? For example, it appears when I fire a webhook on registration.create and try to access the User that the registration is being created for, I get a 404, presumably because the registration is inside the user-creation transaction as well, and the User is not yet persisted.

My use case in particular involves a SAML IdP, so understanding the whole flow of events in between login start for Application > pass to IdP > create user on IdP > SAML retuirned back to FA > create user in FA > create App registration in FA > continue flow into Application

[mooreds]

@bryanlandia we have some stuff here: https://fusionauth.io/docs/v1/tech/events-webhooks/writing-a-webhook#calling-fusionauth-apis-in-webhooks

I'd love to document this fully, but need to work with the engineering team to know what is an invariant that we can publicly document and what is an implementation detail.

To be honest, I don't see this doc being written out before q3.

[bryanlandia]

Thanks @mooreds I understand on timeline. I had seen that doc you linked.

My specific need/frustration is around timing of the registration.create and user.create events. I created a webhook on registration.create before continuing the SAML IdP > OAuth Application flow as I need to update the User's username before continuing. The registration.create webhook requires the User to exist to access it via API, but it appears that user.create and registration.create are in the same Transaction, at least when using an IdP, so I just get 404s and the whole flow errors out with a Webhook Transaction Error (io.fusionauth.api.service.event.WebhookTransactionException) in the "wrapping" step which seems to be the SAML v2 Reconcile Lambda. The events passed to the Webhooks have all the User data, including user.data props set via SAML Reconcile but apparently the User is not actually persisted. I've even added sleep and retry loops on the User API call and they don't help.. I can wait 10 seconds and I still get 404s on the User.

Are you able to at least confirm whether user.create and registration.create are wrapped in the same Transaction code? If not, then I think there is actually a bug with persistence of the User to storage (this is hosted FA) and event flow.

[mooreds]

Without doing some digging, I can't answer your question.

Have you considered using the user.create.complete event or a reconcile lambda to modify the username?

Anyway, this has veered into support, so we should continue this in the forum (or on a support ticket if you have a plan with engineering support).

I do appreciate you adding your use case and re-upping this documentation request.