Joseph Doherty
dd0a846b64
Secrets were per-node SQLite, so a secret written on one node was invisible to the rest of a cluster. G-7's design resolved the "shared SQL store vs Akka replicator" fork to build only the former; both are built here so the choice is a deployment decision (availability vs partition tolerance) rather than a library limitation. Two new packages — ZB.MOM.WW.Secrets.Replicator.SqlServer (shared store, plus a local-store-with-hub mode) and .Replicator.AkkaDotNet (peer-to-peer over distributed pub/sub). Core gains ISecretsStoreMigrator, one shared SecretLastWriterWins predicate so no two stores can disagree on a tie, the transport-agnostic reconciler, and ReplicatingSecretStore — which closes a real gap: nothing had ever called ISecretReplicator.PublishAsync, so the seam was inert and local writes would not have propagated at all. Verified 182 pass / 1 skip / 0 warnings, including 15 live tests against a real SQL Server 2022 (the SQLite suite ported case-for-case, so any behavioural divergence between the stores fails) and a 9-test in-process 2-node Akka cluster over real remoting. A post-build review caught six defects, all fixed and now covered: both replication modes could not resolve from the container (no test had built one), an unbounded fetch that broke past SQL Server's 2100-parameter cap, a poison row that aborted the rest of its batch forever, Enum.Parse on peer input that could restart the actor in a loop, null crypto blobs crossing the trust boundary, and a silently dropped pull-read failure. Packed at 0.2.0 and vulnerability-scanned clean; not yet published to the feed. Claude-Session: https://claude.ai/code/session_01BL2Vu1ESDQ9SCN4gVKkdts
34 lines
1.3 KiB
C#
34 lines
1.3 KiB
C#
using Microsoft.Extensions.Hosting;
|
|
using Microsoft.Extensions.Options;
|
|
|
|
namespace ZB.MOM.WW.Secrets.Replicator.SqlServer;
|
|
|
|
/// <summary>
|
|
/// Provisions the shared hub schema at startup in hub-replication mode.
|
|
/// </summary>
|
|
/// <remarks>
|
|
/// Separate from the core migration hosted service on purpose: in hub mode there are <em>two</em>
|
|
/// stores to provision — the node's local one (handled by the core service through the
|
|
/// <c>ISecretsStoreMigrator</c> seam) and the shared hub, which no node "owns". Every node runs this
|
|
/// idempotently at startup, so the hub exists as soon as any node has started, with no separate
|
|
/// provisioning step for an operator to forget.
|
|
/// </remarks>
|
|
/// <param name="migrator">The hub migrator.</param>
|
|
/// <param name="options">Core secrets options, for the shared startup-migration switch.</param>
|
|
internal sealed class SqlServerHubMigrationHostedService(
|
|
SqlServerSecretsStoreMigrator migrator,
|
|
IOptions<SecretsOptions> options) : IHostedService
|
|
{
|
|
/// <inheritdoc />
|
|
public async Task StartAsync(CancellationToken cancellationToken)
|
|
{
|
|
if (options.Value.RunMigrationsOnStartup)
|
|
{
|
|
await migrator.MigrateAsync(cancellationToken).ConfigureAwait(false);
|
|
}
|
|
}
|
|
|
|
/// <inheritdoc />
|
|
public Task StopAsync(CancellationToken cancellationToken) => Task.CompletedTask;
|
|
}
|