Joseph Doherty
f2efeb37b7
Tasks 5 and 6 of the Phase 2 plan, committed together because their test
fallout is entangled — several fixtures construct both stores.
StoreAndForwardStorage and SiteStorageService now take ILocalDb. Connections
come from ILocalDb.CreateConnection(), which hands out an already-open,
pragma-configured connection carrying the zb_hlc_next() UDF the capture triggers
call; a raw connection would lack the UDF and every write to a replicated table
would fail closed. Deleted with the connection strings: S&F's
EnsureDatabaseDirectoryExists and its per-open busy_timeout pragma, and the site
service's BusyTimeoutFloorSeconds normalization — LocalDb owns all of it now.
DI: AddSiteRuntime's string overload is gone (nothing left to supply), so the
Host calls the no-arg form. ScadaBridge:Database:SiteDbPath and
StoreAndForwardOptions.SqliteDbPath survive only as the migrator's source
locations in Tasks 8/9.
Two things the plan did not anticipate, both worth reading:
1. FOUND A REAL LATENT DEFECT, from Phase 1, now fixed. The plan assumed
directory creation simply moved to LocalDb along with file ownership. It did
not: the LocalDb library never creates the parent directory, and
SqliteLocalDb opens the file eagerly in its constructor — so a missing
directory is a hard boot failure ("SQLite Error 14: unable to open database
file"), not a degraded start. The default site config points at the RELATIVE
path ./data/site-localdb.db, so any site node without a pre-existing data/
directory fails to boot. The docker rig escapes only because its volume mount
happens to create /app/data — a coincidence that would have hidden this until
a bare-metal or fresh deployment. This has been latent since Phase 1 made
LocalDb:Path required; deleting S&F's EnsureDatabaseDirectoryExists here
would have widened it. Re-established the guarantee at the layer that now
owns the path (SiteLocalDbDirectory.Ensure, called before AddZbLocalDb) and
pinned it with SiteLocalDbDirectoryTests. Non-vacuity is not assumed: two
tests written against the wrong assumption failed with exactly this
SQLite Error 14 before the fix existed.
2. Test fallout was ~7x the plan's estimate. The plan named "fixtures" in one
project; the constructor change actually reaches 40 files across 7 test
projects, and most used Mode=Memory;Cache=Shared — which LocalDb has no
equivalent for, so every one had to move to a real temp file. Rather than
copy the Phase 1 TestLocalDb fixture into 7 projects, added a shared
tests/ZB.MOM.WW.ScadaBridge.TestSupport library (not a test project) so the
WAL-sidecar cleanup and the "real, not stubbed" rationale live in one place.
Retargeted rather than deleted, in both directions: the S&F WAL test now asserts
against the LocalDb-backed store (WAL genuinely is LocalDb's job), while the
directory-creation test moved to Host.Tests (that guarantee is NOT LocalDb's).
SiteStorageServiceTests.Initialize_EnablesWalJournalMode got the same treatment.
DeploymentManagerMediumFindingsTests induced a persistence failure via an
unopenable path, which no longer reaches the assertion since the fixture now
throws first; it induces the same failure shape via an uninitialized store.
Verified: full solution build 0 warnings; SiteRuntime 532, Host 318,
AuditLog 355, ExternalSystemGateway 142, HealthMonitoring 97,
StoreAndForward 153 — 1597 passed, 0 failed.
Claude-Session: https://claude.ai/code/session_01BL2Vu1ESDQ9SCN4gVKkdts
71 lines
2.8 KiB
C#
71 lines
2.8 KiB
C#
using Microsoft.Extensions.Configuration;
|
|
using Microsoft.Extensions.DependencyInjection;
|
|
using ZB.MOM.WW.LocalDb;
|
|
|
|
namespace ZB.MOM.WW.ScadaBridge.Host.Tests;
|
|
|
|
/// <summary>
|
|
/// Pins that a site node creates the directory holding <c>LocalDb:Path</c> before the
|
|
/// database is opened.
|
|
/// </summary>
|
|
/// <remarks>
|
|
/// <para>
|
|
/// This guarantee used to live in <c>StoreAndForwardStorage.EnsureDatabaseDirectoryExists</c>,
|
|
/// which created the parent directory for its own SQLite file. LocalDb Phase 2 moved that
|
|
/// file into the consolidated database — but the LocalDb library does <b>not</b> create the
|
|
/// directory, and <c>SqliteLocalDb</c> opens the file eagerly in its constructor, so a
|
|
/// missing directory is a hard boot failure ("SQLite Error 14: unable to open database
|
|
/// file") rather than a degraded start.
|
|
/// </para>
|
|
/// <para>
|
|
/// This is not hypothetical: the default site configuration points at the <i>relative</i>
|
|
/// path <c>./data/site-localdb.db</c>, so any site node whose working directory has no
|
|
/// <c>data/</c> subdirectory hits it. The docker rig escapes only because its volume mount
|
|
/// creates <c>/app/data</c> — which is exactly the kind of coincidence that hides a defect
|
|
/// until a bare-metal or fresh deployment.
|
|
/// </para>
|
|
/// </remarks>
|
|
public class SiteLocalDbDirectoryTests
|
|
{
|
|
[Fact]
|
|
public void SiteRegistration_CreatesTheLocalDbDirectory_WhenItDoesNotExist()
|
|
{
|
|
var root = Path.Combine(Path.GetTempPath(), "localdb-dir-test-" + Guid.NewGuid().ToString("N"));
|
|
var dbPath = Path.Combine(root, "nested", "site-localdb.db");
|
|
Assert.False(Directory.Exists(root));
|
|
|
|
try
|
|
{
|
|
var config = new ConfigurationBuilder()
|
|
.AddInMemoryCollection(new Dictionary<string, string?>
|
|
{
|
|
["LocalDb:Path"] = dbPath,
|
|
})
|
|
.Build();
|
|
|
|
// The registration path under test. Resolving ILocalDb is what actually opens
|
|
// the file, so this fails with SQLite Error 14 if the directory step regresses.
|
|
var services = new ServiceCollection();
|
|
SiteLocalDbDirectory.Ensure(config);
|
|
services.AddZbLocalDb(config);
|
|
|
|
using var provider = services.BuildServiceProvider();
|
|
using var scope = provider.CreateScope();
|
|
var db = scope.ServiceProvider.GetRequiredService<ILocalDb>();
|
|
|
|
Assert.NotNull(db);
|
|
Assert.True(Directory.Exists(Path.GetDirectoryName(dbPath)!));
|
|
Assert.True(File.Exists(dbPath));
|
|
}
|
|
finally
|
|
{
|
|
SqliteConnectionPoolCleanup();
|
|
if (Directory.Exists(root))
|
|
Directory.Delete(root, recursive: true);
|
|
}
|
|
}
|
|
|
|
private static void SqliteConnectionPoolCleanup() =>
|
|
Microsoft.Data.Sqlite.SqliteConnection.ClearAllPools();
|
|
}
|