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

Handshake/WithHandshakeArgs4.RandomLoss/23 fail #4328

Open
1 of 4 tasks
ami-GS opened this issue May 29, 2024 · 6 comments
Open
1 of 4 tasks

Handshake/WithHandshakeArgs4.RandomLoss/23 fail #4328

ami-GS opened this issue May 29, 2024 · 6 comments
Milestone

Comments

@ami-GS
Copy link
Contributor

ami-GS commented May 29, 2024

Describe the bug

QUIC_CONNECTION_EVENT_SHUTDOWN_INITIATED_BY_TRANSPORT before checking Server->GetIsConnected()
Simply slow machine? then how to manage this.
Can we make idle timer longer for test?
https://github.com/microsoft/msquic/actions/runs/9281377624/job/25537479115?pr=4327

image

Affected OS

  • Windows
  • Linux
  • macOS
  • Other (specify below)

Additional OS information

No response

MsQuic version

main

Steps taken to reproduce bug

not repro locally

Expected behavior

pass

Actual outcome

D:\a\msquic\msquic\src\test\lib\HandshakeTest.cpp(323): error: Server->GetIsConnected() not true

Additional details

No response

@ami-GS
Copy link
Contributor Author

ami-GS commented May 30, 2024

OK, the timer is 10 sec which was set at 44. then expired at 54

06:50:44.810 [Microsoft-Quic][conn][0x243EF6A38B0] Setting TIMER.IDLE , delay=10000000 us

@ami-GS
Copy link
Contributor Author

ami-GS commented May 30, 2024

@nibanks

What's this? this says ignoring, but EventConnectionComplete is set which unblock the main thread then fail.
https://github.com/microsoft/msquic/blob/cd5019f2de4251d45cda8783055165c7d32be27c/src/test/lib/TestConnection.cpp#L816C1-L822C89

@ami-GS
Copy link
Contributor Author

ami-GS commented May 30, 2024

My idea are

  • make idle timeout longer
  • retry connection if it there is idle timeout

@nibanks
Copy link
Member

nibanks commented May 30, 2024

Random loss tests are hard. I don't know a way to guarantee they pass, because it's always theoretically possible (though rare) that all packets end up getting randomly dropped. Unless you have a good suggestion (I'll look at your PR), I think we just prioritize looking at other failed tests..... one idea, maybe we add retry support to our test scripts to retry test cases that fail?

@ami-GS
Copy link
Contributor Author

ami-GS commented May 31, 2024

how about retrying test from test.ps1 level?

@nibanks
Copy link
Member

nibanks commented May 31, 2024

how about retrying test from test.ps1 level?

Sure, give it a try?

@nibanks nibanks added this to the Future milestone Jun 6, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants