Response x-api-version header is from request when using waterfalling

[slafs]

Describe the bug

The comment from

cadwyn/cadwyn/middleware.py

Lines 127 to 128 in ca3f3a1

	# We return it because we will be returning the **matched** version, not the requested one.
	# In date-based versioning with waterfalling, it makes sense.

doesn't seem to be true. The x-api-version header in the response seems to have the same value as the one in the request, not the closest matched version determined by "waterfalling".

To Reproduce

This test (app.py):

from cadwyn import Cadwyn, Version, VersionBundle, VersionedAPIRouter

versions = VersionBundle(Version("2023-04-14"), Version("2022-11-16"))

app = Cadwyn(
    versions=versions,
)

router = VersionedAPIRouter()


@router.get("/foo")
def foo():
    return "foo"


app.generate_and_include_versioned_routers(router)


def test_param():
    from fastapi.testclient import TestClient

    client = TestClient(app, headers={"x-api-version": "2024-01-01"})

    res = client.get("/foo")

    assert res.json() == "foo"
    assert res.headers["x-api-version"] == "2023-04-14"

when run like this:

uvx --with 'cadwyn[standard]' pytest app.py

fails.

Expected behavior

As per linked comment, I'd expect the version header value to be 2023-04-14 when I passed 2024-01-01 in the request.

Additional context

Looks like this never worked (? 🤔). The earliest version I can test with this snippet is 4.3.

[zmievsa]

Thanks for posting! I'll look into it!

[csemanish12]

I tested this and found same issue. I can try and fix it. @zmievsa

[zmievsa]

Sounds great, @csemanish12 !

[csemanish12]

This is what i found so far:

In Middleware

• BEFORE invoking the call_next method, api_version_var is set to version from request header

In routing.py

• api_version_var is set to matched version

in Middleware

• AFTER return from call_next method, api_version_var is still from request header. The change made in routing.py did not persist. mostly likely due to different contexts.

Possible solution:

1. store matched version in asgi scope in routing.py and fetch it inside middleware

routing.py

    async def __call__(self, scope: Scope, receive: Receive, send: Send) -> None:
        if "router" not in scope:  # pragma: no cover
            scope["router"] = self

        if scope["type"] == "lifespan":
            await self.lifespan(scope, receive, send)
            return
        version = self.api_version_var.get(None)
        default_version_that_was_picked = DEFAULT_API_VERSION_VAR.get(None)

        # if version is None, then it's an unversioned request and we need to use the unversioned routes
        # if there will be a value, we search for the most suitable version
        if not version:
            routes = self.unversioned_routes
        elif version in self.versioned_routers:
            routes = self.versioned_routers[version].routes
        else:
            routes = await self._get_routes_from_closest_suitable_version(version)

        # store matched version in scope.  
        scope['matched_api_version'] = self.api_version_var.get()  >>>>>>>>>>New Code

middleware.py

        response = await call_next(request)
        if api_version is not None:
            # We return it because we will be returning the **matched** version, not the requested one.
            # In date-based versioning with waterfalling, it makes sense.
            matched_api_version = request.scope.get('matched_api_version', api_version).  >>>>>> new code
            response.headers[self.api_version_parameter_name] = matched_api_version.    >>>>>>modified code

        return response

what do you think @zmievsa ?