-
Notifications
You must be signed in to change notification settings - Fork 631
Conversation
e300523
to
ae68910
Compare
a59ebf8
to
23aec43
Compare
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.
LGTM 👍
Conflicts come from the split recently done between the legacy wallet and the new one. |
- Format message as JSend, include retry information - Use the API error mechanism so it can be caught more easily on client side - Add to sample, test
This function allows you to uniformly add an error handler to each endpoint of the WalletClient type. This will be used in an upcoming commit to provide the throttling retry logic.
This should prevent the failures from throttling to occur in integration testing until we can have file-level configuration of the integration test.
9b848b6
to
a4b14e8
Compare
Okay, I squashed a bunch of stuff together while rebasing and resolving conflicts. Maaaaaaan, that was something. We really need to work on our git practices 😢 ... Also, I've made one slight change instead of solving 18 times the same conflict. I've defined a higher abstraction -- | Natural transformation + mapping on a 'WalletClient'
natMapClient
:: (forall x. m x -> n x)
-> (forall x. n (Either ClientError x) -> n (Either ClientError x))
-> WalletClient m
-> WalletClient n
natMapClient phi f wc = WalletClient
{ getAddressIndexPaginated =
\x -> f . phi . getAddressIndexPaginated wc x
-- ... etc
-- | Run the given natural transformation over the 'WalletClient'.
hoistClient :: (forall x. m x -> n x) -> WalletClient m -> WalletClient n
hoistClient phi =
natMapClient phi id
-- | Generalize a @'WalletClient' 'IO'@ into a @('MonadIO' m) =>
-- 'WalletClient' m@.
liftClient :: MonadIO m => WalletClient IO -> WalletClient m
liftClient = hoistClient liftIO
mapClientErrors :: forall m. Monad m => ResponseErrorHandler m -> WalletClient m -> WalletClient m
mapClientErrors handler =
natMapClient id overError |
@disassembler @cleverca22 This can most probably be left as |
70665d7
to
3d2e22b
Compare
3d2e22b
to
549e5be
Compare
🙄 👀 |
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.
Looks good to me.
I am a bit worried that the defaults are not right compared to V0 (althought its hard to tell because we didn't benchmark it)
@@ -12,6 +12,13 @@ | |||
each slot in an epoch) to an epoch/index file pair. Consolidation happens on-the-fly in a | |||
background process. | |||
|
|||
- #### Add bouncing and throttling to the API | |||
Previously, exchanges could accidentally overload their wallet servers. We |
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.
there was a throttling in v0 per handler https://github.com/input-output-hk/cardano-sl/blob/develop/wallet/src/Pos/Wallet/Web/Methods/Payment.hs#L80
# # Number of requests per throttling period. | ||
# rate: 200 | ||
# # Amount of microseconds in a throttling period. | ||
# period: 1_000_000 |
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.
https://github.com/input-output-hk/cardano-sl/blob/develop/wallet/src/Pos/Wallet/Web/Methods/Payment.hs#L80 note that we have "throttled" 6 seconds here - which is 6 times more then here. I know new data layer is probably more optimized then the old one - but maybe we should measure or check why did we pick 6 in v0. I know it was due to sev1 performance problem
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.
Note that this is actually quite a bit faster -- we have rate
requests per period
microseconds, so 200 requests permitted per second in this configuration, across the board. It is disabled entirely by default.
More fine-grained throttling can easily be done at the handler level, I 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.
so 200 requests permitted per second in this configuration
yes - we just have to check eventually is our wallet layer up to the task. I am not sure have we run benchmarks on new wallet layer and compared it to the old one
defaultThrottleSettings :: ThrottleSettings | ||
defaultThrottleSettings = ThrottleSettings | ||
{ tsRate = 30 | ||
, tsPeriod = 1000000 |
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.
06d8c0f
to
7d541a4
Compare
@parsonsmatt |
@akegalj I merged because there are configuration changes that were nightmarish to deal with along with other work that's going on in the wallet. Target that PR against |
Description
This PR adds throttling capability to the Wallet API as well as the ability to load the configuration from the file.
Note: This requires the
configuration.yaml
file be modified to include thewallet
section. We should figure out how that affects clients.Linked issue
https://iohk.myjetbrains.com/youtrack/issue/CBR-179
Type of change
Developer checklist
Testing checklist
I have not added new tests for this feature. The sort of test we could implement to verify throttling works is to spam the server with a bunch of requests and verify that some of them are
429
. However, the test-suite for the library already does this, so we'd be replicating the work.Existing tests already catch parsing the config format.
QA Steps
Screenshots (if available)