wezterm losing image ids with kitty graphics

[dankamongmen]

What Operating System(s) are you seeing this problem on?

Linux X11

WezTerm version

20210919-182757-8f0ab02b

Did you try the latest nightly build to see if the issue is better (or worse!) than your current version?

No, and I'll explain why below

Describe the bug

I'm using the last version I could build off main. I tried the nightly on my Debian workstation, and it showed the same behavior.

I'm attaching a file. By inspection, it is "well-formed" according to the Kitty protocol. Start a new wezterm and cat it. You ought see five images, 1 significantly smaller than the other 4. Here's an example of the expected output:

I haven't locked things down any further than the following procedure, but it's repeatable. I'm thinking it's related to whatever structure you use to track graphics; I conjecture maybe you have an LRU in there, and when it gets big and comes back down with some out-of-order, your data stricture gets out of whack. Either way:

• run notcurses-demo
• cat the file again

it might take a few times, but you will see

 2021-09-20T11:56:12.317Z ERROR wezterm_term::terminalstate::performer > kitty_img: no matching image id
 2021-09-20T11:56:12.318Z ERROR wezterm_term::terminalstate::performer > kitty_img: no matching image id

with one "missing" corresponding to each missing square (of the 5). there will likewise be at least one pruned image message.

happycrappy.txt

i'll try to narrow this down further.

To Reproduce

see above

Configuration

local config = {
  warn_about_missing_glyphs = false,
  enable_kitty_graphics = true,
}
return config

Expected Behavior

see above; i do not expect to see any images pruned when catting the file happycrappy.txt

Logs

i'll get these for ya

Anything else?

No response

[dankamongmen]

Just noting that I'm still running into this with the current wezterm, 20211021-185611-04768fd1.

I've attached lru.txt, which reproduces the failure once the cache has started to prune. The best way to reproduce this that I've found is to run notcurses-demo all the way through, then cat this file.

lru.txt

[wez]

This should be resolved now in main.

It typically takes about an hour before commits are available as nightly builds for all platforms. Linux builds are the fastest to build and are often available within about 20 minutes. Windows and macOS builds take a bit longer.

Please take a few moments to try out the fix and let me know how that works out. You can find the nightly downloads for your system in the wezterm installation docs.

If you prefer to use packages provided by your distribution or package manager of choice and don't want to replace that with a nightly download, keep in mind that you can download portable packages (eg: a .dmg file on macOS, a .zip file on Windows and an .AppImage file on Linux) that can be run without permanently installing or replacing an existing package, and can then simply be deleted once you no longer need them.

If you are eager and can build from source then you may be able to try this out more quickly.

[github-actions]

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues. If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.