When using throttle directive how can the client be informed when they can retry again etc.

What problem does this feature proposal attempt to solve?

When the @throttle directive is applied and hit, the client side has no way to know when they can re-try.

Which possible solutions should be considered?

How could the problem be solved? What alternative solutions exist? Which is best?

Status on the response is 200 OK not a 429 Too many requests http status which is ok I suppose as there is the errors array.

json
{
    "errors": [
        {
            "message": "Rate limit for Query.user exceeded. Try again later.",
            "extensions": {
                "category": "rate-limit"
            },

But no information is included with the error for when client can re-try their request.
It may not be configured to decay at a rate of 1 minute after-all.

Graphql Spec does not mention how to error specifically for rate limit information presumably details could be added to the extended data.
https://spec.graphql.org/October2021/#sec-Errors

Reading into this elsewhere on githubs api docs for example.

https://docs.github.com/en/graphql/overview/resource-limitations#rate-limit
Suggests a rateLimit object.

Where this issue for githubs own graphql mentions response headers.

https://github.com/github/docs/issues/22607

Suggests headers.

< x-ratelimit-limit: 5000
< x-ratelimit-remaining: 0
< x-ratelimit-reset: 1670985544
< x-ratelimit-used: 5000
< x-ratelimit-resource: graphql

Start by tracing the @throttle directive and the rate-limit error extensions described in the issue. Compare the GraphQL error specification with the linked GitHub rate-limit examples and determine whether retry information belongs in the response data or headers. Done means an agreed design specifies how clients learn when they may retry.