Database getting corrupted on power loss

[silent-sixth-cargo]

Database getting corrupted, there was a powerloss, the database got currepted, even when there were no active transaction being written, had to remove it.
sqlite and sql database like mariadb completely fine.

Error: Internal Error: EOF while parsing a value at line 1 column 0

Caused by:
EOF while parsing a value at line 1 column 0

[penberg]

@roboturso triage

[roboturso]

@roboturso triaged this issue but needs more information to attempt a reproduction: The error indicates an empty JSON file (likely a sync replica '-info' metadata file) was parsed, but the report doesn't say which Turso version, binding/CLI, or database setup was in use, and the quoted 'Internal Error' string doesn't exist in this codebase — could you share the Turso version, how the database was opened (CLI or which language binding, plain vs. synced), and a listing (with sizes) of the database's files (db, -wal, -info) after the power loss?

[penberg]

Hey @silent-sixth-cargo! Thanks for the report. As @roboturso asks here, can you provide bit more information on what you are doing?

[silent-sixth-cargo]

image: ghcr.io/tursodatabase/libsql-server:latest
runtime: containerized (likely pulled the latest published version as of the initial bug report)
environment:
SQLD_HTTP_LISTEN_ADDR: ${SQLD_HTTP_LISTEN_ADDR}
SQLD_DB_PATH: ${SQLD_DB_PATH}
volumes:
- "../data:/var/lib/sqld"
As reported by docker logs turso:
Error: Internal Error: EOF while parsing a value at line 1 column 0
Caused by:
EOF while parsing a value at line 1 column 0;

with hands on integration of many database types, never a single database caused this issue even when were actively being streamed. i tried out turso seeing report from fireship, even build out single binary solution that can connect and interact with database from webapp as db-gate does not support libsql connection, but it's no where near production ready yet! specially at storage and integrity layer.

mariadb has went through rough standby electricity issue, but never caused issue handling my private git repo.
when thinking about database it's the first one that comes to mind.

[silent-sixth-cargo]

[penberg]

Hey @silent-sixth-cargo, note that I moved the issue from https://github.com/tursodatabase/turso here. The libSQL server is in deep maintenance mode and we no longer run it on Turso Cloud on AWS, but instead have a proprietary server: https://turso.tech/blog/turso-cloud-goes-diskless

[janus-reith]

Just ran into this. Zero-byte stats.json, server refused to start and deleting the empty file fixed it. If I understand correctly, your PR fixes both the read path, but also ensuring the empty file scenario doesn't come up in the first place by waiting for a real fsync before renaming to stats.json

In my case it wasn't my homelab but a managed container hosting service. I don't have a complete picture yet, but I suspect it had more to do with their network volumes than with a power outage.