GCS replica writes hang indefinitely on v0.5.16/v0.5.17 during a v0.3.x → v0.5.x migration (works fine on v0.3.13)

Bug Description

Hello, I have a project where I migrated data from PostgreSQL to SQLite. Migration was succesful and chose litestream for backup reasons. I have begun with v0.3.13 but later wanted to upgrade to 0.5.17. While migrating a v0.3.x GCS replica to v0.5.x, seeding the new LTX-format data with litestream replicate never completes — no error, no timeout, it just hangs indefinitely. The identical setup works in ~1-2s on v0.3.13.

Environment

Litestream version:

0.5.17

Operating system & version: macOS 15.7.9

Installation method: running via official litestream/litestream Docker image

Storage backend: GCS

Steps to Reproduce

1. Have a production bucket path already populated by v0.3.13 (generations/<id>/snapshots/*.snapshot.lz4, .../wal/*.wal.lz4 — the pre-LTX layout).
2. Restore current data with v0.3.13 into a local file (works fine, ~577KB db here).

docker run --rm \
    -v "$HOME/.config/gcloud:/root/.config/gcloud:ro" \
    -e GOOGLE_APPLICATION_CREDENTIALS=/root/.config/gcloud/application_default_credentials.json \
    -v /tmp:/out \
    litestream/litestream:0.3.13 \
    restore -o /out/cutover-source.db gcs://mybucket/existing-v3-path

577536 Sep  5 10:19 cutover-source.db
 32768 Sep  5 10:19 cutover-source.db.tmp-shm
     0 Sep  5 10:19 cutover-source.db.tmp-wal

1. Point v0.5.17 at the same bucket path with that restored file as source:

docker run --rm \
  -v /path/to/cutover-source/folder:/data \
  -v "$HOME/.config/gcloud:/root/.config/gcloud:ro" \
  -e GOOGLE_APPLICATION_CREDENTIALS=/root/.config/gcloud/application_default_credentials.json \
  litestream/litestream:0.5.17 \
  replicate /data/mydata.db gs://mybucket/existing-v3-path

Expected behavior: Initial LTX snapshot completes within seconds and new files appear under the bucket path — as happens replicating the same file to a local file:// replica, and as v0.3.13 does against this same GCS bucket/credentials/path.

Actual behavior:

time=2026-09-04T20:06:51.854Z level=INFO msg=litestream version=v0.5.17 level=INFO
time=2026-09-04T20:06:51.857Z level=INFO msg="initialized db" path=/data/cutover-source.db
time=2026-09-04T20:06:51.857Z level=INFO msg="replicating to" type=gs sync-interval=1s bucket=existing-v3-path path=mydb
time=2026-09-04T20:06:51.857Z level=INFO msg="starting compaction monitor" system=store level=2 interval=5m0s
time=2026-09-04T20:06:51.857Z level=INFO msg="starting compaction monitor" system=store level=9 interval=24h0m0s
time=2026-09-04T20:06:51.857Z level=INFO msg="starting compaction monitor" system=store level=1 interval=30s
time=2026-09-04T20:06:51.857Z level=INFO msg="starting L0 retention monitor" system=store interval=15s retention=5m0s
time=2026-09-04T20:06:51.857Z level=INFO msg="starting compaction monitor" system=store level=3 interval=1h0m0s

No further output. Waited up to 3 minutes; no "snapshot complete" line ever appears, and no new objects land in the bucket. Separately, on some runs I also saw this repeating warning:

level=WARN msg="timeout waiting for db initialization" system=store level=1 dbs=[/data/mydata.db] timeout=30s hint="database may have corrupted local state or blocked transactions; try removing -litestream directory and restarting"

Configuration

I was running restore/replication from local machine before push to production. This configuration is ready for 0.5.17.

dbs:
  - path: /data/mydata.db
    replica:
      type: gs
      bucket: ${LITESTREAM_GCS_BUCKET}
      path: mydb

This one was for 0.3.x:

dbs:
  - path: /data/mydata.db
    replicas:
      - type: gcs
        bucket: ${LITESTREAM_GCS_BUCKET}
        path: mydb

Logs

Attached above

Additional Context

• Same restored file → local file:// replica: succeeds in ~2s.
• Same GCS bucket/path/credentials → litestream/litestream:0.3.13: succeeds in ~1-2s.
• GCS restore (read) with 0.5.17: works fine and fast.
• Plain gcloud storage cp to the same bucket: works in ~2s.
• Reproduces identically against a brand-new, never-used bucket path with a trivial synthetic database — so it is not specific to the existing v0.3.x data, database size, or database content.
• Ruled out: bucket IAM, quota-project misconfig (found and fixed one, no change in behavior).
• Reproduces identically on v0.5.16 and v0.5.17.

Related but not identical: #877, #933, #989.