Strange error, can't figure out what is causing it

[0xSwego]

I am using Litestar, that uses argon2-cffi to hash passwords.
It usually works fine, but when I try to access the environment in the morning, I get a strange error (Threading failure), maybe related to threading issues.

It might reflect something else that is wrong with my system. Can you give some ideas?

exception raised on http connection to route /api/access/login
Traceback (most recent call last):
During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/opt/venv/lib/python3.11/site-packages/litestar/middleware/exceptions/middleware.py", line 192, in __call__
    await self.app(scope, receive, send)
  File "/opt/venv/lib/python3.11/site-packages/litestar/routes/http.py", line 82, in handle
    response = await self._get_response_for_request(
               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/opt/venv/lib/python3.11/site-packages/litestar/routes/http.py", line 134, in _get_response_for_request
    return await self._call_handler_function(
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/opt/venv/lib/python3.11/site-packages/litestar/routes/http.py", line 154, in _call_handler_function
    response_data, cleanup_group = await self._get_response_data(
                                   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/opt/venv/lib/python3.11/site-packages/litestar/routes/http.py", line 198, in _get_response_data
    async with cleanup_group:
  File "/opt/venv/lib/python3.11/site-packages/litestar/_kwargs/cleanup.py", line 102, in __aexit__
    await self.throw(exc_val)
  File "/opt/venv/lib/python3.11/site-packages/litestar/_kwargs/cleanup.py", line 113, in throw
    await gen.athrow(exc)
  File "/app/src/app/domain/users/dependencies.py", line 37, in provides_user_service
    yield service
  File "/opt/venv/lib/python3.11/site-packages/litestar/routes/http.py", line 202, in _get_response_data
    else await route_handler.fn(**parsed_kwargs)
         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/app/src/app/domain/users/controllers/access.py", line 85, in login
    user = await users_service.authenticate(obj.email, obj.password)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/app/src/app/domain/users/services.py", line 41, in authenticate
    if not await crypt.verify_password(password, db_obj.hashed_password):
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/app/src/app/lib/crypt.py", line 58, in verify_password
    valid, _ = await asyncio.get_running_loop().run_in_executor(
               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/root/.nix-profile/lib/python3.11/concurrent/futures/thread.py", line 58, in run
    result = self.fn(*self.args, **self.kwargs)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/opt/venv/lib/python3.11/site-packages/passlib/context.py", line 2433, in verify_and_update
    if not record.verify(secret, hash, **clean_kwds):
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/opt/venv/lib/python3.11/site-packages/passlib/handlers/argon2.py", line 670, in verify
    return cls.verify(secret, hash)
           ^^^^^^^^^^^^^^^^^^^^^^^^
  File "/opt/venv/lib/python3.11/site-packages/passlib/handlers/argon2.py", line 779, in verify
    raise cls._adapt_backend_error(err, hash=hash)
          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/opt/venv/lib/python3.11/site-packages/passlib/handlers/argon2.py", line 645, in _adapt_backend_error
    raise exc.MalformedHashError(cls, reason=reason)
ValueError: malformed argon2 hash (argon2_cffi reported: Threading failure: hash=b\'$argon2id$v=19$m=65536,t=3,p=4$7P2/V8qZsxaCUOq9t1YqJQ$XieRN/W6l5kz8kMktYNy111vuaGQZsGjbRVPYaW1W4k\')

[hynek]

We've had a similar problem in #53 which turned out to be a lack of memory.

argon2 is a memory-hard hash, so double-check if you've got enough. By default (and in your hash if I'm squinting correctly), argon2-cffi uses 64 MB.

[0xSwego]

Thanks for your comment. I discovered that Litestar had a memory leak, that caused a huge number of threads to get spawned. I'll report the issue there.