Joseph Doherty
e1487fbf10
SecretEditor and ConfirmDeleteModal wrote the success audit inside the same try as the store write, so a throwing IAuditWriter after a committed add/rotate/delete showed an error, wrote a Failure audit and skipped the resolver-cache eviction - the old plaintext kept resolving for the TTL. The mutation try now covers only the cipher + store call; the success audit is best-effort afterwards and logs a warning (no value) on failure, so the change is reported saved, the callback fires and the cache is evicted. - tests: AuditFailureAfterCommitTests (add, rotate, delete) with a throwing success audit; all fail without the fix - code-reviews: Secrets-013 Resolved; README regenerated Claude-Session: https://claude.ai/code/session_01GT67AEHd2Acv1YPwGfXEoV
17 lines
623 B
C#
17 lines
623 B
C#
using System.Collections.Concurrent;
|
|
using ZB.MOM.WW.Secrets.Abstractions;
|
|
|
|
namespace ZB.MOM.WW.Secrets.Ui.Tests.Fakes;
|
|
|
|
/// <summary>Records every <see cref="Invalidate"/> call so a test can assert the cache was evicted.</summary>
|
|
public sealed class RecordingCacheInvalidator : ISecretCacheInvalidator
|
|
{
|
|
private readonly ConcurrentQueue<SecretName> _invalidated = new();
|
|
|
|
/// <summary>The names evicted so far, in call order.</summary>
|
|
public IReadOnlyList<SecretName> Invalidated => _invalidated.ToArray();
|
|
|
|
/// <inheritdoc />
|
|
public void Invalidate(SecretName name) => _invalidated.Enqueue(name);
|
|
}
|