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.
onKeyDown is async and calls await startTimer (~1s network). A second
press before that resolves saw the same state (isRunning=false,
memRunningEntryId=null) and created a second Notion entry. Only the
last startTimer call's ID was tracked, orphaning the first entry
running indefinitely in Notion.
pendingKeyDown Set acts as a per-action mutex: a second press while the
first is in-flight is dropped. try/finally guarantees the lock is always
released.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
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>
Both buttons now flip to their final visual state immediately on key
press, before any API calls. Previously the old button stayed green
throughout the stopTimer network round-trip (~0.5–2s), causing a
window where both buttons appeared green simultaneously.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Stream Deck plugin settings panel was showing "version 1" because
manifest.json had a hardcoded "Version": "1.0.0".
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Known-good state: blue icons, cross-folder timer fix, name dropdown.
Versioned above master (1.0.22) so auto-updater does not overwrite.
Install script points at stable-rebuild branch.
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
