Closed nexy7574 closed 1 month ago
Upon further investigation, it does appear to be errors being raised in Nio event callbacks. After wrapping the entire callback in a try/except, I can catch the error and log it.
However, this does imply the library is doing something to capture and swallow the error.
It does appear to be the try/finally - throwing in a try/except/finally
properly re-raises the captured error. May be worth implementing.
Cannot reproduce this anymore.
Describe the bug According to logs, the
finally
clause of NioBot.run is being executed, despite my bot not being told to exit.To Reproduce The bug appears to be related to this code - https://github.com/nexy7574/philip/blob/6c9a20396ceb80f2230c3e8f6864a3a20e347bd0/modules/discord_bridge.py#L655-L667
This is what I get in my logs when this code executes:
This is strange, because there should be at least one more DEBUG statement from the avatar resolution code, yet there isn't?
At first, I thought somehow python was confusing
httpx.AsyncClient
closing after exiting a context manager. But after further debugging, the discord account binds should not be able to be printed if this were the case. I suspect that somehow, thetry/finally
is swallowing errors. But wait, try/finally should just propagate the error? More accurately, I believe the error is being swallowed elsewhere, with the try/finally being nothing more than a symptom. However, I am unsure where.Expected behavior Any exceptions that are raised in callbacks (even if not owned by us) should at the very least log the exception, ideally be captured an not bubble up far enough to crash the process.
Tracebacks (if applicable) Contextually, unavailable. However, these are my logs after commenting out the avatar code blocks:
and the rest of the code executes successfully.
Additional context