This PR fixes 2 issues:

• A user sending invalid data in a UUID-based plugin should not result in a server error, but a client error with a 400 status code.
• Middlewares in Starlette should not raise Exceptions, they should abort the request cycle and send a response instead.

The exact error is customizable from user code, but provides a default 400 response with empty body. Implemented on both ContextMiddleware and RawContextMiddleware.

Sometimes it can be very useful to write tests for functions that rely on some data in the request context, but without using a full Starlette test client, as tests that are based on test clients are much less "lean" and do a lot of things beyond just running the code unit under test.

I think it would be very useful to document / add some helpers that enable a context manager that mocks a request / response cycle / middleware / etc. so it can be used in testing.

For now, I have done this in my tests (I'm using pytest fixtures, this is a very simplified example):

code under test

from starlette_context import context

def get_session_id():
    """Get the current session ID"""
    return context['session_id']

in conftest.py:

import pytest
from starlette_context import _request_scope_context_storage, context


@pytest.fixture()
def request_context():
    token = _request_scope_context_storage.set({})
    try:
        yield context
    finally:
        _request_scope_context_storage.reset(token)

in tests:

from myapp.session_utils import get_session_id 


def test_some_func_that_relies_on_context(request_context):
    request_context['session_id'] = 'foobar'
    assert get_session_id() == 'foobar'

Obviously, this is a bit hackish and it would be nice if there would be an official / documented way of doing this without accessing module internals.

I'm using your library right now in a FastAPI app, and since everything's heavily typed in FastAPI (and Pydantic), I have MyPy enabled and it's using quite a strict configuration. Right now, it's complaining about the imports from starlette_context:

Code:

from starlette_context import context
from starlette_context.plugins import Plugin, RequestIdPlugin

Error:

Skipping analyzing 'starlette_context': found module but no type hints or library stubs  [import]
Skipping analyzing 'starlette_context.plugins': found module but no type hints or library stubs  [import]
See https://mypy.readthedocs.io/en/latest/running_mypy.html#missing-imports

I can always just suppress the error with # type: ignore but I was wondering if you were planning on adding type hints or stub packages/files, as recommended by MyPy here: https://mypy.readthedocs.io/en/stable/running_mypy.html#missing-type-hints-for-third-party-library. I think that would be a better approach.

In case there's no plan for this yet, what would you say to a PR to add stub files? Basically, I think just adding the appropriate .pyi files next to each .py file would satisfy MyPy.

Here is a testcase:

>>> from starlette_context import context
>>> context
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/dmig/.pyenv/versions/3.8.2/lib/python3.8/collections/__init__.py", line 1014, in __repr__
    def __repr__(self): return repr(self.data)
  File "/home/dmig/.pyenv/versions/marty-services-3.8.2/lib/python3.8/site-packages/starlette_context/ctx.py", line 26, in data
    return _request_scope_context_storage.get()
LookupError: <ContextVar name='starlette_context' at 0x7f3b3be81c20>

Hi, i'm using Depend FastAPI mechaninsm to access Context on request-response cycle:

async def my_context_dependency(
    x_plt_session_id: str = Header(None),
    x_plt_correlation_id: str = Header(None),
    x_plt_user_id: str = Header(None),
    x_plt_event_id: str = Header(None),
    x_plt_solution_user: str = Header(None),
) -> Any:
    # When used a Depends(), this fucntion get the `X-Client_ID` header,
    # which will be documented as a required header by FastAPI.
    # use `x_client_id: str = Header(None)` for an optional header.

    data = {
        "session-id": x_plt_session_id,
        "correlation-id": x_plt_correlation_id,
        "user-id": x_plt_user_id,
        "event-id": x_plt_event_id,
        "solution-user": x_plt_solution_user,
    }
    with request_cycle_context(data):
        # yield allows it to pass along to the rest of the request
        yield

app = FastAPI(
        dependencies=[Depends(my_context_dependency)],
        title="Virtual Entity API",
        description="This is a very fancy project, with auto docs for the API and everything",
        version="0.0.1",
        openapi_url="/openapi.json"
    )

I'm also using custom exception handler in FastAPI:

from starlette_context import context

@app.exception_handler(AWSException)
async def unicorn_exception_handler(
    request: Request, exc: AWSException
) -> JSONResponse:

   user_id = context.get("user-id", default=None)
    
    print(user_id )

    return JSONResponse(
        status_code=400,
        content={"message": exc.message},
    )

But when i try to access context inside the custom exception handler i receive :

starlette_context.errors.ContextDoesNotExistError: You didn't use the required middleware or you're trying to access context object outside of the request-response cycle.

Any hints ?

This creates and exposes a context manager that instantiates and resets the Token.

This isn't much actual code, it may look like it only slightly improves the code reuse of the token initialization/reset code, but exposing it while abstracting the internal details allows 2 more important use cases:

• within unit tests, creating a mock environment to test a portion using the context out of a request-response cycle (helping for #46).
• leveraging FastAPI framework Depends() to allow required/optional headers to be visibly documented, plus use the full scope of FastAPI features (such as easy access to the request's body within a Depends system, (as #50 shown might be a use case).

This also introduces the first explicit support of FastAPI, which, while limited, may attract more attention to the library.

Since there are issues in Starlette caused by BaseHTTPMiddleware class, this package becomes a source of these issues in any project using it:

• https://github.com/encode/starlette/issues/919
• https://github.com/encode/starlette/issues/1012

The simple solution would be to rewrite the middleware to pure ASGI.

When using PluginUUIDBase's force_new_uuid option and setting it to True I'm always getting the same uuid. Which is the opposite of what I expect.

It looks like when self.value is None a new uuid is generated, and this works fine when for the first request. But subsequent request seem to be using the same id.

I suspect the code that needs to be fixed is missing a self.value = None before trying anything else here: https://github.com/tomwojcik/starlette-context/blob/2f80262bbf4c00fb501c22ac04a5c1c408187fe6/starlette_context/plugins/plugin_uuid.py#L34

Issue

When a route raises an exception and so returns a 500 Internal Server Error, x-request-id and x-correlation-id are not set.

The culprit seems to be https://github.com/tomwojcik/starlette-context/blob/79aa8ffe5b50db2263e2073fc5d252bf442f150c/starlette_context/middleware.py#L46-L52

This is similar to this comment - https://github.com/tiangolo/fastapi/issues/397#issuecomment-543136587

Expectation I'd expect those headers to be set for all responses. One benefit of correlation ids is when there are errors, we can use the ids to track down the issue.

Steps to reproduce Sample. The "/" endpoint returns the x-request-id and x-correlation-id headers. The "/error" does not.

from starlette.applications import Starlette
from starlette.middleware import Middleware
from starlette.requests import Request
from starlette.responses import JSONResponse

import uvicorn
from starlette_context import context, plugins
from starlette_context.middleware import ContextMiddleware

middleware = [
    Middleware(
        ContextMiddleware,
        plugins=(plugins.RequestIdPlugin(), plugins.CorrelationIdPlugin()),
    )
]

app = Starlette(debug=True, middleware=middleware)


@app.route("/")
async def index(request: Request):
    return JSONResponse(context.data)

@app.route("/error")
async def index(request: Request):
    raise RuntimeError()
    return JSONResponse(context.data)

uvicorn.run(app, host="0.0.0.0")

Hi!

I am quite new to Starlette and FastAPI, and I might have holes in my knowledge, however I was not able to write a new plugin.

from fastapi import FastAPI
from fastapi.middleware import Middleware

from starlette_context.header_keys import HeaderKeys
from starlette_context.plugins import Plugin

class LangPlugin(Plugin):
    print('****')

middleware = [
    Middleware(
        RawContextMiddleware,
        plugins(
            LangPlugin()
        )
    )
]

app = FastAPI(middleware=middleware)

And it says:

  File ".../starlette_context/middleware/raw_middleware.py", line 17, in __init__
    if not all([isinstance(plugin, Plugin) for plugin in self.plugins]):
TypeError: 'LangPlugin' object is not iterable

How is my plugin not instance of Plugin, I wonder. Or I guess this is the problem.

To put you into context, I would like to get from here an optional string param, (/path-to-api-endpoint/?lang=en) to access the request language from everywhere. Or maybe you have a more straightforward solution to my problem, what I did not recognize?

Thank you for this middleware!

I want to use it for adding request IDs in the logs of third-party libraries that I do not have control over. Since most libraries might use a logger instead of LoggerAdapter, I am wondering if there is a way to log request IDs without the use LoggerAdapter(like in the example given in this repo).

@hhamana I tested your PR. It works fine. I'm worried about regressions where context is not cleared though.

I'd like to add a test where the client is spamming asgi app with requests. In the meantime, half of them fails. If we can check if response headers are correct after that, it should prove there are no regressions in real world apps with huge traffic.

The only thing left is to figure out why await asyncio.sleep is not working.

The pyproject.toml we use is currently only for black config. While that's fine and all, pyproject.toml is originally intended to define the build system, and replace setup.cfg, which itself is already supposed to be a safer alternative to the setup.py As build system, using the status quo default setuptools is fine for us. But we have to be explicit about it. Latest updates to pip issue a DeprecatedWarning to systems still using setup.py or setup.cfg to define project metadata.

recommended reading:

• https://snarky.ca/what-the-heck-is-pyproject-toml/
• https://setuptools.pypa.io/en/latest/userguide/pyproject_config.html

Closes https://github.com/tomwojcik/starlette-context/issues/58

• starlette errors are returned as PlainTextResponse, so lets do that https://github.com/encode/starlette/blob/389cbfcaa529686bfd4cfab0bfa338a531a389c8/starlette/exceptions.py#L103
• add support for server / client errors. Server errors always return 500. Client errors 4xx with a meaningful message.
• client errors will now return the error message in the response
• drop support for error_response. You said > sending a response object through the exception is weird, but I can't see any other way to make it work nicely with plugins. but I believe changes from this implementation will do the trick.

Not sure if I was doing something wrong but it seems like the library could provide more useful logging. For instance I was passing non valid UUID's as the X-Request-ID and in this case all the logging I saw on my server was:

127.0.0.1:51990 - "POST /graphql/ HTTP/1.1" 400

Some descriptive log message would help.

I like ContextMiddleware because it's very simple to understand and expand, even for minds that are not familiar with async Python.

Some time ago it was advised https://github.com/tomwojcik/starlette-context/issues/18 to add RawContextMiddleware and Starlette maintainers were discouraging the use of the built-in middleware. I was surprised to see 3 ❤️ reactions under this issue so I think a few people had problems with it.

Fast-forward almost a year, the issue https://github.com/encode/starlette/issues/1012#issuecomment-866622798 with memory usage has been closed.

If there's no point in keeping both, I'd be happy to remove the more complicated one but I will wait for some confirmations from the community. If there's a case when it makes sense to use RawContextMiddleware, then I'd keep both.

What's your opinion about that? @hhamana @dmig-alarstudios