Installing BigPipe module along Doubleclick for Publishers (DFP) module causes Drush and Drupal Console to stop working and trowing a ServiceCircularReferenceException:
$ drupal moi dfp
Installing module(s) "dfp"
[ERROR] Circular reference detected for service "html_response.attachments_processor.big_pipe", path:
"html_response.attachments_processor.big_pipe -> html_response.attachments_processor.big_pipe".
Both modules have a service that extend `HtmlResponseAttachmentsProcessor`. If I increase the weight of the BigPipe module before installing DFP, then the error will be:
[ERROR] Circular reference detected for service "dfp.html_response.attachments_processor", path:
"dfp.html_response.attachments_processor -> dfp.html_response.attachments_processor".
I've tested against the latest versions of Drupal core (v8.1.x-dev 363b42f32278a7df4583016e6c65043910fbcef2) and DFP (v8.x-1.x-dev 371fe49b745ca37885181bdd833e9976fe1b6986)
I'm not sure if this bug should have been filed in a different place, but assume that it will have more visibility this way.
Comment | File | Size | Author |
---|---|---|---|
#10 | 2792817-10.patch | 1.11 KB | Wim Leers |
Comments
Comment #2
SchnWalter CreditAttribution: SchnWalter commentedComment #3
Fabianx CreditAttribution: Fabianx at Tag1 Consulting commentedBoth just use a decorator.
Maybe Symfony cannot handle two services decorating something ...
Comment #4
dawehnerOne cannot use the same
decoration_inner_name
for each decorator.Suggestion use:
decoration_inner_name: html_response.attachments_processor.original_big_pipe
Comment #5
cilefen CreditAttribution: cilefen commentedContributed project blockers are Major priority.
Comment #6
cilefen CreditAttribution: cilefen commentedOr it is just a bug in DFP?
Comment #7
dawehnerWell, its a conflict between dfp and big_pipe.
Comment #8
Wim LeersOn this.
Comment #9
Wim LeersAs per usual, @dawehner is right:
This is exactly right. See https://symfony.com/doc/current/service_container/service_decoration.html:
So the solution is simple, and can and should in fact be adopted by both BigPipe in Drupal 8 core and by the
dfp
module:If either module fixes this, it's fixed. So this patch does not block
dfp
;dfp
can fix this itself. Nevertheless, Drupal core should be fixed too.Comment #10
Wim LeersAlternatively, we don't specify
decoration_inner_name
at all, and just rely on the auto-generated inner name. Which is probably the simpler/easier thing to do:Comment #11
dawehner@Wim Leers
Did you actually tried out what happens when you do that?
The code looks like this:
which seems more likely to cause some conflict.
Comment #12
Wim LeersYes. I tested both patches.
Both #9 and #10 work fine. In either case, the decorated service is renamed to something unique that contains the decorating service's name, which ensures uniqueness. Just as https://symfony.com/doc/current/service_container/service_decoration.html prescribes.
Comment #13
dawehnerGotcha.
Yeah I guess this is happening somewhere else than in the code quoted above.
Comment #14
SchnWalter CreditAttribution: SchnWalter commentedThank you very much, the latest patch (#10) works perfectly!
Comment #15
Wim LeersGlad to see that confirmed by you :)
Comment #16
Wim LeersFixed a similar service decoration bug in the BigPipe demo module: #2793487: BigPipe Demo decorates html_response.attachments_processor, but uses an inner name based on the decorated service, which can cause problems.
Comment #17
Fabianx CreditAttribution: Fabianx as a volunteer and at Tag1 Consulting commentedRTBC + 1, looks good to me.
Comment #20
catchCommitted/pushed to 8.3.x and cherry-picked to 8.2.x. Thanks!
Comment #21
Wim LeersThanks!
Comment #23
bleen CreditAttribution: bleen at NBCUniversal commented