tsa.db issue when upgrading to kumomta.2025.05.06.055544.b29689af

get-help
1

I just upgraded from version 2024.11.08.103708.d383b033 to 2025.05.06.055544.b29689af and actually the tsa-daemon failed to start on apparently a hash incompatibility… I understand from the documentation that quite a bit was change in the tsa daemon. but I did not expect this:

May 20 20:25:39 smtp-out2 tsa-daemon[1880423]: #033[2m2025-05-20T20:25:39.054865Z#033[0m #033[32m INFO#033[0m localset-0 #033[2mkumo_server_common::http_server#033[0m#033[2m:#033[0m http listener on 0.0.0.0:8008
May 20 20:25:39 smtp-out2 tsa-daemon[1880423]: #033[2m2025-05-20T20:25:39.055097Z#033[0m #033[33m WARN#033[0m localset-0 #033[2mtsa_daemon::state#033[0m#033[2m:#033[0m Failed to load state from /var/spool/kumomta/tsa.db.state, proceeding with fresh state. Error was: No such file or directory (os error 2)
....
May 20 20:25:38 smtp-out2 tsa-daemon[1880394]: thread 'localset-1' panicked at crates/tsa-daemon/src/state.rs:92:13:
May 20 20:25:38 smtp-out2 tsa-daemon[1880394]: invalid action hash ahash=smtp-virtualmail2->mxs.activeby.net@smtp_client-d9c711171d5d0809fa9d6c45e624b25b269fb5303630c89f95b5dd46e09ef03d Invalid string length
May 20 20:25:38 smtp-out2 tsa-daemon[1880394]: note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

Now I do use my self compiled Debian12 packages. But the cargo build is a tagged git checkout with no changes on it.. then a debian asset builder for a debian install package. (Packages found: KumoMTA – Kwenie Data Consultancy)
I did do a rustup before building the tag 2025.05.06.055544.b29689af

Just to let you know this happened.. After removing /var/spool/kumomta/tsa.db and restarting kumo-tsa-daemon it just started and kumomta also started without issues.

4

https://github.com/KumoCorp/kumomta/issues/382 I see the same issues.

5

oh yeah I did not check the github issues yesterday, I guess I should have. But then again… for those upgrading and experienceing the same issue.. the solution is to delete the tsa.db en you should be fine.

6

I think the only problem with deleting tsa.db is that shapping the previously stored data is lost and needs to be stored again.
Not sure why I upgraded from version 2024.11.08.103708.d383b033 to 2025.05.06.055544.b29689af did not encounter this error.

7

It might depend on what is stored as a hash in that tsa.db

8

TSA is holding counters to know when to trigger different automations, which it then sends to the KumoMTA nodes. Those nodes receive the change to make and the duration of the change, so generally speaking you don’t lose much when you wipe the file and restart.

9

It sounds like there is a record in that db that doesn’t match expectations somehow (maybe due to the naming of your sources?). If we could get a copy of the offending row it would be possible to dig deeper and resolve this, but the workaround of moving aside or deleting the db is conceptually “OK” because the equivalent state from the old storage will be rebuilt as you continue to send more traffic.

10

I just updated a second server, which actually had the same issue… removed tsa.db and it all started happily.