-
Notifications
You must be signed in to change notification settings - Fork 761
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
WebsocketApp does not identify callback arguments correctly on 0.51.0 #467
Comments
I'm seeing the same thing going from 0.50.0 to 0.51.0:
This is from
as it was in 0.50.0 seems to fix the issue. I'm not familiar enough with this code to understand what the |
@liris These folks are correct, somehow the revert from #463 missed the thing that actually needed to be reverted, which is this: It did revert my pull request #462 though which means 0.51.0 is equally as broken as 0.49.0 :( |
Seems like this was fixed in 0.52.0 a few days ago? At least I'm not getting the issue any more. |
As @friday says - 0.52.0 sorted this. Closing this one now. |
I have the same problem in version 0.55.0. My workaround:
|
0.56.0 still has the issue. any clue anyone here? @liris |
0.57.0 still possess the error |
The problem is here
because which is a use case for @MRSharff One way to work around this is to force your function to be a lambda instead of a function so that it misses the
But I don't think this is the intention. @MRSharff is it possible to change your use case to be
which could be done and allow us to simplify the function here https://github.com/websocket-client/websocket-client/blob/master/websocket/_app.py#L343 |
@liris can you comment on desired use of library as well? |
@cjds I believe I was incorrect in my original understanding of the code when I wrote my comments on #471 and now I'm not sure I have enough insight to comment. Though, this quick little mockup seems to work fine:
|
The issue 463 referenced that version 0.49.0 seemed to break callback arguments. Version 0.51.0 was released with a reverse of 442 to fix this.
I've tried this version with the certstream library and the issue is still there as far as I can gather. If I revert to version 0.48.0 it all works again. For my own usage I'm quite happy to use requirements.txt to make sure that version 0.48.0 is used but this might cause issues for others as well?
I use the following example from the Certstream README to replicate the issue.
Here are some examples of the errors that are being reported:
I'm not sure if this is caused by the certstream library using some deprecated functionality that's been removed or what's going on?
The text was updated successfully, but these errors were encountered: