Kraken Refinement

[iamzoltan]

To address issues that did not fit into the scope of PR #214 and tick off the remaining desired functionality from #201

1. [ ] Get trades history asynchronously using nursery and the count:

• not sure we need this yet since realistically we'll be incrementally capturing trades data in the new ledger system. if we get to the point where user's are complaining about ledger loading on first boot, this might be something worth revisiting.

2. [x] ~Change the dict merging for trades to the new syntax: https://github.com/pikers/piker/pull/214/files#r830525470~ this code was all rewritten thus obsoleting this change request
3. [x] Get rid of the try except block in the positions calc: https://github.com/pikers/piker/pull/214/files#r830527334
4. [x] ~Change fixtures to accept kwargs: https://github.com/pikers/piker/pull/214/files#r817211683~ instead just expect funtools.partial()-ing in of needed state.

---

Further follow up TODOs (added by @goodboy):

• [x] ~we should probably use one of their batch cancel endpoints in our Client.submit_cancel()~ such that cc and other automated strats can destroy order sets faster. -> turns out using the WS api makes this all fast enough to avoid needing the batch cancels (for now)
  • [x] the other thing to investigate is whether the ws order entry API doesn't have these same issues with throttling (which one would assume since it's not an extra http request per request). -> it doesn't

[goodboy]

The one last bit was figuring out the source of latency in order cancellation. I got a feeling it's possibly one of 2 things:

• their api is putting a speed bump (would be odd though)
• there's a trio.sleep(1) somewhere that isn't needed in our client

further, we should probably use one of their batch cancel endpoints in our Client.submit_cancel() such that cc and other automated strats can destroy order sets faster.

the other thing to investigate is whether the ws order entry API doesn't have these same issues with throttling (which one would assume since it's not an extra http request per request).

[iamzoltan]

yea, the batch cancel endpoint I believe is the same as the single cancel one, only you pass in a list. when we use the cc command in piker, do we get all the cancels separately? or do they also come in a batch?

[goodboy]

I've updated the issue descr with the new issues i found and probably have addressed / solved by now.

[iamzoltan]

has all this been taking care of in the new branch?

[goodboy]

Initially completed in https://github.com/pikers/piker/pull/349 and there were a bunch of follow up patches to resolve various issues; see our PR history.