bug: CommandBar.runOnAsyncThread can hang forever when reading TNote bridge fields
@EduardMe arbeitet bereits daran.
Seit 28.10.2026.
Bewertung
Dieses Issue wurde noch nicht bewertet.
Beschreibung
Summary
CommandBar.runOnAsyncThread() (NotePlan 3.21.3+) can leave its Promise unresolved forever when the sync callback reads live NotePlan note objects (TNote / note.content / note.paragraphs / frontmatter) via the plugin bridge. Plugin code that awaits the result never resumes, so finally cleanup (e.g. CommandBar.showLoading(false)) never runs and UI progress dialogs stay stuck.
We have now hit this twice in np.Shared cache rebuilds.
Observed behaviour
1. Tag / mention cache (Dashboard install rebuild)
User vault ~1667 calendar + ~4844 regular notes. Dashboard onUpdateOrInstall forced a tag/mention cache rebuild, which scans notes inside runOnAsyncThread via our helper runSyncWorkOnAsyncThread.
Log sequence:
generateTagMentionCache :: - processing 1667 calendar + 4844 regular notes ...
generateTagMentionCache :: - scanning 1667 calendar notes ...
runSyncWorkOnAsyncThread :: generateTagMentionCache calendar: starting on async thread
Then nothing: no async thread finished, no completion / error path, no showLoading(false).
Progress UI (CommandBar.showLoading) updated every 100 notes and stuck at:
Generating tag/mention cache: reading calendar note 1600/1667
(That count only means note 1600 was reached; the next UI tick would be 1700. Hang is somewhere after that progress update -- later notes and/or returning from the async callback.)
Meanwhile the main plugin thread kept accepting other Dashboard work (windowReload, showDashboardReact, section refreshes), which is consistent with the background job never completing while onUpdateOrInstall stayed parked on await generateTagMentionCache(...).
2. Notes-changed-recently cache (earlier, same API)
Reading a few TNote fields inside runOnAsyncThread during generate/update left Projects Refresh spinning indefinitely. We worked around it in np.Shared 1.3.1 by keeping that cache on the main thread, with comments documenting that bridge field reads inside the async API hung the Promise live.
What we already ruled out / worked around on the plugin side
- Returning large objects from the async callback previously also hung the Promise (scan finished,
awaitnever resumed). Tag/mention cache now only returns a primitive (true) and stores results in outer variables. That did not prevent this hang. CommandBar.showLoadingfrom inside the callback is documented as allowed and did update for a long time before the hang.- This does not look like a simple "vault too big / slow" case: progress advanced through ~1600 notes, then the Promise never settled.
Ask
Please confirm whether reading live note bridge objects from CommandBar.runOnAsyncThread is unsupported, or whether this is a platform bug.
If unsupported, docs should say so explicitly (safe work = plain data only; gather TNote fields on the main thread first).
If supported, we need the Promise to always settle (resolve or reject) even when note-field reads fail or deadlock, so plugins can clear loading UI and recover.
Workaround plugins are using
Until this is reliable, Shared Resources will avoid runOnAsyncThread for loops that read live TNote fields (main-thread scan + showLoading progress), same as the notes-changed-recently cache.
Environment
- API:
CommandBar.runOnAsyncThread(feature gated from 3.21.3) - Plugins:
np.Sharedtag/mention cache + DashboardonUpdateOrInstallforced rebuild - Repro scale: ~6.5k notes in the reported vault
- Vorherrschende Sprache
- JavaScript
- Sterne
- 203
- Forks
- 81
- Ø Merge
- 52 Min.
- Gemergte PRs (30 T.)
- 1
Entwicklungsumgebung
Dieses Projekt bietet weder Dev-Container noch Dockerfile noch Beitragsleitfaden – die Einrichtung liegt bei Ihnen. Beginnen Sie mit der README; die allgemeinen Schritte stehen in unserem Leitfaden für den ersten Beitrag.
Erste Schritte
- Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
- Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
- Forken Sie das Repository und arbeiten Sie in einem Branch.
- Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.
Mehr aus NotePlan/plugins
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 74/100
-
the todaystart command fails silently if you are working in a splitEvtl. vergeben @jgclark hat das vor 2 Tagen übernommen. Offenbug
-
API bug
Schwierigkeit 4/5 3-5 Tage Anfängerfreundlichkeit 45/100
-
Task Sorting & Tools: support other line typesEvtl. vergeben @dwertheimer hat das vor 14 Tagen übernommen. Offenenhancement
-
getFoldersMatching adds root "/" even when it is not an inclusionEvtl. vergeben @jgclark hat das vor 14 Tagen übernommen. Offen
NotePlan/plugins#788 · 2 Kommentare · 1 zugewiesene Person ·
Alle Issues in NotePlan/plugins
Ähnliche Issues
-
Let TypeScript accept an initial object in ReactiveDictEvtl. vergeben @yograj-vijay-yadav hat das heute übernommen. Offenbug good first issue help wanted workshop
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 92/100
meteor/meteor#14919 · 1 Kommentar ·
Maintainer antworten meist innerhalb von 1 Tag
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 65/100
akitaonrails/FrankMD#268 ·
Maintainer antworten meist innerhalb von 1 Tag
-
account: profile
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 75/100
Maintainer antworten meist innerhalb von 5 Tagen
-
Schwierigkeit 1/5 Unter einer Stunde Anfängerfreundlichkeit 82/100
mfreed7/xslt_polyfill#65 ·
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 82/100
Maintainer antworten meist innerhalb von 1 Tag