Unleash / unleash / 25112758706

87%

master: 91%

push

github

fix: revision id calculation for segments (#11861)

## Summary

This PR fixes how delta/streaming revisions are calculated for segments.

The intended rule is:
- segment events should keep the cached delta snapshot up to date
- segment events should only advance the visible `revisionId` when the
segment is actually referenced by the visible feature payload for that
environment

## The bug

A segment event could advance the in-memory visible `revisionId` for an
environment even when the client-visible delta payload for that
environment had not changed.

That showed up as inconsistent behavior across pods:
1. a long-lived pod could carry an inflated visible `revisionId`
2. a fresh pod could recompute from persisted state and return a lower
one

So the issue was not incorrect flag state, but incorrect visible
revision tracking.

## Why the patch also touches segment delivery

While working through this, there was a second correctness issue for
segment-by-reference clients.

If a segment was updated while unreferenced, a client could advance past
that hidden segment update because of unrelated visible feature changes.
Later, a `feature-updated` event could start referencing that segment,
but the client would not necessarily receive the segment payload it now
needed for evaluation.

To avoid that stale-client case, the delta response now materializes a
synthetic `segment-updated` event when a returned `feature-updated`
event introduces a segment reference that is not already present in the
returned delta event set. The payload comes from the cached hydration
snapshot.

## Event ordering and ETags

Delta events are accumulated in the cache by event category, so a
response could contain events out of revision order, for example a
`feature-updated` event with revision 26 followed by a `segment-updated`
event with revision 25.

That matters because the delta controller uses the last returned event
id as the response ETag. If the last event is not the highest r... (continued)

1836 of 2028 branches covered (90.53%)

66 of 71 new or added lines in 4 files covered. (92.96%)

15042 of 17263 relevant lines covered (87.13%)

911.79 hits per line