issue_comments

@simonw do you think it is still worth populating the endpoint key in the scope as originally intended by this issue, or should we hold off until a decision about possibly using an X-Endpoint header instead? :smile:

Oh yes well spotted thank you 😁

I agree that the strictness would be nice as it could help to avoid different middleware altering the scope in incompatible ways. However I do also agree that it's likely for not all implementations to follow 🤔

Right now the spec does say “copy the scope, rather than mutate it” https://asgi.readthedocs.io/en/latest/specs/main.html#middleware

I wouldn’t be surprised if that there’s room for discussion on evolving the exact language there.

There’s obvs a nice element to the strictness there, tho practically I’m not sure it’s something that implementations will follow, and its not something that Starlette chooses to abide by.

The asgi spec doesn't explicitly specify (at least as far as I can tell) whether the scope is immutable/mutable https://asgi.readthedocs.io/en/latest/specs/lifespan.html#scope . @simonw using a header for this would be a nice approach. It would also potentially increase the portability of any middleware/plugins/clients across different applications/frameworks as it's not tied directly to an asgi implementation

The middleware implementation there works okay with a router nested inside if the scope is mutated. (Ie. "endpoint" doesn't need to exist at the point that the middleware starts running, but if it has been made available by the time an exception is thrown, then it can be used.)

Starlette's usage of "endpoint" there is unilateral, rather than something I've discussed against the ASGI spec - certainly it's important for any monitoring ASGI middleware to be able to have some kind of visibility onto some limited subset of routing information, and "endpoint" in the scope referencing some routed-to callable seemed general enough to be useful.

Ok great, getting the __qualname__ to be TableView and adding endpoint to the scope in AsgiRouter is simple enough (already done). However, (unless I'm missing a plugin hook or something) the suggestion of utilising it within a datasette-sentry plugin may not work. The only hook that would have access to the scope is the asgi_wrapper hook. But as this wraps the existing asgi app, the endpoint won't yet have been added to the scope received by the hook https://github.com/SteadBytes/datasette/blob/107d47567dedd472eebec7f35bc34f5b58285ba8/datasette/app.py#L672 . However, I'm not sure where else the endpoint could be added to the asgi scope :thinking:

It looks as if the datasette.utils.AsgiRouter.__call__ is the place to add this https://github.com/simonw/datasette/blob/90d4f497f9b3f6a5882937c91fddb496ac3e7368/datasette/utils/asgi.py#L101 .

The sentry_asgi middleware uses the __qualname__ or __name__ attributes of the endpoint https://github.com/encode/sentry-asgi/blob/c6a42d44d31f85885b79e4ee898683ecf8104971/sentry_asgi/middleware.py#L84

Looking at the Starlette implementation endpoint is a Callable https://github.com/encode/starlette/commit/34d0097feb6f057bd050d5057df5a2f96b97384e#diff-34fba745b50527bfb4245d02afd59246R100 which as far as I can tell is analogous to the view function which is matched here https://github.com/simonw/datasette/blob/90d4f497f9b3f6a5882937c91fddb496ac3e7368/datasette/utils/asgi.py#L96 .

A slight issue is that __qualname__ is matched first in the sentry_asgi middleware, and __name__ is used if that doesn't exist. I think (please correct me if I am wrong) that for datasette, the __name__ is what should be used. For example, when using the development fixtures and hitting http://127.0.0.1:8001/fixtures/compound_three_primary_keys the view function that is matched gives:

```python

view.qualname 'AsgiView.as_asgi.<locals>.view' view.name 'TableView' ```

Would TableView be the desired value here? Or am I looking in entirely the wrong place? :smile: