-
Notifications
You must be signed in to change notification settings - Fork 1
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
tss: Webhook handler service #44
Conversation
adding semicolons
…ransaction_hash ...also remove outgoing/incoming_status and have one status column
commit fb807aa Author: gouthamp-stellar <[email protected]> Date: Tue Sep 3 10:28:49 2024 -0700 remove the index on try_transaction_xdr and add column/index on try_transaction_hash ...also remove outgoing/incoming_status and have one status column commit 6fc0dc2 Author: gouthamp-stellar <[email protected]> Date: Tue Sep 3 08:58:46 2024 -0700 missing , commit a9cf4e3 Author: gouthamp-stellar <[email protected]> Date: Tue Sep 3 01:55:23 2024 -0700 make hash primary key instead of xdr commit c0f9d32 Author: gouthamp-stellar <[email protected]> Date: Fri Aug 30 15:18:27 2024 -0700 moving all migrations to one file commit 2de9898 Author: gouthamp-stellar <[email protected]> Date: Fri Aug 30 15:16:53 2024 -0700 adding semicolons adding semicolons commit 373c71a Author: gouthamp-stellar <[email protected]> Date: Fri Aug 30 15:12:24 2024 -0700 update commit 3f9f9f0 Author: gouthamp-stellar <[email protected]> Date: Fri Aug 30 15:12:00 2024 -0700 remove empty lines commit 9920f48 Author: gouthamp-stellar <[email protected]> Date: Fri Aug 30 15:06:40 2024 -0700 TSS tables and the channel interface commit a58d519 Author: gouthamp-stellar <[email protected]> Date: Fri Aug 30 10:55:22 2024 -0700 tables and interfaces for TSS
…and builds a transaction out of it
cmd/utils/tss_options.go
Outdated
func WebhookHandlerServiceChannelMinWaitBtwnRetriesMSOption(configKey *int) *config.ConfigOption { | ||
return &config.ConfigOption{ | ||
Name: "webhook-service-channel-min-wait-between-retries", | ||
Usage: "The minumum amout of time to wait before repining the webhook url", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this in seconds
, right?
Usage: "The minumum amout of time to wait before repining the webhook url", | |
Usage: "The minimum amount of time to wait before resending the request to the webhook url", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Corrected this typo. As for wait times, typically from what I've seen, and done in the past, in exponential backoff implementations is a wait time in the order of milliseconds so I'm doing the same here. Also we have to remember that this is being done inside a task in a thread pool, which typically should not be long running, so milliseconds seems appropriate to me
} | ||
var i int | ||
for i = 0; i < p.MaxRetries; i++ { | ||
resp, err := p.HTTPClient.Post(payload.WebhookURL, "application/json", bytes.NewBuffer(jsonData)) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Here we are just sending the data as a JSON body payload to the webhook URL, right? There's no authentication nor any custom header.
I'm imagining here that maybe we should support some kind of Signature
header, to add a security layer in the communication between the wallet-backend
and the customer application.
What do you think?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I actually do like the idea of adding a security layer, but want to give it some more thought. I'm working on a doc for tss v2 ideas and I'll make sure to add this to it. I think that we should be ok not having auth for now because customer applications will deploy their own wallet backends so there's some inherent trust there already
response := tss.TSSResponse{} | ||
response.TransactionHash = payload.TransactionHash | ||
if payload.RpcSubmitTxResponse.Status.Status() != "" { | ||
response.Status = string(payload.RpcSubmitTxResponse.Status.Status()) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This .Status()
method already returns a string, so you don't need to parse it here
response.Status = string(payload.RpcSubmitTxResponse.Status.Status()) | |
response.Status = payload.RpcSubmitTxResponse.Status.Status() |
MaxRetries: cfg.MaxRetries, | ||
MinWaitBtwnRetriesMS: cfg.MinWaitBtwnRetriesMS, | ||
} | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
func WebhookHandlerServiceChannelMaxBufferSizeOption(configKey *int) *config.ConfigOption { | ||
return &config.ConfigOption{ | ||
Name: "webhook-service-channel-max-buffer-size", | ||
Usage: "Set the buffer size of the webhook serive channel.", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Usage: "Set the buffer size of the webhook serive channel.", | |
Usage: "Set the buffer size of the webhook service channel.", |
func WebhookHandlerServiceChannelMaxWorkersOptions(configKey *int) *config.ConfigOption { | ||
return &config.ConfigOption{ | ||
Name: "webhook-service-channel-max-workers", | ||
Usage: "Set the max number of workers for the webhook serive channel.", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Usage: "Set the max number of workers for the webhook serive channel.", | |
Usage: "Set the max number of workers for the webhook service channel.", |
func WebhookHandlerServiceChannelMinWaitBtwnRetriesMSOption(configKey *int) *config.ConfigOption { | ||
return &config.ConfigOption{ | ||
Name: "webhook-service-channel-min-wait-between-retries", | ||
Usage: "The minumum amout of time to wait before resending the payload to the webhook url", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Usage: "The minumum amout of time to wait before resending the payload to the webhook url", | |
Usage: "The minimum amount of time (in milliseconds) to wait before resending the payload to the webhook url", |
utils.WebhookHandlerServiceChannelMaxWorkersOptions(&cfg.WebhookHandlerServiceChannelMaxWorkers), | ||
utils.WebhookHandlerServiceChannelMaxRetriesOption(&cfg.WebhookHandlerServiceChannelMaxRetries), | ||
utils.WebhookHandlerServiceChannelMinWaitBtwnRetriesMSOption(&cfg.WebhookHandlerServiceChannelMinWaitBtwnRetriesMS), | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
}) | ||
} | ||
|
||
func (p *webhookPool) Receive(payload tss.Payload) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we add a test to validate this method errors? I see that you have a test that covers the "happy path", just wondering here if it's nice do validate these errors too
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just approved, just left a few comments about some improvements that are nice to have, imo :)
What
This is TSS's Webhook Handler Service as described in this doc:
https://docs.google.com/document/d/1xcX86-w8lwT_60flCuYBK9X9co-108-5X6D9e5epw0U/edit#heading=h.76emp0zcbvdy
Why
This service is responsible for sending completed transactions to the client
Known limitations
N/A
Issue that this PR addresses
https://app.asana.com/0/1207947010297920/1208138733594326
Checklist
PR Structure
all
if the changes are broad or impact many packages.Thoroughness
Release