[Tsavorite] Default to NativeStorageDevice on x64 Linux (+ segment-boundary flush and write-error propagation fixes) - #1991

…dary

A full-page recovery flush whose fromAddress points just past the PageHeader
double-counted the header: endOffset was computed as startOffset + PageSize,
then startOffset was reset to 0 to include the header while keeping the inflated
end, producing a PageSize + PageHeader byte write. When a segment holds a single
page (SegmentSize == aligned page size), that write crosses into the next segment.

Managed devices (RandomAccess) silently tolerated this by growing the segment
file; NativeStorageDevice correctly rejects a write whose end exceeds the segment.
Clamp the page-relative end to PageSize so a full-page flush writes exactly the
page and never past it. Records never span pages, so this only removes the header
double-count.

Co-authored-by: Copilot <[email protected]>
Copilot-Session: acafd58e-b5ce-420c-aec8-0e6a492d69fd

…fault to x64 Linux

Two production-readiness fixes from code review:

- ObjectAllocatorImpl: make the page-boundary clamp unconditional instead of
  only inside the isFirstRecordOnPage branch, so no flush path (mid-page start or
  partial snapshot, in addition to full-page recovery starting past the
  PageHeader) can emit a write whose end crosses the page/segment boundary.

- Devices.GetDefaultDeviceType: default to Native on Linux only when the process
  architecture is x64, matching the shipped prebuilt native library
  (runtimes/linux-x64). Other Linux architectures (e.g. arm64) fall back to the
  managed RandomAccess device instead of failing to load the native library on
  the first storage IO.

Co-authored-by: Copilot <[email protected]>
Copilot-Session: acafd58e-b5ce-420c-aec8-0e6a492d69fd

…ardown

Two pre-existing robustness fixes surfaced by the code review of the native
device switch (the native device surfaces real IO errors that managed devices
previously masked). Both are error-path only; success paths are unchanged.

Durability: on a device write error, the object-allocator flush completion
(CountdownCallbackAndContext, reached via CircularDiskWriteBuffer) hardcoded
errorCode 0 when invoking the upper-layer callback, so AllocatorBase's
AsyncFlushPageCallback (which is already error-aware and records failures in
errorList) treated a failed flush as success and advanced FlushedUntilAddress
past unwritten data. Retain and forward the first non-zero error instead.
Likewise, the snapshot, main-index, overflow-bucket, and commit-metadata
checkpoint completions logged the error but signaled success; they now fault
their completion (TrySetException / throw) so a checkpoint cannot commit after
a failed write.

Session: RespServerSession.TryConsumeMessages caught a fatal exception, disposed
the sender, and returned 0, letting the network receive loop re-enter on the
disposed sender (null response-object pointers -> NullReferenceException). It now
rethrows; both the TLS and non-TLS receive loops already tear the connection
down cleanly on exception.

Co-authored-by: Copilot <[email protected]>
Copilot-Session: acafd58e-b5ce-420c-aec8-0e6a492d69fd

… during migration

The vector-set migration stress test hammers VADD/VEMB while slots migrate
back and forth. Its retry loop already treats MOVED/timeout/connection as
retryable migration transients, but a raw Execute can also transiently return
a nil/null RedisResult mid-migration. Casting that nil to int threw a
NullReferenceException that escaped the retry filter (and the VEMB read cast a
nil to a null string[] that would NRE on .Length), intermittently failing the
test. Switching the default Linux device to NativeStorageDevice shifts IO
timing during migration and made this pre-existing flake surface more often.

Treat a nil/null result as one more retryable transient in both the write and
read loops. Data integrity is unaffected: only writes that return 1 are
recorded, and the end-of-test VEMB validation independently verifies every
recorded element survived all migrations.

Co-authored-by: Copilot <[email protected]>
Copilot-Session: acafd58e-b5ce-420c-aec8-0e6a492d69fd

…tErrorCode note

- CountdownCallbackAndContext.ToString() now null-checks `context` (it was
  guarded by the `callback` null check but dereferenced `context`, which can be
  null).
- DeviceType.RandomAccess doc now reflects the x64 gating: the Linux native
  library ships only for x64, so non-x64 Linux (e.g. arm64) and macOS default to
  RandomAccess; Windows and x64 Linux default to Native.
- Documented why firstErrorCode is intentionally not reset in
  CountdownCallbackAndContext.Set(): a fresh instance is created per partial
  flush (OnBeginPartialFlush -> new()), and a device write can RecordError before
  OnPartialFlushComplete installs the callback via Set(); resetting there would
  discard a pre-Set error and let a failed flush report success.

Co-authored-by: Copilot <[email protected]>
Copilot-Session: acafd58e-b5ce-420c-aec8-0e6a492d69fd

… for all platforms

Switching the Linux default to the native device surfaced that Alpine (musl) had
no working native library: the shipped prebuilt is a glibc build whose DT_NEEDED is
libaio.so.1t64, which musl's loader (and Alpine's libaio.so.1) cannot satisfy, so
the first storage-tier/AOF write threw DllNotFoundException. The native C++ itself
builds cleanly on musl; we simply were not shipping a musl binary.

Changes:
- Ship a linux-musl-x64 prebuilt (libnative_device.so + libnative_device_libaio.so)
  built against musl; it links the portable libaio.so.1 / liburing.so.2 SONAMEs.
- Make the NativeStorageDevice loader RID-aware: it resolves runtimes/<rid>/native/
  from OS + architecture + libc (linux-x64, linux-musl-x64, linux-arm64,
  linux-musl-arm64, win-x64, win-arm64, osx-*) instead of hardcoding linux-x64/win-x64.
- Package prebuilts with a recursive glob over Device/runtimes/** so a new RID folder
  is shipped automatically without a csproj edit.
- Devices.GetDefaultDeviceType now returns Native on musl x64 too (a real musl prebuilt
  is shipped); non-x64 and other unshipped RIDs still fall back to RandomAccess.
- Add .github/workflows/native-build.yml: builds native_device via CMake for every RID
  (linux glibc/musl x64+arm64 via containers/QEMU; win x64+arm64 via MSVC), verifies the
  exported C ABI, and on manual dispatch opens a PR updating the checked-in prebuilts.
  macOS is intentionally excluded until a file_darwin.cc backend exists (the current C++
  is hard-wired to libaio/io_uring/O_DIRECT and will not compile on macOS).
- Add libs/storage/Tsavorite/cc/build-native.sh: reproducible per-platform build helper
  used by both the workflow and developers.
- Update the io_uring init-failure diagnostic (container seccomp blocking io_uring_setup
  is the real cause; musl is now supported), the native README, .gitattributes (mark
  native libs binary), and the docker validation script (Alpine now tests the native
  device too).

Validated: full docker image validation (default + native device persistence across all
5 images incl. Alpine musl) 67/0; native-build.sh recipe built + verified locally for
linux-x64 glibc, linux-musl-x64, and linux-musl-arm64 (QEMU); Tsavorite device tests 89/0;
full solution build clean.

Co-authored-by: Copilot <[email protected]>
Copilot-Session: acafd58e-b5ce-420c-aec8-0e6a492d69fd

…r Windows/modern toolsets

Adding the Windows jobs to the native-build workflow surfaced that the C++ used
<experimental/filesystem>, which the newest MSVC toolset (Visual Studio 2026 /
17.10+) has removed, so the win-x64 and win-arm64 builds failed with C1083
"Cannot open include file: 'experimental/filesystem'".

Introduce filesystem_compat.h, which prefers C++17 <filesystem> and only falls
back to <experimental/filesystem> where <filesystem> is unavailable, exposing a
single `tsv_fs` alias. Replace the hard-coded std::experimental::filesystem uses
in file_system_disk.h and native_device.h with it, and compile the native library
as C++17 (bump CMAKE_CXX_STANDARD to 17; add /std:c++17 for MSVC and -std=c++17
for gcc/clang). No C++17-removed features are used (no std::auto_ptr etc.).

Regenerated the checked-in linux-x64 and linux-musl-x64 prebuilts from the C++17
source. The win-x64/win-arm64 and arm64 Linux prebuilts are produced by the
native-build workflow (run it with update_repo=true to refresh all of them).

Validated: Tsavorite device tests 89/0 on the regenerated glibc binary; docker
image validation (default + alpine, native + default device persistence) 28/0;
glibc and musl builds compile clean under C++17 locally.

Co-authored-by: Copilot <[email protected]>
Copilot-Session: acafd58e-b5ce-420c-aec8-0e6a492d69fd

The build succeeds but CMAKE_RUNTIME_OUTPUT_DIRECTORY is overridden, so
native_device.dll is not at build/src/Release/. Find the dll/pdb recursively under
build/ instead of assuming a generator-specific path.

Co-authored-by: Copilot <[email protected]>
Copilot-Session: acafd58e-b5ce-420c-aec8-0e6a492d69fd

/CETCOMPAT (CET shadow stack) is x86/x64-only; MSVC rejects it for ARM64 with
LNK1246, breaking the win-arm64 native build. Guard the flag on
CMAKE_GENERATOR_PLATFORM != ARM64 so win-x64 is unchanged and win-arm64 links.

Co-authored-by: Copilot <[email protected]>
Copilot-Session: acafd58e-b5ce-420c-aec8-0e6a492d69fd

…-build CI

Replaces the locally-built linux-x64/linux-musl-x64 prebuilts and the stale
(C++14) win-x64 dll with the canonical binaries produced by the native-build
workflow, and adds the previously-missing linux-arm64, linux-musl-arm64, and
win-arm64 prebuilts. All six were built from the C++17 source by
.github/workflows/native-build.yml (run 30671785943, all jobs green) and had
their exported C ABI verified in that workflow.

Runtime-validated locally: linux-x64 (Tsavorite device tests 89/0) and
linux-musl-x64 (Alpine native device active + storage-tier persistence). The
arm64 and Windows binaries are build- and symbol-verified by CI; enabling Native
by default on arm64 is deferred pending validation on real arm64 hardware
(GetDefaultDeviceType keeps arm64 on the managed device; the prebuilts allow
explicit --device-type Native there).

Co-authored-by: Copilot <[email protected]>
Copilot-Session: acafd58e-b5ce-420c-aec8-0e6a492d69fd

…ched PR branch

Reworks the workflow's publish step so a developer working on a PR that changes
the native device can get the rebuilt binaries into their own PR:

- Dispatching native-build on a feature branch with update_repo=true now commits
  the refreshed runtimes/<rid>/native/ binaries directly onto that branch (rebasing
  onto the latest tip first), so the open PR updates in place and ci.yml then tests
  the C# against the new native code. Dispatching on main/dev opens a review PR
  instead (protected branches are never pushed to directly).
- Uses an optional NATIVE_BINARIES_PAT secret for the push so it can re-trigger
  ci.yml; falls back to GITHUB_TOKEN (push lands, ci.yml runs on the next push or a
  manual re-run) when the secret is absent. Documented in the workflow header and README.
- Adds a per-branch concurrency group so two dispatches can't race on the push.
- Tightens the build-only trigger to exclude cc/README.md so a docs-only edit does
  not spin up the 6-platform build; the filter remains scoped to the native sources
  under libs/storage/Tsavorite/cc/** (a change under cs/** — including the checked-in
  binaries the publish step commits — never triggers native-build, avoiding loops).

Co-authored-by: Copilot <[email protected]>
Copilot-Session: acafd58e-b5ce-420c-aec8-0e6a492d69fd

…re mitigation

The Windows build requires the Spectre-mitigated CRT libraries (CMakeLists uses
/Qspectre /guard:cf /sdl; a missing component fails the link with MSB8040, per
cc/README.md). The workflow previously relied implicitly on the hosted image
shipping them. Make it explicit and verified:

- Add an "Ensure MSVC Spectre-mitigated CRT libraries" step that detects the
  lib\spectre\<arch> component (and the ARM64 VC toolset for the arm64 target) and
  installs it on demand, so the build no longer silently depends on image contents.
- After the build, verify the produced native_device.dll actually carries the
  security mitigations by checking the PE load config for Control Flow Guard
  (/guard:cf) and the stack Security Cookie (/GS,/sdl) — both set alongside
  /Qspectre — failing the job if they are absent.

Co-authored-by: Copilot <[email protected]>
Copilot-Session: acafd58e-b5ce-420c-aec8-0e6a492d69fd

…vice docs

macOS is not a shipped native platform here; drop the macOS/darwin explanatory
commentary from the native-build workflow header and the GetDefaultDeviceType
doc comment to keep the comments focused on what is actually built and shipped.

Co-authored-by: Copilot <[email protected]>
Copilot-Session: acafd58e-b5ce-420c-aec8-0e6a492d69fd

Regenerated by the Build Native Device workflow (run 30677804058) from the native sources on 'badrishc/switch-to-native-device-linux'.