Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
[v2] disperser client payments api #928
[v2] disperser client payments api #928
Changes from 5 commits
9982bf1
5004cf9
dd00e32
0d59ee9
cd908e1
6643ca9
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
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 feels too coupled to me. A Public setter that is not part of the interface and it set by some response from another client. As discussed in other threads, could we not combine accountant and disperser_client more smoothly? Does accountant really need to be an independent struct?
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.
We wanted to keep accounting flow separate from the client, but arguably we can combine them into a bigger struct. What do you think @ian-shim ?
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 think this would improve the UX quite a bit. You cannot disperse a blob without payment metadata and you probably don't need accountant functionality other than for the purpose of dispersing a blob, so coupling them more explicitly makes sense imo
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.
Makes sense! I would also not try to future-proof this design too much (to a case where there are multiple dispersers and you need some super complex accountant that manages multiple dispersers). We should try to make the simple case simple, true to golang's philosophy, and people who need complex integrations can take on the complexity hit around our simple API.
Another possibility is to have 2 constructors: one where we inject the accountant, and the other that initializes the accountant by calling the disperser?
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.
Hmm all one needs to do is to call the current constructor and then call
PopulateAccountant
, so adding a separate constructor doesn't seem that beneficial to me. I won't mind adding it, probably in the follow-up PR that focus on integrations adaptions (maybe something likeNewDisperserClientV2AutoPay
?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.
how about we make the call to PopulateAccountant as part of the initOnce function? This way its hidden from the user.
Is there ever a need to recall PopulateAccountant? For eg if disperser went down, or whatever other weird case? To reset the accountant basically? If so, should it be called
ResetAccountantFromServer
or something like that?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.
In this case, maybe we also move signer check to the initOnce?
There's some cases a user might recall populate accountant, I don't think it hurts to be able to reset. Can update the function name for sure
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 think I'll leave this as a future refactoring
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.
check if
c.accountant
is nil?we can instruct how to initialize accountant in the error message