The once-per-host-and-path-per-day key reduces noise, but it can also hide a more urgent notice received later that day. Two explicitly pinned API versions may share a path while returning different Sunset dates; the first response wins the cache key even if the second version is retiring sooner.
I would include the configured API version and a fingerprint of the deprecation metadata in deduplication, then aggregate repeated events for alerting. A fixture with the same path and two different Sunset headers would check that both migration obligations reach the dependency register without logging every successful request.
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.
Ahmet Özel
The once-per-host-and-path-per-day key reduces noise, but it can also hide a more urgent notice received later that day. Two explicitly pinned API versions may share a path while returning different Sunset dates; the first response wins the cache key even if the second version is retiring sooner.
I would include the configured API version and a fingerprint of the deprecation metadata in deduplication, then aggregate repeated events for alerting. A fixture with the same path and two different Sunset headers would check that both migration obligations reach the dependency register without logging every successful request.