Embed native SQLite (e_sqlite3) into the single-file binary; release 0.34.2 - #151
Merged
Conversation
…oject level
A re-installed daemon crashed on first DB touch with:
TypeInitializationException: 'SQLite.SQLiteConnection'
---> DllNotFoundException: Unable to load shared library 'e_sqlite3'
/opt/dapps/e_sqlite3.so: cannot open shared object file: No such file
Root cause: a plain `dotnet publish -p:PublishSingleFile=true` (the
build-from-source / hand-rolled path) emits libe_sqlite3.so as a SIBLING
file next to the exe rather than inside it. DAPPS ships as one downloaded
binary — docs/install.sh drops only /opt/dapps/dapps, nothing alongside —
so the native lib is absent at runtime and SQLitePCLRaw's static init
throws the first time the daemon opens the DB.
The self-extract publish flags previously lived only in the CI and
dev-push publish args, so any other publish path produced a silently
broken single binary. Move IncludeNativeLibrariesForSelfExtract +
IncludeAllContentForSelfExtract into dapps.core.csproj (conditioned on
PublishSingleFile) so every publish path bakes SQLite — and the rest of
the native deps — into the binary. The properties are inert for normal
build/run/test, so dev and the UI-test fixture's output paths are
unchanged.
Reproduced the exact failure and verified the fix: a flagless
`-p:PublishSingleFile=true` publish now embeds the native lib (no sibling
.so), and the lone copied binary boots and creates dapps.db standalone.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Q2kdbKAG4JQTLmf1eSuhtq
Bump <Version> so CI cuts a release carrying the e_sqlite3 self-extract fix. Without a version bump the merge lands as a normal commit and no release is published, leaving install.sh serving the old binary. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Q2kdbKAG4JQTLmf1eSuhtq
…t silently skip a release The test job gates releases (build/release run only when its should_release output is true, and a failed step short-circuits the job), so one intermittent test failure strands a version-bumped release: the run goes red but no binary publishes. The suite has a known ~1/683 broker-port bind-race flake that must not be able to block a real release. Run the suite up to 3 times: a transient flake heals on a later attempt and the release proceeds; a genuine regression fails all attempts and loudly blocks it. On each failed attempt, dump the per-test results log to the console - under `dotnet test`, MTP writes the failing test NAME only to that log file (stdout has just the summary), so this makes the flake greppable in the job log instead of requiring an artifact download. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Q2kdbKAG4JQTLmf1eSuhtq
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Q2kdbKAG4JQTLmf1eSuhtq
…env from parallel tests Fixes the intermittent CI flake (GatewayPathBaseTests.*_UrlSurfaces* asserting 200 but getting 302). Root cause is test env-var bleed, not the broker-port race first guessed in #152: DbStartupTests and Rhpv2InboundServiceTests set DAPPS_*/PDN_* vars process-wide via Environment.SetEnvironmentVariable. They're in a different xUnit collection, so they run in parallel with GatewayPathBaseTests, which spawns `dotnet dapps.core.dll` as a subprocess - and the subprocess inherits this process's environment. When e.g. PDN_NODE_CALLSIGN is set at spawn time, DbStartup in the child derives a real callsign, so the fresh-install /Setup wizard's OnGet sees a configured callsign and 302s to / instead of rendering the bearer step, failing the assertion for 200. Purely a function of parallel timing, which is why it was intermittent and why retrying the whole suite never healed it (the polluting tests re-run on every attempt). Scrub all inherited DAPPS_*/PDN_* keys from the subprocess environment before launch so it always boots a pristine first-run state regardless of what sibling tests do to the shared process env. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Q2kdbKAG4JQTLmf1eSuhtq
M0LTE
added a commit
that referenced
this pull request
Jun 21, 2026
Bump <Version> to 0.34.3 so CI publishes a real release carrying the embedded-SQLite single-file fix from #151. v0.34.2 was already taken by a manual pre-fix release, so the post-merge run skipped publishing.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
An early adopter's re-installed daemon crashed on first DB touch:
Root cause
A plain
dotnet publish -p:PublishSingleFile=true(the build-from-source / hand-rolled path) emitslibe_sqlite3.soas a sibling file next to the exe rather than inside it. DAPPS ships as one downloaded binary —docs/install.shdrops only/opt/dapps/dapps, nothing alongside — so the native lib is absent at runtime andSQLitePCLRaw's static init throws the first time the daemon opens the DB.The probe paths in the log are the giveaway: they list only
/opt/dapps/...(no/tmp/.net/...extraction dir) whileMainis running — the signature of a single-file build with neither self-extract flag. CI andscripts/dev-pushboth pass those flags, but they lived only in those two scripts, so any other publish path silently produced a broken binary.Fix
Move
IncludeNativeLibrariesForSelfExtract+IncludeAllContentForSelfExtractintodapps.core.csproj(conditioned onPublishSingleFile), so every publish path bakes SQLite — and the rest of the native deps — into the binary. The properties are inert for normalbuild/run/test, so dev and the UI-test fixture's output paths are unchanged.Also bumps
<Version>to 0.34.2 so CI cuts a release carrying the fix (no bump → no release →install.shkeeps serving the old binary).Verification
Reproduced the exact failure and confirmed the fix locally (.NET 8, linux-x64):
TypeInitializationException/DllNotFoundExceptionwith the/opt/dapps/...e_sqlite3probes.-p:PublishSingleFile=truepublish embeds the lib (no sibling.so); the lone copied binary boots and createsdapps.dbstandalone — the very code path (DbStartup.EnsureSchemaAndSeed) that was crashing.dotnet buildsucceeds with the dll still atbin/Release/net8.0/, so the UI-test fixture is unaffected.🤖 Generated with Claude Code
https://claude.ai/code/session_01Q2kdbKAG4JQTLmf1eSuhtq
Generated by Claude Code