Closed HuidaeCho closed 2 years ago
I'm getting the same error when trying to make a little FastAPI service, but a CLI tool running the exact same code works reliably. It seems to me that there is clearly some global state pollution here. I haven't tracked it down yet, but I do find it odd that the internals of pymyq freely intermix calls to async with ClientSession() as websession
with just accepting a websession
parameter; in the absence of any countervailing explanation my current hypothesis is that somewhere the parameter is accidentally used as the contextmanager instead.
Here's the problem:
Specifically:
devices: dict = {}
This means you get one dictionary for the entire process, shared between every MyQAccount
process.
I'll send a PR.
This SO question is related.
I have two versions of almost the same code: (1) one using Bottle as a uWSGI web app, (2) another as a command line utility. The web app only works the first time after it's loaded and it fails with a "Session is closed" error thereafter. It reports the door state as "opening" or "closing" when the door is fully open or closed already. The command line program reports the correct state and works every time without any issues.
The web app used to work fine with pymyq 3.0.3 before I updated pymyq to 3.1.4 this morning.
I tested the same code with pymyq 3.0.3 again. Well, it works now again.
This is the core part of the app:
Actually, pymyq 3.0.3 also seems to raise the same "Session is closed" exception at
login()
, but Task exception was never retrieved (not sure what it means and what it's for). With pymyq 3.1.4, the same exception is raised whendoor.close()
is called.With pymyq 3.1.4:
With pymyq 3.0.3: