-
Notifications
You must be signed in to change notification settings - Fork 822
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
base: master
Are you sure you want to change the base?
Conversation
06c750a
to
8d0146d
Compare
8d0146d
to
2f10c4b
Compare
Linter fixed; Rebased to resolve conflict |
2f10c4b
to
b88173c
Compare
b88173c
to
ac7b14a
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.
Awesome update. 🍰 Just some minor nits.
ff199aa
to
479095c
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.
Nice work! Thanks for addressing my initial nits, just one left over issue then looks good to go, good stuff! 🚀
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.
🕊️ Last thing from me, I hope 🙏
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.
unauth tACK unauth utACK. Thanks!
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.
Per-instance future codes not getting cached causin occassional fails
This has been an transient test failure for ages, impervious to introspection. Fixed gbjk@52dfbfd8f but running long |
CI failures all have 5 or 6 failures for just Coinbase and/or test server. Also nothing locally for hundreds of runs. |
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.
Changes ACK, Thanks 🫡
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.
Nicely done
h.Websocket.SetCanUseAuthenticatedEndpoints(false) | ||
if h.IsWebsocketAuthenticationSupported() { |
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 don't see any other exchange behave in this manner
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 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.
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.
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
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.
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 theif
statement, for any reason at all, thenfalse
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.
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.
Kinda afraid you're going to ask me to change all the others if I convince you 🤦
exchanges/huobi/huobi_websocket.go
Outdated
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 | ||
} | ||
} |
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.
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)
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.
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
testexch.FixtureToDataHandlerWithErrors
Stacked Dependencies
Related
Type of change
Please delete options that are not relevant and add an
x
in[]
as item is complete.How has this been tested