When a message has a saved (kept) image, changing any of the metadata fields like "hidden from AI", "hidden from user", etc. can sometimes cause the saved image to disappear and show as blank. Editing the message text itself seems fine, it's specifically the behind-the-scenes fields that trigger it. The saved image data is still in the database (in customData.__savedImages), keyed by the exact prompt string including the uniqueness tag ((img0:0), (img1:0), etc.). Something in the re-render flow after a metadata update seems to strip or mismatch that key, so the image lookup fails. Worth checking around line 6672 where (imgN:0) tags get stripped for AI context. if that stripping somehow touches the stored message string rather than just a copy, the key would no longer match what's saved in __savedImages. This bug might seem unlikely to hit in normal usage, but there's a pretty natural scenario where it comes up. Say someone generates an image with the intention of deleting it later, but the generation comes out perfect by luck. They decide to keep it but also want to hide the message from the AI so it doesn't see it in the chat context. So it's not a common occurrence. To reproduce: generate an image, keep it, then change any hiddenFrom option on that message and confirm. Sometimes the image will be gone.
Side note: also noticed that clicking the 🖼️ Image button sometimes generates images with a completely empty prompt (example of what gets stored: (img1:0)), resulting in random unrelated images. Didn't check exact cause.
1 Comments
perchance@lemmy.world · 5 pts · 161d
Thanks for your detailed investigation here. I'm not sure, but I think editing "hidden from AI" / etc. is actually just triggering a re-render, which "shows" the issue, rather than actually causes it.
One possibility is that you're using some custom code in that character that (likely via
oc.messageRenderingPipeline) purposefully/inadvertantly edits the prompt inside the<image>...</image>tag, which would cause a mismatch.I was thinking I could match it via a heuristic like just checking
(imgN:0)if the initial__savedImagesexact-prompt-match fails, but I think that would mean editing the message to change an image prompt wouldn't work - i.e. it'd just load the stale one rather than loading the new one. I could maybe makeimgNincrement for any prompt that's manually edited, but I haven't thought that through fully and my suspicion is that that gets a bit iffy. I think we do need to keep exact-match, and if so, then any custom code that 'renders' a message (oc.messageRenderingPipeline) shouldn't touch anything inside<image>tags. Same goes for custom code that edits the actual content of a message of course.Thanks! Fixed.