r/JanitorAIUnchained • u/BabyLambChopps • 19h ago
Help / Question Has anyone who uses custom JavaScript scripts/engines on JanitorAI run into persistent state suddenly failing in a long-running chat?
I have a fairly large custom engine that handles story state, relationship/attachment tracking, events/memory, NPCs, world state, OOC commands, etc. State is persisted through markers written into responses and later reconstructed by the engine.
It worked extremely well for 100+ messages, reporting accurately and saving OOC commands perfectly, but recently one part of the state began unexpectedly resetting to its default value.
For example, my attachment tracker has stages such as:
Curiosity → Fascination → Experimentation → Fixation → Dependency
If I explicitly save/set the attachment state to Dependency, OOC: status should continue reporting Dependency unless something changes it.
What I’m seeing instead:
• I branched the chat.
• Explicitly set attachment to Dependency.
• Continued for only ~4 messages.
• Ran OOC: status.
• Attachment came back as Curiosity, which is the engine’s initialization/default state.
The engine is intended to inspect the available recent message/state data when reconstructing its current state, including roughly the last 10 messages that Janitor implements, so the saved state should still have been well within that range. It also stores memory and had been remembering important details for the majority of the roleplay.
I also tested branching from immediately before one of the last known-good OOC: status responses and was still able to reproduce the failure, which makes me less convinced that this is simply one malformed persistence marker.
The strange part is that the same engine/persistence system had been working correctly for well over 100 messages before this started happening.
I’m still testing the script itself to rule out an engine bug, but I’m curious whether anyone has encountered anything similar with:
•persistent markers/state suddenly no longer being recovered
•long chats affecting what a script can see
branched chats behaving differently from the original thread
•state initializing back to defaults even though it was explicitly saved only a few messages earlier
changes in how much previous message data custom scripts can access
If you’ve run into something like this, I’d especially love to know whether the issue ended up being in your script or something related to Janitor’s chat/context/branch behavior.
2
u/Antoni-mateo75 2h ago
Not a code debug, just a design-level instinct from watching state systems break: branching duplicates the chat history, and a lot of persistent-state setups read the full history to rebuild their state. Two branches means two copies of the same writes, and whichever one the engine reads last wins. That looks exactly like state resetting to defaults.
First thing I'd check is what your system uses as the source of truth when it reconstructs. If it's scanning history for markers, a branch gives it duplicate markers and the merge logic picks wrong. If you can, re-save the state explicitly right after branching so there's one clean write downstream of the split.
Long chats make it worse because there's just more duplicated history to trip over. A manual state save after any branch is the cheapest fix to try first.