Get `RateLimitException`s origin

[christian98]

What problem does this feature proposal attempt to solve?
We are currently building a new GraphQL-Query which we want to throttle by @throttle. We are pretty unsure which rate limit we should use (The query might get executed quite often when the user is mistyping its input). So we want to start with a fairly restrictive rate limit and adjust it along the way. Therefore we wanted to add a new ErrorHandler to log the RateLimitException to be notified about how often users run into the rate limit. Unfortunately, when we look into the logs we can not determine which query was the cause for such an entry in our log files. So, we have to guess if the rate limit is from someone trying to abuse our API or someone hitting our new query.

Which possible solutions should be considered?
It would be great if the RateLimitException could be extended to provide the information about the path the exception was thrown at. The exception could get this info by a newly introduced constructor parameter or a setter function. Then we could access this property in our Errorhandler to enhance our log message with that info.

If this is desired, we would be happy to bring up a PR.

[spawnia]

Sounds good. How about we add the path to the field to the error message?

-Rate limit exceeded. Please try later.
+Rate limit for FooType.barField exceeded. Try again later.

[christian98]

For me, this would be fine. But it might break assertions in the user's test suites. Actually, we do test that the throttle directive is applied to certain fields by expecting the error message and the category. If the message changes we (and potentially others too) would have to adjust our assertions:

$this->performGraphQL()
    ->assertGraphQLErrorCategory('rate-limit')
    ->assertGraphQLErrorMessage('Rate limit exceeded. Please try later.');

Also, this might break clients, no? As the Exception is clientSafe a client could check the error message (not the best idea, but possible 😄 )

[spawnia]

I don't consider the contents of error messages a public API covered by backwards compatibility guarantees. Such minor changes are to be expected when upgrading between minor releases.