I think there might be a misunderstanding here. This error message is emitted by Sanic-Plugins-Framework, not Sanic-CORS. And seeing this message is certainly not “expected behavior”. It is a sign that something went wrong, that is why an error is thrown. Are you able to link to any discussion topics where it is implied that it is expected behavior?
Sanic-Plugins-Framework has a mechanism to detect if incoming requests are entering the application before the Sanic server has started. At that time, the sanic application, its routes, and its middleware are in an “undefined” state. Only after the Sanic server emits a “server_started” event, should requests be processed. If a request was allowed through before that, invalid results could be produced.
Sanic-Plugins-Framework listens for the “server_started” event, and uses that to disable this error message after the server starts.
This mechanism can be fragile, here are some times it has failed:
- When using Sanic in ASGI Mode, the server emits an “after_server_start” event, but never a “before_server_start” event, which confuses SPF. This was fixed in SPF in 0.8.2 in Aug 2019.
- When using the test-client within sanic to execute async requests against a non-running sanic server. This was fixed in 0.9.3 in July 2020
- When manually executing an async server instance created using app.create_server(), and similar circumstances more recently here. This never emits any “server_start” event, so breaks SPF (and other plugins) on startup. There are workarounds here and here.
In each of these situations, the error message is/was not expected behavior, and steps were taken to prevent it from happening.
Are you able to give us more details about your application and method of executing Sanic? With more information we might be able to get to the bottom of this together.
I think there is a small chance, under very high load, a race condition may cause this error to be thrown for few requests at startup. There would be a period of between 1 and 10 milliseconds after the server starts up, but before SPF starts to allow requests through. If you have very high load, in the order of hundreds of requests per second on your application before it starts up, then one or two might make it through before requests are allowed.
Does that correspond with what you are seeing?