-
Notifications
You must be signed in to change notification settings - Fork 81
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
Failing TestWSClientNonBlockingEvents
#3005
Labels
Milestone
Comments
AnnaShaleva
added a commit
that referenced
this issue
Aug 29, 2023
The race is probably caused by the fact that accessing receivers list of WSClient under rlock requires some time. Technically, it may be helpful to increase timeouts for the receivers checking operation, but we can add one more condition to ensure that at least maximum number of messages was received by the buffered receiver. This test can't be reproduced on my machine, thus I'd suggest to keep an eye on it in GH workflows for some time. Close #3005. Signed-off-by: Anna Shaleva <[email protected]>
AnnaShaleva
added a commit
that referenced
this issue
Aug 29, 2023
The race is probably caused by the fact that accessing receivers list of WSClient under rlock requires some time. Technically, it may be helpful to increase timeouts for the receivers checking operation, but we can add one more condition to ensure that at least maximum number of messages was received by the buffered receiver. This test can't be reproduced on my machine, thus I'd suggest to keep an eye on it in GH workflows for some time. Close #3005. Signed-off-by: Anna Shaleva <[email protected]>
AnnaShaleva
added a commit
that referenced
this issue
Aug 30, 2023
The race is probably caused by the fact that accessing receivers list of WSClient under rlock requires some time. Technically, it may be helpful to increase timeouts for the receivers checking operation, but we can add one more condition to ensure that at least maximum number of messages was received by the buffered receiver. This test can't be reproduced on my machine, thus I'd suggest to keep an eye on it in GH workflows for some time. Close #3005. Signed-off-by: Anna Shaleva <[email protected]>
AnnaShaleva
added a commit
that referenced
this issue
Aug 30, 2023
The race is probably caused by the fact that accessing receivers list of WSClient under rlock requires some time. Technically, it may be helpful to increase timeouts for the receivers checking operation, but we can add one more condition to ensure that at least maximum number of messages was received by the buffered receiver. This test can't be reproduced on my machine, thus I'd suggest to keep an eye on it in GH workflows for some time. Close #3005. Signed-off-by: Anna Shaleva <[email protected]>
AnnaShaleva
added a commit
that referenced
this issue
Aug 30, 2023
The race is probably caused by the fact that accessing receivers list of WSClient under rlock requires some time. Technically, it may be helpful to increase timeouts for the receivers checking operation, but we can add one more condition to ensure that at least maximum number of messages was received by the buffered receiver. This test can't be reproduced on my machine, thus I'd suggest to keep an eye on it in GH workflows for some time. Close #3005. Signed-off-by: Anna Shaleva <[email protected]>
AnnaShaleva
added a commit
that referenced
this issue
Aug 30, 2023
The race is probably caused by the fact that accessing receivers list of WSClient under rlock requires some time. Technically, it may be helpful to increase timeouts for the receivers checking operation, but we can add one more condition to ensure that at least maximum number of messages was received by the buffered receiver. This test can't be reproduced on my machine, thus I'd suggest to keep an eye on it in GH workflows for some time. Close #3005. Signed-off-by: Anna Shaleva <[email protected]>
AnnaShaleva
added a commit
that referenced
this issue
Aug 30, 2023
The race is probably caused by the fact that accessing receivers list of WSClient under rlock requires some time. Technically, it may be helpful to increase timeouts for the receivers checking operation, but we can add one more condition to ensure that at least maximum number of messages was received by the buffered receiver. This test can't be reproduced on my machine, thus I'd suggest to keep an eye on it in GH workflows for some time. Close #3005. Signed-off-by: Anna Shaleva <[email protected]>
AnnaShaleva
added a commit
that referenced
this issue
Aug 30, 2023
The race is probably caused by the fact that accessing receivers list of WSClient under rlock requires some time. Technically, it may be helpful to increase timeouts for the receivers checking operation, but we can add one more condition to ensure that at least maximum number of messages was received by the buffered receiver. This test can't be reproduced on my machine, thus I'd suggest to keep an eye on it in GH workflows for some time. Close #3005. Signed-off-by: Anna Shaleva <[email protected]>
AliceInHunterland
added a commit
that referenced
this issue
Mar 6, 2024
Add waiting for startSending to ensure that the client is ready before the server starts sending messages. Close #3005 Signed-off-by: Ekaterina Pavlova <[email protected]>
AliceInHunterland
added a commit
that referenced
this issue
Mar 6, 2024
Add waiting for startSending to ensure that the client is ready before the server starts sending messages. Close #3005 Signed-off-by: Ekaterina Pavlova <[email protected]>
AliceInHunterland
added a commit
that referenced
this issue
Mar 6, 2024
Add waiting for startSending to ensure that the client is ready before the server starts sending messages. Close #3005 Signed-off-by: Ekaterina Pavlova <[email protected]>
AliceInHunterland
added a commit
that referenced
this issue
Mar 7, 2024
Add waiting for startSending to ensure that the client is ready before the server starts sending messages. Close #3005 Signed-off-by: Ekaterina Pavlova <[email protected]>
AliceInHunterland
added a commit
that referenced
this issue
Mar 11, 2024
Add waiting for startSending to ensure that the client is ready before the server starts sending messages. Close #3005 Signed-off-by: Ekaterina Pavlova <[email protected]>
AliceInHunterland
added a commit
that referenced
this issue
Mar 13, 2024
Add waiting for startSending to ensure that the client is ready before the server starts sending messages. Close #3005 Close #3312 Signed-off-by: Ekaterina Pavlova <[email protected]>
AliceInHunterland
added a commit
that referenced
this issue
Mar 13, 2024
Add waiting for startSending to ensure that the client is ready before the server starts sending messages. Close #3005 Close #3312 Signed-off-by: Ekaterina Pavlova <[email protected]>
AliceInHunterland
added a commit
that referenced
this issue
Mar 13, 2024
Add waiting for startSending to ensure that the client is ready before the server starts sending messages. Close #3005 Close #3312 Signed-off-by: Ekaterina Pavlova <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Ubuntu, go 1.19. Firstly discovered at https://github.com/nspcc-dev/neo-go/actions/runs/4883739029/jobs/8715507458?pr=3004.
The text was updated successfully, but these errors were encountered: