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

Huobi: V2 subscription support #1703

Open
wants to merge 20 commits into
base: master
Choose a base branch
from

Conversation

gbjk
Copy link
Collaborator

@gbjk gbjk commented Nov 6, 2024

  • Removes deprecated and non-functional WS endpoints
  • Adds V2 endpoints available as described here ( Account updates, Order updates, Trades )
  • Mock tests for Private subscriptions
  • Improves code structure for wsHandleData
  • Assertifies tests
  • Quite a few test fixes as well
  • Adds testexch.FixtureToDataHandlerWithErrors

Stacked Dependencies

Related

Type of change

Please delete options that are not relevant and add an x in [] as item is complete.

  • Bug fix (non-breaking change which fixes an issue)

How has this been tested

  • go test ./... -race
  • golangci-lint run

@gbjk gbjk self-assigned this Nov 6, 2024
@thrasher- thrasher- requested review from shazbert, gloriousCode and thrasher- and removed request for shazbert and gloriousCode November 6, 2024 22:29
@thrasher- thrasher- added review me This pull request is ready for review nomerge requires dependency This pull request is dependent on another, so it can't be merged until the dependent one is merged labels Nov 6, 2024
@gbjk gbjk added reconstructing Based on PR feedback, this is currently being reworked and is not to be merged review me This pull request is ready for review and removed review me This pull request is ready for review reconstructing Based on PR feedback, this is currently being reworked and is not to be merged labels Nov 7, 2024
@gbjk gbjk force-pushed the feature/huobi_v2 branch 3 times, most recently from 06c750a to 8d0146d Compare November 11, 2024 03:44
@gbjk gbjk removed the nomerge requires dependency This pull request is dependent on another, so it can't be merged until the dependent one is merged label Nov 11, 2024
@gbjk gbjk force-pushed the feature/huobi_v2 branch from 8d0146d to 2f10c4b Compare December 2, 2024 00:41
@gbjk
Copy link
Collaborator Author

gbjk commented Dec 2, 2024

Linter fixed; Rebased to resolve conflict

@gbjk gbjk force-pushed the feature/huobi_v2 branch from 2f10c4b to b88173c Compare December 2, 2024 01:14
Copy link
Collaborator

@shazbert shazbert left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Awesome update. 🍰 Just some minor nits.

exchanges/huobi/huobi_websocket.go Show resolved Hide resolved
exchanges/huobi/huobi_test.go Outdated Show resolved Hide resolved
exchanges/huobi/huobi_websocket.go Outdated Show resolved Hide resolved
exchanges/huobi/huobi_websocket.go Outdated Show resolved Hide resolved
exchanges/huobi/huobi_websocket.go Show resolved Hide resolved
exchanges/huobi/huobi_websocket.go Show resolved Hide resolved
exchanges/huobi/huobi_websocket.go Outdated Show resolved Hide resolved
exchanges/huobi/huobi_websocket.go Show resolved Hide resolved
exchanges/huobi/huobi_websocket.go Outdated Show resolved Hide resolved
Copy link
Collaborator

@shazbert shazbert left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice work! Thanks for addressing my initial nits, just one left over issue then looks good to go, good stuff! 🚀

exchanges/huobi/huobi_websocket.go Outdated Show resolved Hide resolved
@gbjk gbjk requested a review from shazbert December 17, 2024 01:53
Copy link
Collaborator

@shazbert shazbert left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🕊️ Last thing from me, I hope 🙏

exchanges/huobi/huobi_wrapper.go Show resolved Hide resolved
Copy link
Collaborator

@shazbert shazbert left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

unauth tACK unauth utACK. Thanks!

Copy link
Collaborator

@shazbert shazbert left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Per-instance future codes not getting cached causin occassional fails
@gbjk
Copy link
Collaborator Author

gbjk commented Dec 18, 2024

Whoops tests broke

This has been an transient test failure for ages, impervious to introspection.
Think I finally cracked it with:

Fixed gbjk@52dfbfd8f

but running long -count=100 -race again to be (somewhat) sure.

@gbjk
Copy link
Collaborator Author

gbjk commented Dec 18, 2024

CI failures all have 5 or 6 failures for just Coinbase and/or test server.
All clean for Huobi.

Also nothing locally for hundreds of runs.

@gbjk gbjk requested a review from shazbert December 18, 2024 02:55
Copy link
Collaborator

@shazbert shazbert left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Changes ACK, Thanks 🫡

@shazbert shazbert added the szrc shazbert review complete label Dec 19, 2024
Copy link
Collaborator

@gloriousCode gloriousCode left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nicely done

exchanges/huobi/huobi_test.go Outdated Show resolved Hide resolved
exchanges/huobi/huobi_test.go Outdated Show resolved Hide resolved
exchanges/huobi/huobi_test.go Show resolved Hide resolved
exchanges/huobi/huobi_test.go Show resolved Hide resolved
exchanges/huobi/huobi_websocket.go Show resolved Hide resolved
Comment on lines +94 to +95
h.Websocket.SetCanUseAuthenticatedEndpoints(false)
if h.IsWebsocketAuthenticationSupported() {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

?
I don't see any other exchange behave in this manner

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In which sense?
Most of them use SetCanUseAuthenticatedEndpoints false on failure (Kraken, Okx)
Many of them use IsWebsocketAuthenticationSupported to choose to dial auth (Kraken, Okx)

This is using a different pattern, but I'm actually happier with it.
Set CanUseAuthEndpoints to false on a (re)connect, and then true if the auth succeeds.
It feels cleaner than having the branching logic we've seen elsewhere.
Definitely cleaner than using CanUseAuthenticatedEndpoints to decide to even dial, which I saw on one exchange, and feels definitely wrong.

Is there a downside to this that I'm missing?

If anything, I'd follow this pattern with others when I'm interfering with them.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why set something to false when you don't even know if they have credentials set or if its going to be used?
If you put the h.Websocket.SetCanUseAuthenticatedEndpoints(false) inside the if statement, it no longer looks out of place and that change will still work with all the reasoning you outlined

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why set something to false when you don't even know if they have credentials set or if its going to be used?
Because if we aren't about to go into the if statement, for any reason at all, then false is the correct state for the value. Not setting it to false seems wrong to me; Doing it inside an if statement that could be false and not run seems wrong to me.

I don't know what the use-cases might be. Feels like the user would have to unset credentials for it to need to be set to false where I have it. But that's kind of irrelevant. My point is that it's the best representation of the state at the right time.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Kinda afraid you're going to ask me to change all the others if I convince you 🤦

Comment on lines 121 to 129
for _, op := range []string{wsSubOp, wsUnsubOp} {
key := op + "bed" // subbed, unsubbed
if ch, err := jsonparser.GetString(respRaw, key); err == nil {
if !h.Websocket.Match.IncomingWithData(op+":"+ch, respRaw) {
return fmt.Errorf("%w: %s:%s", stream.ErrNoMessageListener, op, ch)
}
return nil
}
}
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Perhaps there's something I've missed, but I don't see the point to this loop when you have a handler for it that performs the same function below. It also doesn't force every single message on the ws into a loop - costing about 90ns per message

case wsSubOp, wsUnsubOp:
			return h.wsHandleV2subResp(action, respRaw)

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's the V1 sub support, so the section you highlighted isn't relevant.
However it's also entirely superfluous because the id is in there and it's working, so ... remove this section and everything is still fine.

Fixed gbjk@6938c5573

@gbjk gbjk requested a review from gloriousCode January 11, 2025 06:09
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
review me This pull request is ready for review szrc shazbert review complete
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants