The version number shown in the PI only updates via the 'projects' push,
which only fires from onPropertyInspectorDidAppear (i.e. when a
different button is clicked, forcing the PI to re-appear). After
'Check for Updates' completes and the plugin process restarts, an
already-open PI kept showing the pre-update version indefinitely.
Two changes: send a final 'Updated to vX — restarting…' status right
before process.exit(0) so the update message doesn't hang on
'Updating…', and push sendProjectsToPI() once on every plugin startup
(after streamDeck.connect()) so a PI that survived the restart gets
the new version immediately instead of waiting for an unrelated button
click.
The onKeyDown stop/switch paths only cleared memRunningActionId/EntryId
after a successful stopTimer call. If the tracked Notion entry was
already gone (archived/deleted/edited outside the plugin), stopTimer
threw and the stale ID was never cleared -- every subsequent keypress
retried the same doomed stop call, showed a warning triangle, and the
deck got permanently stuck (unable to unselect the stuck button or
start any new timer). checkElapsed already handled this correctly by
clearing state unconditionally; onKeyDown now does the same: stopTimer
failures are logged but non-fatal, and local state clears regardless.
Diagnosed via instrumented logging: the v1.0.44 blocked-press redraw
was calling setState()/setTitle() successfully (no error, confirmed
in logs) but Stream Deck wasn't visually applying it — the corrective
image call was landing too close to Stream Deck's own native
key-press flash animation and getting silently dropped. Forcing a
page navigation away and back always redrew correctly, proving the
tracked state was right all along and this was purely a rendering
timing issue. Adding a 150ms delay before the corrective redraw lets
the native animation settle first; confirmed fixed on device.
Found while testing v1.0.43's icon self-heal: when switching from one
running timer to another, the old Notion entry was stopped but
memRunningActionId/EntryId weren't cleared until AFTER the new
startTimer call resolved. During that gap, a blocked press on the
just-stopped button read the stale (not-yet-cleared) tracked id and
self-healed itself back to a wrongly-'running' green — reinforcing
the exact staleness the self-heal was meant to fix. Now cleared to
null the moment the old timer is actually stopped.
When a keyDown is blocked by the v1.0.42 lock, redraw that button to
match memRunningActionId instead of leaving whatever it was already
showing. This closes the follow-on issue found while testing 1.0.42:
a button's key image can go stale if its Notion timer was ever
stopped/started outside the plugin (e.g. a manual Notion edit), and
a blocked press was leaving that stale image in place — misleading
the user into thinking a timer was running when it wasn't, which
then caused a *real* unintended timer start on the next press.
pendingKeyDown was a Set keyed by action.id, so it only blocked a
button from re-firing itself. Pressing two different buttons in fast
succession (e.g. RB01 then RA01) both passed the guard, both read
memRunningActionId before either had persisted it, and both started
a Notion timer entry. Replaced with a single keyDownBusy flag shared
across all buttons of the action, set synchronously before the first
await, closing the race.
Remove await from running-state updates so onWillAppear cannot
fire between the optimistic setState(1) and the API call completing,
eliminating the green→blue→green flash on button press.
setSettings always resets the button visual state — no workaround
exists. Removed activeEntryId from per-button settings entirely.
Running state now tracked via runningActionId in global settings
(alongside runningEntryId). onWillAppear restores state from
memRunningActionId. onKeyDown only calls setState — clean, instant.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Previously setSettings was awaited first (causing blue flash), then
setState was called. Now both are sent in the same Promise.all so
Stream Deck processes setState in the same batch, overriding the
visual reset from setSettings with no visible blue transition.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
setState was being called after setRunningEntry, which makes two
async global settings calls and takes ~1 second. During that time
the button sat in the blue reset state from setSettings. Now
setState is called immediately after setSettings, before
setRunningEntry, so the blue flash is imperceptibly brief.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
setSettings() resets the visual state in both directions. The start
path already re-asserted setState(1) after setSettings. The stop path
was missing the equivalent setState(0), leaving the button green.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
When pressing B while A was running, B went green immediately but A
stayed green until getGlobal()+getRunningEntryId() resolved. Now uses
settingsCache to turn off all running buttons in the same synchronous
pass as turning B on — no async gap where both appear active.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Visual state change now happens before any async work (getGlobal,
getRunningEntryId, API calls). Previously the button waited for
getGlobal() to resolve before going green, causing a 1-2s delay.
Also reverts optimistic state on API error.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
setSettings() causes Stream Deck to reset the button visual back to
its default state (state 0). The optimistic setState(1) was correct
but got overridden. Now setState(1) is called again after setSettings
completes to ensure the button stays green.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Selecting a name called saveCredentials, which sent refreshProjects,
which re-fetched users and called populateUsers(users, globalUserId)
with globalUserId still empty — immediately clearing the selection.
Fix: saveCredentials now updates globalUserId immediately, and
refreshProjects is only triggered by token changes (scheduleCredSave),
not by name changes.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Previous versions of checkForUpdates only wrote plugin.js, leaving
property-inspector.html stale on all machines that used Check for
Updates. PI fixes (name dropdown, refreshProjects) never reached them.
Now downloads and writes all UI and image assets before restarting.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
onSendToPropertyInspector (users list) arrives before
onDidReceiveGlobalSettings (saved userId) in most cases, leaving
globalUserId empty when populateUsers runs. Now cachedUsers stores
the list, and onDidReceiveGlobalSettings re-populates if users
already arrived — handles both orderings.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
onDidReceiveGlobalSettings fired before the users list was populated,
so the saved userId couldn't be selected. Now stored in globalUserId
variable and applied when populateUsers runs, regardless of order.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Previously staff had to close and reopen the property inspector
after entering their token to trigger the fetch. Now saving the
token immediately sends a refreshProjects event to the plugin,
which fetches and returns the project list and name dropdown.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
GITEA_BASE was pointing at master (v1.0.22), so Check for Updates
always said "already up to date". Now points at stable-rebuild so
updates are served from the correct branch. Also bumps version.json
to 1.0.26.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
- Stop previously running timer globally using persisted runningEntryId,
works across nested folders and plugin restarts
- In-memory cache prevents onWillAppear flash of stale running state
- Replace SVG button icons with Aurora timer PNG icons (on/off)
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Remove onWillDisappear cache pruning so buttons in other folders remain
in settingsCache — previously navigating away deleted their entries,
causing the stop-other-timers loop to miss them on next key press.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Fixes chicken-and-egg setup flow where new users couldn't populate
the name dropdown because isConfigured required userId to already exist.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
pdmarf
