@omarzouk do you have an example on how you'd use this? it will be useful for me for writing the tests 😊

it is a map object similar to the variables field, so the input request would look something like this:
{"query":"query getAccount($id: ID!) {\n getAccount(id: $id) {\n id\n name\n\n }\n","variables":{ "id": "XXX" }, "extensions":{"some_property": "some_value"}}

We would then like to have access to it in the get_context function somehow. Perhaps under the Request object?

thanks!

this might be a good time to refactor some parts of accessing the context. Ref #1258 #2687

How urgent is this?

Would be nice to have it in the upcoming couple months. We would love if we can start using it early next year

@patrick91 hello! do u think there is bandwidth to prioritise the refactor you mentioned during January? if not, could we add support for the variable to the existing setup?

We would love to start using extensions soon. As opposed to headers, extensions are meant to work on both HTTP and Websockets which make them much better at carrying soft metadata, like device timezone or locale

@omarzouk I think we can make it happen, just to clarify, you want to be able to update value of extensions from a resolver, something like:

@strawberry.type
class Mutation:
    @strawberry.mutation
    def login(self, info: Info) -> bool:
        token = do_login()
        info.context["extensions"]["something"] = 123
        return True

We don't need to edit it, we just want to be able to read it. Today its not part of the Request object we get in the get_context function

@omarzouk oh, gotcha, thanks 😊