BadRequestHttpException: No contextual ID tokens specified

I received the the message after updating to 8.6.2 My stack is: Apache/2.4.33 (Win64) PHP/7.2.4 Commerce 2.x site completely built with composer and use composer update --with-dependencies to shotgun update sandbox sites.

Look at the code ... This returns requested rendered contextual links. If you are not seeing 'Invalid contextual ID specified.' then you are probably OK.

I was not able to force the message a second time without reverting to 8.6.1

Does not apply to this item, but if you are using pathauto and see something like "The URL-Alias field needs to be uninstalled" then fix with drupal update:entities (drupal console) or drush update:entities. This has been a fairly regular occurrence in 8.3 through 8.6 and I asume will continue. Also you may want to re- bulk generate URL aliases.

I've experienced the same issue updating from 8.5.7 to 8.5.8, with the following 2 log entries:

Symfony\Component\HttpKernel\Exception\BadRequestHttpException: No contextual ID tokens specified. in Drupal\contextual\ContextualController->render() (regel 63 van /var/www/clients/.../web/core/modules/contextual/src/ContextualController.php).

Symfony\Component\HttpKernel\Exception\BadRequestHttpException: No contextual ID tokens specified. in Drupal\contextual\ContextualController->render() (regel 63 van /var/www/clients/.../web/core/modules/contextual/src/ContextualController.php).

In the security update tokens were added to contextual links.
Token adding: https://github.com/drupal/drupal/commit/c8f0c39ca488cc29ed575b61c0acf458...
Token checking: https://github.com/drupal/drupal/commit/c8f0c39ca488cc29ed575b61c0acf458...

If the error occurred only once then it's probably a stale rendered content cache.
If you keep getting the error then something in your site may be creating contextual links without 'data-contextual-token'

JvE in #5 is right: the usual reason for this error is some custom code or template that render the contextual wrapper without the new required token.

Grepping your templates and preprocessing functions looking for 'data-contextual-id' may help...

The error is coming for me as well. I am using Seven as Administration theme and while I am changing the themes, I am getting this error.
I am unable to place blocks in regions. I noticed the same error when I am placing the blocks.

In browser console, I can see errors such as anonymous call has been made.

My usage stack is Drupal 8.6.3 (got same error in Drupal 8.6.2, so upgraded the core). I am using Cent OS and in a Virtual Private server.

Any help to on this on where to start looking.

Here is the error screenshot

It would be interesting to know the names and versions of non core extensions on affected sites.

This issue is still occurring. Is there an update on this?

This error can be caused by a PHP post_max_size directive which is too small.

Thanks puregin - that was kind of my issue.

I had set post_max_size to 8MB instead of 8M.

Thanks, if you can reproduce with steps starting from 'install drupal', please re-open

Thanks pmagunia - I had done a similar mistake. Wrote post_max_size as 516 instead of 516M 😉

I believe that in most of the cases where this error shows up in my logs, the client has made a GET request to /contextual/render. It looks like bots that are monitoring all the URLs accessed by a page request and trying to hit all of them. So they make a normal request to some page on the site, which triggers an ajax event that does a POST to /contextual/render, and somehow they see that URL and try to follow it.

I think it would be preferable to just silently fail in that case, versus the BadRequestHttpException. I certainly get a ton of these errors and they're effectively meaningless.

It is trivially easy to generate this error in one way - do a GET request of /contextual/render. But the question is, I suppose, is that a bug?

If people are getting this error from a normal context, the contextual links for an element on a webpage, that's likely a different problem. My only suggestion would be to add code to where the exception is being thrown - Drupal\\contextual\\ContextualController::render() for me - that writes the current request out to the error log.

Drupal 9 is EOL. Does this happen on a supported version of Drupal?

Yes, of course.

I tried building an 11.x example at simplytest.me and the status came up as "This version of Drupal is no longer supported"?? The 11.2.x build comes up in 11.2.3-dev. These are all limitations of simplytest.me.

Just spin up a core Drupal instance there and log in as admin/admin, then go to the path /contextual/render in the browser - eg
https://master-yegb7y4mz13n4rdqlxwabk2v5vqfrni6.tugboatqa.com/contextual...

What I see is a white screen with "No contextual ids specified." In the error log, this is the error:

Type client error
Date Friday, 11 July 2025 - 17:00
User admin
Location https://master-yegb7y4mz13n4rdqlxwabk2v5vqfrni6.tugboatqa.com/contextual...
Referrer
Message Symfony\Component\HttpKernel\Exception\BadRequestHttpException: No contextual ids specified. in Drupal\contextual\ContextualController->render() (line 66 of /var/lib/tugboat/stm/web/core/modules/contextual/src/ContextualController.php).
Severity Warning

None of this is anything other than what you would expect it to do, I don't think. As I said, the question is, is this a bug? Should it be failing like this in this circumstance?

If people are seeing normal valid AJAX POST requests to /contextual/render that have no ids, that's a different problem. So far I don't have evidence of that but it's tricky to separate the two cases.

I am connecting the issue that added this behavior.

It's intentional that requests to /contextual/render with no IDs results in this response—of course Drupal does so and it is tested to be true. As far as I know these requests are always invalid and are always client error. A 400 response is appropriate. In addition tokens is also required and produces a 400 too.

I agree we would have to understand if there are what people think are valid requests to /contextual/render failing in 2025.

To be a bug we need steps to reproduce involving valid contextual link setups that experience this behavior. I don't think there are any because Drupal has been configured for a long time to reject these requests.

To change the behavior is a different matter. In my opinion we should not. A web application firewall or web server configuration can block these bad requests to avoid them ever getting to Drupal.

So @brad.bulger, I pretty much agree with you and I think this should be closed as not having steps to reproduce.

Since there's been no follow up going to close out. If still an issue in D11 please re-open!