have a heading linked in 7 places inside the file and another link in a separte file
rename the heading
Often the rename will freeze for seconds (maybe tens of seconds)
After the modal closes, the process stays at over 100% CPU and sluggish (mostyl unresponsive)
The operation takes too long - suggest a bug in the rename implementation
The operations takes exponentially longer if heading is linked multiple times - suggests a bug in the rename implementation (possibly the same as the first one. check recursion?)
The operation is not transactional. Changes still hapen after modal closes. While the modal seems to take a while to dissappear, once it’s closed, changes will still take place after, further corrupting the file. As renames change non-local context, they should never be completely async. I.e. I should never get back to editor if tasks are still running
Possibly adding rows during this time contributes to the corruption
I expect rename to not delete my data, nor insert garbage
Actual result
Rename
Environment
SYSTEM INFO:
Obsidian version: v1.6.4
Installer version: v1.4.13
Operating system: Darwin Kernel Version 23.5.0: Wed May 1 20:12:58 PDT 2024; root:xnu-10063.121.3~5/RELEASE_ARM64_T6000 23.5.0
Login status: logged in
Catalyst license: supporter
Insider build toggle: on
Live preview: on
Base theme: light
Community theme: Minimal v7.3.2
Snippets enabled: 2
Restricted mode: on
RECOMMENDATIONS:
Custom theme and snippets: for cosmetic issues, please first try updating your theme and disabling your snippets. If still not fixed, please try to make the issue happen in the Sandbox Vault or disable community theme and snippets.
Additional information
I tried to reproduce it synthetically by creating a file with several headings and wasn’t able to.
I’m able to reproduce when copying the large file to a new file and repeating the operation
I was able to reproduce the problem partially (shared recording privately).
The rename operation hangs locking the UI with CPU at 100%. As the UI remains unresponsive, I wasn’t able to make changes in the document and I suspect the concurrent changes cause the corruption.
This said, in the sanbox, sometimes it doesn’t reproduce and, when it doesn’t, it’s actually fast, as you describe. This would be the case with a race condition.
Is there any debug logging or tracing flag I can enable?
While I don’t have much time to fiddle with the sanbox, I’m getting incrementally slower behavior on my main repo and I suspect these are connected (here’s a related post Events observation and control for performance - #2 by clehene)
It would be easier to track it down in my main valut