You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
@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?
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.
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.
Activity
[-]Database getting corrupted on powerloss.[/-][+]Database getting corrupted on power loss[/+]penberg commentedon Jul 12, 2026
@roboturso triage
roboturso commentedon Jul 12, 2026
@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 commentedon Jul 12, 2026
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 commentedon Jul 12, 2026
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 commentedon Jul 12, 2026
penberg commentedon Jul 12, 2026
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 commentedon Aug 18, 2026
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.