Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Webhook for Transactions (Jobs) Status #180

Closed
SiriusDely opened this issue Sep 6, 2021 · 5 comments · Fixed by #203
Closed

Webhook for Transactions (Jobs) Status #180

SiriusDely opened this issue Sep 6, 2021 · 5 comments · Fixed by #203

Comments

@SiriusDely
Copy link
Contributor

Wondering if there is a plan to add some kind of webhook functionality so that the interested parties can be updated for the status of transactions (jobs) or account creation status, instead of needing to poll the related HTTP API endpoints.

@nanuuki
Copy link
Contributor

nanuuki commented Sep 24, 2021

There's no timeline for this feature yet unfortunately. See related discussions in #155 :)

@latenssi
Copy link
Member

latenssi commented Nov 5, 2021

We are thinking about adding a webhook support for job status updates. This webhook would be configurable via env vars (as everything else) and would receive a POST request on job status updates. The POST request would contain the same information you can get by calling the GET /v1/jobs/:id endpoint as well as the Type of the job (transaction or account_create).

@SiriusDely
Copy link
Contributor Author

@latenssi , glad to hear this, thank you for planning to add this feature.

The requirement you've mentioned above seems to be perfect already.

One thing I'd like to add is to have some kind of retry mechanism with exponential backoff when the webhook was failed to be delivered (not getting back 2xx http status code as a response).

@latenssi
Copy link
Member

latenssi commented Nov 8, 2021

@SiriusDely Thank you for the feedback!

We will use the existing job scheduling infra for sending the notifications. This means if a webhook fails (error or status code != 200) the scheduler will try again in exactly 1 minute and retry a maximum of 10 times. I understand this is not ideal in a web environment but we don't want to implement a second scheduler just for webhooks. It would be ideal to have the job scheduler doing the exponential backoff some day so all the async jobs benefit from it.

@latenssi latenssi linked a pull request Nov 8, 2021 that will close this issue
@SiriusDely
Copy link
Contributor Author

sounds great @latenssi !

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants