v0.10.2 — integration-key deletion stops trusting a partial render
The circuit breaker on integration-key deletion withheld only when
spec.integrationKeys[] was entirely empty. Its own reasoning -- that a
service dropping every key at once is more likely a broken render than a
teardown -- applies equally to a service dropping most of them, and a
truncated overlay leaving one key of six standing deleted the other five.
A GoAlert key ID is the customer's webhook bearer token and cannot be
reissued.
Neither obvious fix works. Counting keys blocks adoption cleanup, where a
service legitimately declares one key while GoAlert holds several that
were never in spec. Keying off history blocks the feature itself, since
'these keys were in spec last generation' describes deliberate
declarative removal exactly.
So the removal set is split by whether the operator has ever managed each
key, which status.integrationKeys already records. Keys it never managed
are adoption cleanup and are deleted at any size. Keys that were in spec
and just left are withheld when they cover more than half of what was
being managed. Removing one key from a six-key service still works.
Verified against a live GoAlert instance, not only the mock: six keys to
one keeps all six; five keys created directly in GoAlert are all removed
while the declared one survives; and a spec going from {a,b,c} to {c,d}
in a single apply withholds a and b while still creating d.
Two limits are documented rather than implied. Dropping one key of two is
indistinguishable from meaning it. And the protection depends on
status.integrationKeys surviving, so a CR recreated with empty status
treats every pre-existing key as unmanaged.
Also in this release: CI now refuses to publish a release whose chart
appVersion does not match its tag, an upgrade-verification recipe that
queries GoAlert rather than trusting operator status, and a race-free
test suite -- 27 data races had been latent since v0.7.0 -- with the
detector running on every pipeline.
No CRD schema change from v0.10.1.