"Refusing the destructive short id repair" on starting tuwunel

[dogarrowtype]

Tuwunel version

1.9.0

Installation method

Static binary from a release

Platform and OS

Debian 13 x86_64 and also Alma Linux 10 x86_64

Database origin

Created by Tuwunel

What happened?

I get a persistent warning in the log that tells me to report this upstream. This seems to be related to the 1.9.0 database migration update.
The server this database goes to is pretty active. It has been the same database since installing tuwunel fresh in 02-2026.

Steps to reproduce

No response

Expected behavior

No response

Relevant log output or configuration

2026-09-10T04:52:58.546806Z  INFO main:start:open: tuwunel_database::engine::open: Opened database. columns=133 sequence=133606143 time=212.490279ms
2026-09-10T04:52:58.581156Z  INFO main:start: tuwunel_service::migrations::injectivity::scan: Scanning ShortID columns for duplicate values...
2026-09-10T04:52:59.394059Z  INFO main:start: tuwunel_service::migrations::injectivity::scan: Finished scanning column pair. forward=eventid_shorteventid reverse=shorteventid_eventid rows=276417 losers=0 dangling=0 promotable=0 contended=0 unresolved=0 malformed=0
2026-09-10T04:52:59.396138Z  INFO main:start: tuwunel_service::migrations::injectivity::scan: Finished scanning column pair. forward=statekey_shortstatekey reverse=shortstatekey_statekey rows=109 losers=1 dangling=0 promotable=0 contended=0 unresolved=0 malformed=0
2026-09-10T04:52:59.682879Z  WARN main:start: tuwunel_service::migrations::injectivity::scan: Swept the deeper short id indexes. dirty=0 entries=0 infected=6 ghosts=6 removed_ghosts=0 orphans=0 missing_parents=0 infected_parents=9 malformed_diffs=0 moves=0 relations=0
2026-09-10T04:52:59.683458Z  WARN main:start: tuwunel_service::migrations::injectivity::repair: Refusing the destructive short id repair; the nonzero counts name shapes it does not handle. Please report this line upstream, since the scan repeats each boot until a release handles them. dangling_events=0 dangling_statekeys=0 promotable_events=0 promotable_statekeys=0 contended_events=0 contended_statekeys=0 unresolved_events=0 unresolved_statekeys=0 malformed_event_keys=0 malformed_statekey_keys=0 orphan_entries=0 missing_parents=0 infected_parents=9 malformed_diffs=0

[jevolk]

Thank you for reporting. We have recorded and analyzed this very rare condition. Currently no repair exists either on 1.9.0 or main branch because the complexity of such repair outweighs the effects of these incorrect records, which we were unsure even existed until this report. I'm having a look again at what it would take to do this repair now that we received this. The small number of affected records indicate an extremely low chance of any noticeable impact, which would likely occur in historical room state.

In any case, I advise upgrading to main branch or the upcoming 1.9.1 release which won't re-run the repair attempt on every restart. If you don't restart frequently waiting for 1.9.1 shouldn't be a problem. Unfortunately it is unlikely a fix for this will be ready in time for 1.9.1.

[dogarrowtype]

I see, thank you for the response!
Should I be concerned, leaving the database in this state? I'm not sure what the function of ShortID is, so it's hard to tell how much of a problem this is. If it's just 9 random old messages that will never load and also never cause a problem, that is completely fine. It's more of a concern to me if it's a time bomb where if a user tries to load one of these corrupted messages, the server crashes. (I haven't noticed any crashes or strange behavior).
Is this some kind of corruption that will spread? Or is it limited to only extremely rare old messages/events?
If there's a way I can locate the problematic messages and just remove them from the database to restore it to a clean state, I would prefer to do that rather than let this error sit.

[jevolk]

We can't tell from this report what room_id(s) are affected or what state is involved. The most likely scenario is that 6 members of a room will be missing. If they are current members with activity in a room you are still joined to, you may see auth rejection warnings or errors in your logs. In a highly improbable case, the state may be more essential to the room where you'll see more frequent warnings and errors, far and above normal federation noise. No crash or further corruption is possible.

[dogarrowtype]

I see. I wonder if this is maybe related to a room deletion from months ago. I deleted 1 or 2 rooms using one of the admin commands maybe around March, and got many errors from it. The rooms were not deleted cleanly at all, from what I remember. They eventually cleared but were stuck in a sort of limbo state.
There's no users obviously missing from any rooms as far as I can tell. If that's the only thing to be looking for, then I think the errors are not impacting the actual function of the server.

[jevolk]

Almost certainly not related to room deletions. Ironically something I checked to determine if deleting a room was an alternative to a repair, but the delete routines don't cover this.