Skip to content

Releases: zoispag/omniroute-tray

v0.1.14

Choose a tag to compare

@github-actions github-actions released this 23 Jul 13:10
Immutable release. Only release title and notes can be modified.
fe9e36b
v0.1.14 — periodic background quota refresh

v0.1.13

Choose a tag to compare

@github-actions github-actions released this 09 Jul 21:02
Immutable release. Only release title and notes can be modified.
f419502
Fix update-button staleness and Running→Error status flapping (#24)

* Re-check npm registry periodically for omniroute updates

check_for_update only ran once at the end of bootstrap(), so a release
published while the app sat in Running was never noticed until the next
app relaunch. That's why an adopted instance (fresh launch = fresh
bootstrap = fresh registry check) showed the update button while a
long-running spawned instance did not.

Add a 30-minute recheck loop, spawned once at app setup (not in
bootstrap, which re-runs on Restart Server and would leak a loop per
restart). It only nudges Running/UpdateAvailable states, never
clobbering Starting/Updating/Error.

* Re-check for updates when recovering from a slow cold start

bootstrap() only runs check_for_update when wait_ready succeeds within
20s. On a fresh spawn (e.g. after killing both the tray and omniroute),
a slow cold start lands in Error, monitor_health later flips it back to
Running — but the update check was skipped and never retried. That is
the exact repro: adopted instance shows the button (ready=true is
instant, check always runs), while a spawned-after-kill instance does
not. Run check_for_update on the recovery transition too.

* Stop flapping Running->Error on a single busy health probe

Opening settings with a cold cache fires get_rate_limits, which walks
/api/providers plus one sequential /api/usage/{id} per account. That
keeps omniroute's single event loop busy long enough for the health
monitor's 2s probe to miss — and one missed probe flipped the state to
Error, then straight back to Running on the next poll.

Two fixes: the monitor now uses server_responding (any HTTP reply means
alive — a degraded health status is still a responding server), and it
requires 3 consecutive missed probes (~15s) before declaring Error.
Recovery stays immediate. wait_ready/server_present keep the strict
server_healthy check, which is right for startup readiness.

v0.1.12

Choose a tag to compare

@github-actions github-actions released this 08 Jul 09:13
Immutable release. Only release title and notes can be modified.
bb80cb2
Add granular Cost period selector (1D/7D/30D/Yesterday/Today), a
loading skeleton, model-name truncation, and control layout-shift
fixes in the Cost section. See #23.

v0.1.11

Choose a tag to compare

@github-actions github-actions released this 07 Jul 13:51
Immutable release. Only release title and notes can be modified.
2cda617
v0.1.11

v0.1.10

Choose a tag to compare

@github-actions github-actions released this 07 Jul 12:44
Immutable release. Only release title and notes can be modified.
7bfd48c
v0.1.10

v0.1.9

Choose a tag to compare

@github-actions github-actions released this 07 Jul 11:59
Immutable release. Only release title and notes can be modified.
884be3f
v0.1.9

v0.1.8

Choose a tag to compare

@github-actions github-actions released this 07 Jul 07:52
Immutable release. Only release title and notes can be modified.
25270c8
v0.1.8

v0.1.7

Choose a tag to compare

@github-actions github-actions released this 06 Jul 13:45
Immutable release. Only release title and notes can be modified.
8efdf14

v0.1.6

Choose a tag to compare

@github-actions github-actions released this 06 Jul 12:29
Immutable release. Only release title and notes can be modified.
bdd82c5
v0.1.6: re-verify active install on launch, self-heal broken markers

v0.1.5

Choose a tag to compare

@github-actions github-actions released this 06 Jul 11:45
Immutable release. Only release title and notes can be modified.
a1001f9
v0.1.5: verify omniroute install before marking complete (fixes empty…