Needs work
Project:
Drupal core
Version:
main
Component:
cache system
Priority:
Normal
Category:
Bug report
Assigned:
Unassigned
Issue tags:
Reporter:
Created:
5 Feb 2016 at 19:10 UTC
Updated:
7 Nov 2019 at 23:15 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #2
marthinal commentedI don't know if we can prevent to execute the subscriber instead of verify the Method... For the moment let's try this patch.
Comment #5
steveoliver commentedStill applies locally to 8.1.x. Want to see what testbot has to say.
Comment #8
themic8 commentedFor Drupal 8.1.x.
Most recent tests from September look like they have passed.
I have also applied and tested the patch. Specifically for 8.1.7.
Comment #10
cilefen commentedComment #13
jespermb commentedI updated the patch for 8.6
Comment #14
yogeshmpawarTriggering test bots.
Comment #16
nick.monaco15@gmail.com commentedThis patch seems to work.
Comment #17
nick.monaco15@gmail.com commentedComment #18
pfrillingI am using the jsonapi module to update commerce product variations. When using the PATCH method to update products, I received the following error:
After I applied the patch in #16, my product variations updated correctly.
Comment #20
arturs.v commentedPatch from #16 worked in our case. Attaching another patch (functionally the same) with slightly updated formatting.
Comment #21
leksat commentedI met the following error when worked on a custom mutation for the GraphQL module:
LogicException: The controller result claims to be providing relevant cache metadata, but leaked metadata was detected.I used this patch, but then I met the other error on the taxonomy term overview page:
LogicException: Render context is empty, because render() was called outside of a renderRoot() or renderPlain() call.More details and a debug tip: https://github.com/drupal-graphql/graphql/issues/610#issuecomment-440998061
In general, I think this patch can't be used in its current form (only use
wrapControllerExecutionInRenderContextfor GET requests) because:- we have several places in core where rendering happens on POST requests (see failed tests on this issue)
- there can be a lot more such cases in contrib/custom code
Comment #22
leksat commentedThe issue was solved in GraphQL module like this:
REST and JSON:API modules can probably do the same.
Comment #23
gerzenstl commentedI was getting similar error mentioned on #18 when using POST method through jsonapi module.
I can confirm that patch from #20 works fine.
My setup:
Drupal: 8.6.9
eck: 1.0-alpha5
jsonapi: 1.24
jsonapi_extras: 2.15
Comment #24
lexsoft00 commentedPatch from #20 does not work with drupal blocks.
Drupal Version
8.7.8
Whenever you update a drupal block you get the following error:
Comment #25
fabianx commentedJSON API / GraphQL / ... should not return a cacheable response for PUT / POST in the first place, but use a non-cacheable variation.
Alternatively we could check max-age on the returned response and not throw the Exception if it’s 0 (uncacheable).
Though I do think that we have extra code in Dynamic Page Cache to account for GET vs POST so a patch like this should be fine but likely needs to update the tests.
Comment #26
mglamanJumping in, does this relate #3072076: JSON:API returns a CacheableResponseInterface instance for non-cacheable methods; causes unnecessary exceptions.? Which would stop JSON:API from always returning a cacheable response.