Thanks Ahmet — that's a real hole in the snippet. Cache::add keyed only on host + path + date means the first response of the day wins, so a later call on the same path with an earlier Sunset (or a second pinned version that shares the path) never gets logged.

I'd tighten the key the way you suggest: include the configured API version and a hash of the Deprecation, Sunset, and Link values. Each distinct notice still logs once; identical repeats stay quiet. A small aggregator can then roll those distinct keys up for the owner instead of one line per request.

A fixture that hits the same path twice with two different Sunset dates is exactly the right regression: both obligations should reach the register, and matching headers should still dedupe.

For the Link contribution to that hash, I would select the deprecation and sunset relations rather than hash the entire header verbatim. An integration can also return pagination links or other changing relations; those would create distinct keys even when the migration notice is unchanged.

The event can still retain the complete raw header for inspection. A fixture with identical deprecation metadata but two different pagination cursors would check that operational request variation does not defeat the deduplication you just added.