`failed to parse compact revision: strconv.ParseInt: parsing ""` error message repeated in logs following upgrade

[EP3UV2KyFG]

Environmental Info:
K3s Version:
k3s version v1.35.1+k3s1 (50fa2d7)
go version go1.25.6

Node(s) CPU architecture, OS, and Version:
Debian Bookworm - 6.1.0-43-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.162-1 (2026-02-08) x86_64 GNU/Linux

Cluster Configuration:
Single server with embedded SQLite (default configuration)

Describe the bug:
After upgrading from K3s v1.34.1+k3s1 to v1.35.1+k3s1, the cluster logs continuous errors every second related to parsing the compact revision:

E0215 09:43:39.094814 3513 compact.go:265] etcd: endpoint ([unix://kine.sock]): failed to parse compact revision: strconv.ParseInt: parsing "": invalid syntax

The root cause is a missing database migration in Kine. The format of the value column in compact_rev_key and compact_rev_key_apiserver rows changed between Kine v0.14.0 (bundled with K3s v1.34.1) and v0.14.11 (bundled with K3s v1.35.1):

Entry	Old format (Kine v0.14.0)	New format (Kine v0.14.11)
compact_rev_key	empty (data in prev_revision column)	0|<revision>
compact_rev_key_apiserver	<counter>	<counter>|<revision>

The new Kine version expects a pipe-delimited value but the existing database has the old format, causing strconv.ParseInt to fail when parsing an empty string.

Steps To Reproduce:

• Initial installation some time ago, not sure with which version I started.
• Upgraded to K3s v1.34.1+k3s1
• Cluster ran normally for some time with default SQLite backend
• Upgraded to v1.35.1+k3s1
• Restarted k3s with systemctl restart k3s
• Error appears continuously every second in logs

Expected behavior:
Kine should automatically migrate the compact_rev_key and compact_rev_key_apiserver value columns to the new format on startup, or the upgrade documentation should mention this migration step.

Actual behavior:
The error failed to parse compact revision: strconv.ParseInt: parsing "": invalid syntax is logged every second. The cluster appears to function but with continuous error spam and potential performance impact from retry loops.

Additional context / logs:

Verification that the database is intact but has old format:

# compact_rev_key has empty value column
sqlite3 /var/lib/rancher/k3s/server/db/state.db "SELECT id, name, prev_revision, length(value) FROM kine WHERE id = 1;"
# Returns: 1|compact_rev_key|12035781|0

# compact_rev_key_apiserver entries have old format (no pipe delimiter)
sqlite3 /var/lib/rancher/k3s/server/db/state.db "SELECT id, name, value FROM kine WHERE name = 'compact_rev_key_apiserver' ORDER BY id DESC LIMIT 1;"
# Returns: 14938860|compact_rev_key_apiserver|53525
# Expected format: 53525|14938860

Workaround:

systemctl stop k3s

# Fix compact_rev_key (id=1)
sqlite3 /var/lib/rancher/k3s/server/db/state.db \
  "UPDATE kine SET value = '0|' || prev_revision WHERE id = 1 AND name = 'compact_rev_key';"

# Fix ALL compact_rev_key_apiserver entries with old format
sqlite3 /var/lib/rancher/k3s/server/db/state.db \
  "UPDATE kine SET value = value || '|' || prev_revision WHERE name = 'compact_rev_key_apiserver' AND length(value) < 10;"

# Commit WAL changes
sqlite3 /var/lib/rancher/k3s/server/db/state.db "PRAGMA wal_checkpoint(TRUNCATE);"

systemctl start k3s

Or have I done something wrong when upgrading? Thanks!

[brandond]

There shouldn't be any "migration" necessary. The code that handles the parsing should handle reading either format, and does not return any errors from ParseInt. The "migration" will occur on first compact, which will write a value with the new format.

https://github.com/k3s-io/kine/blob/v0.14.11/pkg/server/compact.go#L123-L134

Its possible that there is some other place that is directly accessing the value where it should instead be using the helper function... we can take a look.

[brandond]

This message is actually coming from the apiserver, not kine:
https://github.com/kubernetes/kubernetes/blob/v1.35.1/staging/src/k8s.io/apiserver/pkg/storage/etcd3/compact.go#L283-L292.

The message repeats once per second until compact is triggered by the new version of kine, at which point compact_rev_key_apiserver gets set. This will happen 10 minutes (2x 5 minute apiserver compact interval) after K3s startup:

Feb 17 19:22:30 systemd-node-001.example.com k3s[3219]: E0217 19:22:30.082055    3219 compact.go:265] etcd: endpoint ([unix://kine.sock]): failed to parse compact revision: strconv.ParseInt: parsing "": invalid syntax
Feb 17 19:22:31 systemd-node-001.example.com k3s[3219]: E0217 19:22:31.083964    3219 compact.go:265] etcd: endpoint ([unix://kine.sock]): failed to parse compact revision: strconv.ParseInt: parsing "": invalid syntax
Feb 17 19:22:32 systemd-node-001.example.com k3s[3219]: E0217 19:22:32.085489    3219 compact.go:265] etcd: endpoint ([unix://kine.sock]): failed to parse compact revision: strconv.ParseInt: parsing "": invalid syntax
Feb 17 19:22:33 systemd-node-001.example.com k3s[3219]: E0217 19:22:33.087249    3219 compact.go:265] etcd: endpoint ([unix://kine.sock]): failed to parse compact revision: strconv.ParseInt: parsing "": invalid syntax
Feb 17 19:22:33 systemd-node-001.example.com k3s[3219]: time="2026-02-17T19:22:33Z" level=info msg="COMPACT compactRev=74 targetCompactRev=831 currentRev=1831"
Feb 17 19:22:33 systemd-node-001.example.com k3s[3219]: time="2026-02-17T19:22:33Z" level=info msg="COMPACT deleted 346 rows from 757 revisions in 39.896818ms - compacted to 831/1831"
Feb 17 19:22:33 systemd-node-001.example.com k3s[3219]: time="2026-02-17T19:22:33Z" level=info msg="COMPACT compacted from 74 to 831 in 1 transactions over 40ms"

Since this self-resolves after a few minutes, and doesn't cause any problems other than log spam, I don't think it is a critical issue. That said, I think we should be able to address it for the March release.