Regression on generated cache tags since 2.4.3

Hi folks,

I was tested varnish integration on a branch with 2.4.3 and just constated a difference with my master branch which use 2.4.2. I backport all my changes and everything worked smoothly on 2.4.2, so this seems to be a regresson. Maybe it’s on purpose, but i haven’t seen it here https://github.com/api-platform/core/releases/tag/v2.4.3.

serialization/entity1.yml
   uuid:
     groups:
       - entity1:list
   entity2: 
     groups:
       - entity1:list
   entity3: 
     groups:
       - entity1:list


serialization/entity2.yml
   label: 
     groups:
       - entity1:list
   uuid: 
     groups:
       - entity1:list


serialization/entity3.yml
# nothing related to entity1:list, forcing the use of iri

On both branch, the output json is the same (call on /entity1):

[{
	"entity2": {
		"uuid": "1925bf7f-d719-473b-a1c9-6981f70c4340",
		"label": "toto",
	},
	"entity3": ["/entity3/2fec4ee1-5127-43e1-977f-6995d068aa88"],
	"uuid": "23b11ca6-3cc0-489a-8b13-0c643060ae9a"
}]

But the cache tags sent changes:

on 2.4.2

- entity1/23b11ca6-3cc0-489a-8b13-0c643060ae9a
- entity2/1925bf7f-d719-473b-a1c9-6981f70c4340
- entity3/2fec4ee1-5127-43e1-977f-6995d068aa88
- entity1

on 2.4.3, the entity that indeed have a serialization group lost the corresponding cache tags

- entity1/23b11ca6-3cc0-489a-8b13-0c643060ae9a
- entity3/2fec4ee1-5127-43e1-977f-6995d068aa88
- entity1

It’s very critical, and kind of illogic : I don’t care to invalidate the entity1 entity if I change something on entity3 as the uuid doesnt change but i do really care to invalidate this page if i change my entity2 label because it’s indeed present in the response.

I didn’t got the chance to find wich commit / PR causes this change, but I figured that some of you may have an idea.

[bastnic]

@teohhanhui done 😉.

[teohhanhui]

@bastnic Good catch! So, we should unset($context['iri']); when traversing down to the children, if I understand correctly.