bug: CommandBar.runOnAsyncThread can hang forever when reading TNote bridge fields
@EduardMe y travaille déjà.
Depuis le 28/10/2026.
Évaluation
Cette issue n'a pas encore été évaluée.
Description
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
- Langage dominant
- JavaScript
- Étoiles
- 203
- Forks
- 81
- Merge moyen
- 52 min
- PR mergées (30 j)
- 1
Préparer son environnement
Ce projet ne fournit ni conteneur de développement, ni Dockerfile, ni guide de contribution : l'installation est à votre charge. Commencez par son README, et consultez notre guide de la première contribution pour les étapes générales.
Par où commencer
- Lisez l'issue en entier, puis le guide de contribution du projet.
- Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
- Forkez le dépôt et travaillez sur une branche.
- Ouvrez une pull request qui référence le numéro de l'issue.
Autres issues de NotePlan/plugins
-
Difficulté 2/5 1-3 heures Accessibilité débutants 74/100
-
the todaystart command fails silently if you are working in a splitPeut-être pris @jgclark l’a pris il y a 1 jour. Ouvertebug
NotePlan/plugins#792 · 1 commentaire · 1 personne assignée ·
-
API bug
Difficulté 4/5 3-5 jours Accessibilité débutants 45/100
-
Task Sorting & Tools: support other line typesPeut-être pris @dwertheimer l’a pris il y a 13 jours. Ouverteenhancement
-
getFoldersMatching adds root "/" even when it is not an inclusionPeut-être pris @jgclark l’a pris il y a 13 jours. Ouverte
NotePlan/plugins#788 · 2 commentaires · 1 personne assignée ·
Toutes les issues de NotePlan/plugins
Issues similaires
-
Difficulté 2/5 1-3 heures Accessibilité débutants 85/100
Les mainteneurs répondent en général sous 1 jour
-
Difficulté 2/5 1-3 heures Accessibilité débutants 73/100
microsoft/monaco-editor#5563 ·
Les mainteneurs répondent en général sous 1 jour
-
Package downloads never retry: getUrlWithResuming's retry catch cannot see a rejected requestOuverte
Difficulté 2/5 1-3 heures Accessibilité débutants 85/100
Les mainteneurs répondent en général sous 1 jour
-
account: profile bug
Difficulté 2/5 1-3 heures Accessibilité débutants 78/100
Les mainteneurs répondent en général sous 5 jours
-
ai-driven-fuzzing bug claude Minor
Difficulté 2/5 1-3 heures Accessibilité débutants 78/100
linagora/cozy-client#1777 · 1 commentaire · 1 réaction ·
Les mainteneurs répondent en général sous 1 jour