Joseph Doherty
122940c0e4
Two latent apply-path hazards from the ScadaBridge adversarial architecture review. Neither has a live trigger in any current consumer — ScadaBridge's ten replicated tables carry no foreign keys at all (verified against the running rig's site-localdb.db) and OtOpcUa's LocalDb tables carry none either — but both are the kind that surface as silent divergence rather than as an error, so they are closed before a consumer's schema grows into them. Wire-compatible: no proto change, no lib_schema_version bump, no on-disk schema change. No consumer code change. - RegisterReplicated now refuses a table that is the PARENT of a foreign key with a row-mutating ON DELETE action (CASCADE / SET NULL / SET DEFAULT), naming the offending child column and action. The apply path writes remote rows with INSERT OR REPLACE, whose PK-conflict resolution DELETES the existing row first; connections run PRAGMA foreign_keys=ON, so that implicit delete fires the child's ON DELETE action while the capture guard is raised. The child rows would change on the applying node only, produce no oplog entry, and diverge the pair with nothing able to detect it — LWW compares only rows it was told about. RESTRICT / NO ACTION stay allowed: they abort the statement instead of mutating rows behind capture's back, which the apply path already handles as per-entry poison. The check inspects every foreign key in the database and runs at registration; SQLite cannot add a foreign key to an existing table, so a child table created later is caught at the next startup's registration, not at the DDL. Documented on ILocalDb.RegisterReplicated and in the README's limitations list. - An entry's row write and its ledger write are now atomic with each other. They are two statements and SQLite aborts only the failing one, so a statement-level fault between them — the case the per-entry poison catch exists for — committed a half-applied entry: a tombstone whose table row was gone while __localdb_row_version still called it live (SnapshotStreamer can only warn and skip that, so the peer never learns the row died), or an upsert whose new row carried the OLD version and therefore lost the next comparison it should have won. The pair now runs inside a per-entry SAVEPOINT, rolled back (and released, so nothing nests) before dead-lettering, leaving both writes or neither while the rest of the batch proceeds and commits. Every new test was run against the unfixed code first and fails there with exactly the divergence shape described: the tombstone case reads back null instead of the live row, the upsert case reads back the remote row against an unchanged ledger, and the registration cases throw nothing. Suite: 213/213 green, build 0 warnings / 0 errors.
25 lines
1.1 KiB
XML
25 lines
1.1 KiB
XML
<Project>
|
|
|
|
<PropertyGroup>
|
|
<TargetFramework>net10.0</TargetFramework>
|
|
<Nullable>enable</Nullable>
|
|
<ImplicitUsings>enable</ImplicitUsings>
|
|
<LangVersion>latest</LangVersion>
|
|
<Version>0.3.3</Version>
|
|
<ManagePackageVersionsCentrally>true</ManagePackageVersionsCentrally>
|
|
<TreatWarningsAsErrors>true</TreatWarningsAsErrors>
|
|
<!-- NU1510 (package-pruning advice): the Replication and Tests projects carry a
|
|
Microsoft.AspNetCore.App FrameworkReference AND explicit PackageReferences to
|
|
in-framework packages (Hosting/Logging/DI/Configuration), as required by the
|
|
library layout. The advice is benign; keep the explicit refs and silence it. -->
|
|
<NoWarn>$(NoWarn);NU1510</NoWarn>
|
|
<PackageReadmeFile>README.md</PackageReadmeFile>
|
|
</PropertyGroup>
|
|
|
|
<!-- Embed the repo README in each packable nupkg (ignored by non-packable projects). -->
|
|
<ItemGroup Condition="'$(IsPackable)' == 'true'">
|
|
<None Include="$(MSBuildThisFileDirectory)README.md" Pack="true" PackagePath="\" Visible="false" />
|
|
</ItemGroup>
|
|
|
|
</Project>
|