Due to an unknown issue at the time, my custom module tests were failing. When trying to add a debug() statement on a config object, all of a sudden the tests were passing. This caused for a big WTF moment for me and for my team. You can see this happening on youtube or in the attached movie file (http://www.youtube.com/watch?v=8y3S6VXKlO0)
Thanks to Wim Leers I was able to figure this out by using the "$this->dumpHeaders = TRUE;" call within the tests that show what headers are being used.
The issue is that a debug() statement or any error that gets triggered which causes _drupal_log_error to show any error, such as trigger_error() adds a new header to the request. This header is added as follows:
// For non-fatal errors (e.g. PHP notices) _drupal_log_error can be called
// multiple times per request. In that case the response is typically
// generated outside of the error handler, e.g., in a controller. As a
// result it is not possible to use a Response object here but instead the
// headers need to be emitted directly.
header('X-Drupal-Assertion-' . $number . ': ' . rawurlencode(serialize($assertion)));The negative effect of this is that it somehow ends up being a different cache variation and makes debugging in tests really hard.
Don't let the X-Drupal-Assertion-* change the cache variation?
unknown
unknown
unknown
unknown
| Comment | File | Size | Author |
|---|---|---|---|
| #3 | drupal8debugcachewtf.mp4 | 19.05 MB | nick_vh |
Comments
Comment #2
wim leersComment #3
nick_vhComment #6
wim leersComment #12
quietone commentedTriaging issues in simpletest.module as part of the Bug Smash Initiative to determine if they should be in the Simpletest Project or core.
This looks like it a Phpunit issue, changing component.
Comment #15
larowlanCame up as today's bugsmash triage target. I think its got all the tags it needs here
Comment #16
mondrakewell debug() was deprecated in 9.2 via #2002514: Deprecate debug(); remove references to _drupal_debug_message()., so is this still relevant?