Stack trace:
ERROR: Exception in ASGI application
Traceback (most recent call last):
File "/opt/venv/.venv/lib/python3.11/site-packages/uvicorn/protocols/http/httptools_impl.py", line 404, in run_asgi
result = await app( # type: ignore[func-returns-value]
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/opt/venv/.venv/lib/python3.11/site-packages/uvicorn/middleware/proxy_headers.py", line 78, in __call__
return await self.app(scope, receive, send)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/opt/venv/.venv/lib/python3.11/site-packages/fastapi/applications.py", line 269, in __call__
await super().__call__(scope, receive, send)
File "/opt/venv/.venv/lib/python3.11/site-packages/starlette/applications.py", line 124, in __call__
await self.middleware_stack(scope, receive, send)
File "/opt/venv/.venv/lib/python3.11/site-packages/starlette/middleware/errors.py", line 184, in __call__
raise exc
File "/opt/venv/.venv/lib/python3.11/site-packages/starlette/middleware/errors.py", line 162, in __call__
await self.app(scope, receive, _send)
File "/opt/venv/.venv/lib/python3.11/site-packages/uvicorn/middleware/proxy_headers.py", line 78, in __call__
return await self.app(scope, receive, send)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/app/app/main.py", line 176, in __call__
await self.app(scope, receive, send_wrapper) # type: ignore
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/opt/venv/.venv/lib/python3.11/site-packages/starlette/exceptions.py", line 93, in __call__
raise exc
File "/opt/venv/.venv/lib/python3.11/site-packages/starlette/exceptions.py", line 82, in __call__
await self.app(scope, receive, sender)
File "/usr/local/lib/python3.11/contextlib.py", line 222, in __aexit__
await self.gen.athrow(typ, value, traceback)
File "/app/app/database.py", line 33, in get_db_session
yield session
File "/opt/venv/.venv/lib/python3.11/site-packages/fastapi/middleware/asyncexitstack.py", line 21, in __call__
raise e
File "/opt/venv/.venv/lib/python3.11/site-packages/fastapi/middleware/asyncexitstack.py", line 18, in __call__
await self.app(scope, receive, send)
File "/opt/venv/.venv/lib/python3.11/site-packages/starlette/routing.py", line 670, in __call__
await route.handle(scope, receive, send)
File "/opt/venv/.venv/lib/python3.11/site-packages/starlette/routing.py", line 266, in handle
await self.app(scope, receive, send)
File "/opt/venv/.venv/lib/python3.11/site-packages/starlette/routing.py", line 65, in app
response = await func(request)
^^^^^^^^^^^^^^^^^^^
File "/opt/venv/.venv/lib/python3.11/site-packages/fastapi/routing.py", line 227, in app
raw_response = await run_endpoint_function(
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/opt/venv/.venv/lib/python3.11/site-packages/fastapi/routing.py", line 160, in run_endpoint_function
return await dependant.call(**values)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/app/app/admin.py", line 192, in admin_new
mentioned_actor = await fetch_actor(db_session, tag["href"])
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/app/app/actor.py", line 271, in fetch_actor
ap_actor = await ap.fetch(actor_id)
^^^^^^^^^^^^^^^^^^^^^^^^
File "/app/app/activitypub.py", line 199, in fetch
raise ObjectUnavailableError(url, resp)
To reproduce: attempt to start a reply to a post by someone whose instance uses whitelisting and you aren't on the whitelist, apparently?
Per the user's other profile at https://mstdn.social/@binarytango: "Main account over at @binarytango. If you can't see it, let me know and I'll whitelist the instance you're on."
For reference, trying to start such a reply from my other fediverse account - on a server that is also apparently not whitelisted - instead omits that actor from the @'s. This gave me the idea of just wrapping a try around the attempt to add each mentioned actor, which appears to yield that same result.
I don't think any of the files in the stach trace are ones I've modified yet, so hopefully the line numbers are useful.
Doggone it, I said that wrong. This was technically an attempt to reply to a post that mentioned the unavailable profile, not one of that actor's posts, but I suspect the result would be the same, since either way my server would try to look him up and fail.
Hey,
It's a bird hard to reproduce for me, as I can fetch this profile without issues on all of my instances. But it does make sense to omit the @ in this case, I've pushed a fix that should introduce this behavior.
When creating a new post with "invalid actor", it should also already fail gracefully.
Let me know if the latest commit fixes your issue, or please share the updated traceback.
Thanks!
I almost replied without double-checking, because you did it almost exactly the same way I tried. (logging whose lookup failed is an improvement over my quick fix.) But yes, verified this prevents the error. Thanks!