panic: sqld incremental snapshot

sqld 0.24.30 (0b89875a 2024-12-17)

the snapshot.sh

#!/bin/bash

SNAPSHOT_FILE="$1"
NAMESPACE="$2"

echo "Generated incremental snapshot $SNAPSHOT_FILE for namespace $NAMESPACE"

# At this point we can ship the snapshot file to whereever we would like but we
# must delete it from its location on disk or else sqld will panic.
rm $SNAPSHOT_FILE

thread 'tokio-runtime-worker' panicked at libsql-server/src/replication/primary/logger.rs:393:66:
called `Result::unwrap()` on an `Err` value: failed to perform snapshot file swap data.sqld/dbs/default/to_compact/eb6b8987-0b1a-4b37-9b56-d50a45ae3799 -> data.sqld/dbs/default/wallog

Caused by:
    EINVAL: Invalid argument
thread 'tokio-runtime-worker' panicked at library/core/src/panicking.rs:221:5:
panic in a function that cannot unwind
stack backtrace:
   0:     0x55729da63665 - <std::sys::backtrace::BacktraceLock::print::DisplayBacktrace as core::fmt::Display>::fmt::h1b9dad2a88e955ff
   1:     0x55729c8ec0fb - core::fmt::write::h4b5a1270214bc4a7
   2:     0x55729da6011f - std::io::Write::write_fmt::hd04af345a50c312d
   3:     0x55729da647c1 - std::panicking::default_hook::{{closure}}::h96ab15e9936be7ed
   4:     0x55729da644a7 - std::panicking::default_hook::h3cacb9c27561ad33
   5:     0x55729da64e09 - std::panicking::rust_panic_with_hook::hfe205f6954b2c97b
   6:     0x55729da64cd3 - std::panicking::begin_panic_handler::{{closure}}::h6cb44b3a50f28c44
   7:     0x55729da63b39 - std::sys::backtrace::__rust_end_short_backtrace::hf1c1f2a92799bb0e
   8:     0x55729da64914 - rust_begin_unwind
   9:     0x55729c30ce55 - core::panicking::panic_nounwind_fmt::h4c4dc67d0bbc166c
  10:     0x55729c30cee2 - core::panicking::panic_nounwind::hb98133c151c787e4
  11:     0x55729c30d026 - core::panicking::panic_cannot_unwind::he9511e6e72319a3e
  12:     0x55729ca5dd7d - libsql_sys::wal::ffi::frames::h12fe3f4edd1fde6e
  13:     0x55729dcb5fff - pagerWalFrames
  14:     0x55729dccdb21 - sqlite3PagerCommitPhaseOne.part.0
  15:     0x55729dcce27c - sqlite3BtreeCommitPhaseOne.part.0
  16:     0x55729dcd044e - sqlite3VdbeHalt
  17:     0x55729dd3d9ef - sqlite3VdbeExec
  18:     0x55729dd41260 - sqlite3_step
  19:     0x55729d9c6299 - <rusqlite::row::Rows as fallible_streaming_iterator::FallibleStreamingIterator>::advance::he6afd743cddcfe6a
  20:     0x55729d7f13bf - tokio::runtime::task::raw::poll::h5286dd51e43e697a
  21:     0x55729da96a9c - std::sys::backtrace::__rust_begin_short_backtrace::h43336d4b21488a29
  22:     0x55729da986b3 - core::ops::function::FnOnce::call_once{{vtable.shim}}::h5218553105c5c996
  23:     0x55729da69feb - std::sys::pal::unix::thread::Thread::new::thread_start::ha8af9c992ef0b208
  24:     0x7fc2e18ebac3 - start_thread
                               at ./nptl/pthread_create.c:442:8
  25:     0x7fc2e197d850 - __GI___clone3
                               at ./misc/../sysdeps/unix/sysv/linux/x86_64/clone3.S:81
  26:                0x0 - <unknown>
thread caused non-unwinding panic. aborting.
[1]    617431 IOT instruction (core dumped)  sqld --http-listen-addr 127.0.0.1:8081 --snapshot-exec ./snapshot.sh  5

Run sqld 0.24.30 with the provided snapshot.sh and --snapshot-exec command to reproduce the failure. Then inspect libsql-server/src/replication/primary/logger.rs around line 393 and trace the incremental snapshot file swap after snapshot.sh deletes the file; done means the same workflow no longer panics.