| 1 | | Okay, this is expected behavior and not a bug. I propose to remove this restriction for middleware when you have to handle sync and async cases separately. Because the middleware often does not contain any I/O |
| | 1 | Okay, this is expected behavior and not a bug. I propose to remove this restriction for middleware when you have to handle sync and async cases separately. Because the middleware often does not contain any I/O. |
| | 2 | |
| | 3 | Because the check is really redundant. We do know whether the next middleware is async-capable from its definition. |
| | 4 | |
| | 5 | This is a weird API. The user has to return sync or async function based on the type of the next middleware function. Well, python is duck-typed, you cannot rely on types |