-
WebSockets do get retried even if To reproduce:
You can observe the errors are logged but the test happily goes on.
|
Beta Was this translation helpful? Give feedback.
Replies: 5 comments
-
Hi, thanks for report. Could you please show the test that reproduces it? And if possible could you show which operation in the source code of the test triggered deadline and was retried? |
Beta Was this translation helpful? Give feedback.
-
Sure the test can be found here. The server code is here. What's unusual it that the traffic goes through a proxy and the proxy sets a 5s t/o (deadline now+5s). |
Beta Was this translation helpful? Give feedback.
-
Thanks. Sorry for stupid question, but could you point me where exactly do you observe a retry? From what I see you're using testing.T as Reporter, so failures are non-fatal (httpexpect will use t.Errorf), i.e. after failure test will continue, but will be marked as failed. And you continue sending messages in a loop disregarding of failures. After WriteText() fails in message 6, websocket marks itself as failed, and further calls to WriteText() from loop become no-op. Am I missing something? BTW if you need fatal failures, you can use httpexpect.NewRequireReporter. |
Beta Was this translation helpful? Give feedback.
-
Thanks for the detailed description. I double checked and indeed there is no retry. I was fooled by "websocket marks itself as failed, and further calls to WriteText() from loop become no-op". |
Beta Was this translation helpful? Give feedback.
-
Converted this to discussion.
Yep, all httpexpect methods work like this. If reporter does not interrupt test, after failure subsequent assertion on same or child objects become no-op. |
Beta Was this translation helpful? Give feedback.
Thanks for the detailed description. I double checked and indeed there is no retry. I was fooled by "websocket marks itself as failed, and further calls to WriteText() from loop become no-op".