@@ -27,7 +27,7 @@ def macos_raise_ulimit():
2727
2828# There is a relatively low time limit for the server to respond with a resource error
2929# for this test. In resource limited environments such as CI, it doesn't seem to be enough,
30- # notably it is the first request that will take the longest to process as it also sets up
30+ # notably it is the first message that will take the longest to process as it also sets up
3131# the request. We can consider raising this delay in the runner to see if it helps.
3232#
3333# https://github.com/connectrpc/conformance/blob/main/internal/app/connectconformance/testsuites/data/server_message_size.yaml#L46
@@ -37,24 +37,24 @@ def macos_raise_ulimit():
3737]
3838
3939
40- @pytest .mark .parametrize ("server" , ["granian" , "gunicorn" , "hypercorn" ])
40+ @pytest .mark .parametrize ("server" , ["granian" , "gunicorn" , "hypercorn" , "pyvoy" ])
4141def test_server_sync (server : str ) -> None :
42+ if server == "pyvoy" and sys .platform == "win32" :
43+ pytest .skip ("pyvoy not supported on Windows" )
44+
4245 args = maybe_patch_args_with_debug (
4346 [sys .executable , _server_py_path , "--mode" , "sync" , "--server" , server ]
4447 )
45- opts = [
46- # While Hypercorn and Granian supports HTTP/2 and WSGI, they both have simple wrappers
47- # that reads the entire request body before running the application, which does not work for
48- # full duplex. There are no other popular WSGI servers that support HTTP/2, so in practice
49- # it cannot be supported. It is possible in theory following hyper-h2's example code in
50- # https://python-hyper.org/projects/hyper-h2/en/stable/wsgi-example.html though.
51- "--skip" ,
52- "**/bidi-stream/full-duplex/**" ,
53- ]
48+ opts = []
5449 match server :
5550 case "granian" | "hypercorn" :
56- # granian and hypercorn seem to have issues with concurrency
57- opts += ["--parallel" , "1" ]
51+ opts += [
52+ # While Hypercorn and Granian supports HTTP/2 and WSGI, they both have simple wrappers
53+ # that reads the entire request body before running the application, which does not work for
54+ # full duplex.
55+ "--skip" ,
56+ "**/bidi-stream/full-duplex/**" ,
57+ ]
5858 case "gunicorn" :
5959 # gunicorn doesn't support HTTP/2
6060 opts = ["--skip" , "**/HTTPVersion:2/**" ]
@@ -78,17 +78,16 @@ def test_server_sync(server: str) -> None:
7878 check = False ,
7979 )
8080 if result .returncode != 0 :
81- if server == "granian" :
82- # Even with low parallelism, some tests are flaky. We'll need to investigate further.
83- print ( # noqa: T201
84- f"Granian server tests failed, see output below, not treating as failure:\n { result .stdout } \n { result .stderr } "
85- )
86- return
8781 pytest .fail (f"\n { result .stdout } \n { result .stderr } " )
8882
8983
90- @pytest .mark .parametrize ("server" , ["daphne" , "granian" , "hypercorn" , "uvicorn" ])
84+ @pytest .mark .parametrize (
85+ "server" , ["daphne" , "granian" , "hypercorn" , "pyvoy" , "uvicorn" ]
86+ )
9187def test_server_async (server : str ) -> None :
88+ if server == "pyvoy" and sys .platform == "win32" :
89+ pytest .skip ("pyvoy not supported on Windows" )
90+
9291 args = maybe_patch_args_with_debug (
9392 [sys .executable , _server_py_path , "--mode" , "async" , "--server" , server ]
9493 )
@@ -104,9 +103,6 @@ def test_server_async(server: str) -> None:
104103 "--skip" ,
105104 "**/full-duplex/**" ,
106105 ]
107- case "granian" | "hypercorn" :
108- # granian and hypercorn seem to have issues with concurrency
109- opts = ["--parallel" , "1" ]
110106 case "uvicorn" :
111107 # uvicorn doesn't support HTTP/2
112108 opts = ["--skip" , "**/HTTPVersion:2/**" ]
@@ -115,6 +111,7 @@ def test_server_async(server: str) -> None:
115111 "go" ,
116112 "run" ,
117113 f"connectrpc.com/conformance/cmd/connectconformance@{ VERSION_CONFORMANCE } " ,
114+ "-v" ,
118115 "--conf" ,
119116 _config_path ,
120117 "--mode" ,
@@ -129,10 +126,4 @@ def test_server_async(server: str) -> None:
129126 check = False ,
130127 )
131128 if result .returncode != 0 :
132- if server == "granian" :
133- # Even with low parallelism, some tests are flaky. We'll need to investigate further.
134- print ( # noqa: T201
135- f"Granian server tests failed, see output below, not treating as failure:\n { result .stdout } \n { result .stderr } "
136- )
137- return
138129 pytest .fail (f"\n { result .stdout } \n { result .stderr } " )
0 commit comments