[BUG] Same-character chat switching can mix chat identity and trigger cross-chat integrity failures / data loss
Environment
Termux
System
Android 16 / Termux / Samsung Internet + Chromium. SillyTavern server is running locally through Termux and accessed through the browser at 127.0.0.1.
Version
1.18.0 release
Desktop Information
- Node.js version: v24.13.0
- Generation API: Chat Completion / NanoGPT
- Branch: release
- Model: GLM 5.x family
- Host: Termux on Android 16
- Client: Samsung Internet + Chromium
- Chat integrity checking: enabled
- SillyTavern server instances: 1
Describe the problem
Here's a media file of the issue. I'm having issues uploading the video on here.
https://www.mediafire.com/folder/nqqrhy8ayco21/ST_Glitch
I have multiple separate chats belonging to the same character that I frequently switch between while testing presets. Intermittently, switching between these same-character chats results in a cross-chat integrity mismatch. In several earlier occurrences, a populated chat was ultimately replaced with only its metadata/header and a newly instantiated character greeting.
I have now caught the failure live before the destructive write completed.
Example:
- Chat A: "Romeo Reyes - 5.4.jsonl"
- Chat B: "Romeo Reyes - Ember.jsonl"
- Both are separate, ordinary chats belonging to the same character.
During the reproduced failure, the server reported that an attempted save of "Romeo Reyes - Ember.jsonl" expected an integrity UUID associated with the other Romeo chat (5.4).
The server log showed:
File "data/default-user/chats/Romeo Reyes/Romeo Reyes - 5.4.jsonl" does not have integrity metadata matching "d4a068a2-a3d3-4aca-9f3e-1ab0394e3dc9". The integrity validation has been skipped.
Immediately afterward:
Chat integrity check failed for "data/default-user/chats/Romeo Reyes/Romeo Reyes - Ember.jsonl". The expected integrity slug was "d4a068a2-a3d3-4aca-9f3e-1ab0394e3dc9".
The existing Ember file has a different integrity UUID.
This suggests that during a same-character chat switch, the active filename/save target and in-memory chat metadata can temporarily refer to different chats.
This is particularly relevant because saveChatDebounced() guards against this_chid changing, but switching between two chats belonging to the same character does not change this_chid.
Earlier destructive occurrences resulted in the affected JSONL files containing exactly two valid records: the chat metadata/header followed by a newly instantiated copy of the character's first greeting. This resembles fresh-chat initialization rather than random filesystem truncation.
I previously encountered the separate #5941 failure mode. I applied a local defensive patch for that read-error pathway and verified it using an injected read failure: the existing chat survived unchanged. The same-character integrity mismatch described here still occurs with that protection present, suggesting that there is an additional pathway.
Expected result:
Switching between two chats belonging to the same character should never allow state or metadata from Chat A to be saved to Chat B's filename.
Actual result:
An attempted save of Chat B can carry an integrity identity associated with Chat A. Integrity checking sometimes catches and blocks the write. Earlier occurrences resulted in populated chats being reset to metadata/header + character greeting.
Approximate reproduction:
- Have multiple independent chats belonging to one character.
- Open Chat A.
- Switch to Chat B belonging to the same character.
- Navigate between these chats normally.
- Intermittently, a save targets Chat B while carrying an integrity identity associated with Chat A.
The issue appears timing-sensitive and does not occur on every switch.
Additional info
Potentially related issues:
- #5941 — /api/chats/get read failure can be interpreted as an empty chat. I have separately tested a local defensive patch for this pathway; the current same-character integrity reproduction still occurs.
- #5942 — describes a same-character chat identity issue involving saveChatDebounced() checking chid but not the chat filename in the branch/checkpoint context. My reproduction involves ordinary independent chats belonging to the same character rather than branches.
- #5864 — discusses whole-chat stale writes and limitations of integrity UUIDs as identity rather than revision protection.
I have video recordings showing the failure occurring in the UI together with corresponding Termux/server logs. I have also preserved the affected JSONL files and can provide sanitized copies if useful.
In one live reproduction, integrity checking prevented the attempted cross-chat write and produced:
Chat integrity check failed for "data/default-user/chats/Romeo Reyes/Romeo Reyes - Ember.jsonl". The expected integrity slug was "d4a068a2-a3d3-4aca-9f3e-1ab0394e3dc9".
That UUID was also associated with the other same-character chat involved in the transition, while Ember's existing file contained a different integrity UUID.
I did NOT select OVERWRITE when SillyTavern presented the integrity warning.
The issue has occurred multiple times with this character, for whom I maintain many separate chats because I use them for preset testing. I have not observed the same destructive behavior with characters for whom I do not frequently switch among multiple chats.
NOTE: This installation currently contains third-party extensions and a local defensive patch for #5941. The integrity mismatch has reproduced with Chat Recap disabled, so that extension is not required for this occurrence. I am reporting the environment accurately rather than claiming third-party extensions have been completely ruled out.
Here's a media file of the issue. I'm having issues uploading the video on here.
https://www.mediafire.com/folder/nqqrhy8ayco21/ST_Glitch
Please tick the boxes
- I have explained the issue clearly, and I included all relevant info
- I have checked that this issue hasn't already been raised
- I have checked the docs
- I confirm that my issue is not related to third-party content, unofficial extension or patch. If in doubt, check with a new user account and with extensions disabled
Source: SillyTavern/SillyTavern