Open wjt opened 2 months ago
Stylistically I think it was incorrect to make an assertion about user-supplied data: assertions are to catch logic errors in the checker itself. But nonetheless it is the case that assertions are used liberally in the various checkers,
Indeed, assertions in cases such as this one are used in place of proper input checks and should be replaced, probably with schema-based validation (I believe the number of capture groups in a regex can be checked with an extended python-jsonschema validator).
so it's a problem that the asyncio mainloop would hang in this situation.
And this is kinda weird. Are there some specific cases when AssertionError isn't propagated to the main loop? Or anywhere in a coroutine will cause it to hang?
In #418, @tobiasmicheler figured out that the checker was hanging while checking https://github.com/flathub/com.modrinth.ModrinthApp/blob/1d954cc7c91841d020fe4c860593789a16ca62c6/com.modrinth.ModrinthApp.yml#L108. This is because prior to 1a0e0c76449a20344584644cca69c6c61d494af2,
gitchecker.GitChecker._check_has_new
asserted that the (user-supplied) regular expression contained exactly one match group.Stylistically I think it was incorrect to make an assertion about user-supplied data: assertions are to catch logic errors in the checker itself. But nonetheless it is the case that assertions are used liberally in the various checkers, so it's a problem that the asyncio mainloop would hang in this situation.
The symptom is that once the assertion is raised, the program hangs; if you interrupt it with
Ctrl+C
you get the following backtrace:A bit of printf debugging shows that the gitchecker for another module is executing the async function
git_ls_remote
at the point of the hang. If I remove that module, the assertion bubbles up to the top level correctly.