@caius_kong/ccusage-dashboard 0.2.20 → 0.2.22

package/lib/index.html

@@ -346,10 +346,9 @@ async function rangeApply(){
 }
 
 async function loadTrend(){
-  const d=await(await fetch("/api/trend?days=30")).json();
-  if(d.error){return;}
-  drawTrend(d.days||[]);
-  $("trendSum").textContent=fmtUsd((d.days||[]).reduce((a,x)=>a+(x.totalCost||0),0));
+  // Used by the resize redraw and first paint; a failed trend must not surface
+  // as an unhandled rejection (auxTick reports status via the tick() indicator).
+  try{renderTrend(await fetchTrend());}catch(e){}
 }
 
 function drawTrend(days){
@@ -415,12 +414,30 @@ async function fetchMonth(){
   return d;
 }
 
+async function fetchTrend(){
+  const d=await(await fetch("/api/trend?days=30")).json();
+  if(d.error)throw new Error(d.error);
+  return d;
+}
+
+function renderTrend(d){
+  drawTrend(d.days||[]);
+  $("trendSum").textContent=fmtUsd((d.days||[]).reduce((a,x)=>a+(x.totalCost||0),0));
+}
+
 async function tick(){                 // the active view + the sessions panel
   const dot=$("dot"),st=$("status");
   try{
-    if(active==="range")await rangeApply();
-    else await loadModels();
-    await loadSessions();
+    // These two hit independent endpoints with independent caches and render
+    // into different panels, so run them together. Awaiting one before starting
+    // the other would make a cold tick cost `today + sessions` worth of scans
+    // (~13-24s each) — close enough to the 60s refresh window to risk the next
+    // tick arriving before this one finishes. The server's run gate is sized for
+    // exactly this small overlap.
+    await Promise.all([
+      active==="range"?rangeApply():loadModels(),
+      loadSessions(),
+    ]);
     dot.className="dot ok";st.textContent="live";
     $("lastUpd").textContent="last updated "+new Date().toLocaleTimeString();
   }catch(e){dot.className="dot err";st.textContent="error: "+e.message;}
@@ -428,8 +445,10 @@ async function tick(){                 // the active view + the sessions panel
 
 async function auxTick(){              // always-visible panels: budget + 30d trend
   try{
-    applyBudget(await fetchMonth());
-    await loadTrend();
+    // Independent endpoints again: fetch both, then render.
+    const [month,trend]=await Promise.all([fetchMonth(), fetchTrend()]);
+    applyBudget(month);
+    renderTrend(trend);
   }catch(e){/* status is reported by tick() */}
 }
 

package/lib/server.py

@@ -81,12 +81,9 @@ BUDGET = 300.0  # monthly cap in USD (override via --budget or CCUSAGE_BUDGET)
 # the heavier reports cost ~12-16 CPU-seconds each and are rarely watched, so
 # they re-scan a tenth as often. Inactive views are never polled at all.
 #
-# A value here is the refresh PERIOD, not a from-now duration: an entry is valid
-# until the end of its period (see run_ccusage), so a request at the next period
-# boundary always finds it stale and triggers exactly one fresh scan. That makes
-# the refresh cadence independent of how long a scan happens to take — with a
-# plain "now + ttl", a scan finishing `runtime` after the tick would keep the
-# entry alive past the next tick and silently halve the refresh rate.
+# A value here is the refresh PERIOD, not a length of time an entry is kept.
+# run_ccusage expires entries slightly before their period elapses, so each new
+# period triggers exactly one fresh scan regardless of how long a scan takes.
 _REFRESH_INTERVAL = 60   # browser poll interval; must match lib/index.html
 _SLOW_INTERVAL = 600     # cadence for the non-default views
 TTL = {
@@ -100,9 +97,17 @@ TTL = {
 
 # A transient failure is remembered only briefly: long enough that concurrent
 # waiters share it instead of each retrying, short enough that the endpoint
-# recovers quickly rather than staying broken for a whole TTL.
+# recovers quickly rather than staying whole a full period.
 _ERROR_TTL = 30
 
+# Entries expire this many seconds before their period ends, so the next poll of
+# the same cadence always triggers a fresh scan. Measured from the REQUEST, so it
+# does not care when the scan started. The entry stays valid for
+# `period - _EXPIRY_MARGIN` seconds, which must exceed the total time until a
+# scan's data exists (queueing delay + runtime) or the entry would expire on
+# write — keep the margin small and the period comfortably above one scan.
+_EXPIRY_MARGIN = 5
+
 # --- optional self-update check (purely user-triggered) ----------------------
 # The dashboard is otherwise fully offline: it makes a network request ONLY when
 # the user clicks the "check update" button in the UI. A short debounce stops
@@ -120,15 +125,22 @@ _last_check = None  # (timestamp, result dict) — debounce + last outcome
 def run_ccusage(args: list[str], ttl: float) -> dict:
     """Run ccusage and cache the JSON report under its argv for one `ttl` window.
 
-    ``ttl`` is a refresh PERIOD, and an entry stays valid until that window ends
-    (`expires_at` is the next `ttl` boundary, not `now + ttl`). Stamping a
-    from-now duration instead would make the effective cadence `runtime + ttl`,
-    i.e. a scan that finishes 12s after a 60s tick would keep its entry alive
-    past the next tick and halve the refresh rate.
+    ``ttl`` here is a refresh PERIOD (the cadence the browser polls this report
+    at), and the entry is made to expire just before that period elapses — see
+    _EXPIRY_MARGIN. Expiry is measured from the REQUEST time (the tick), not from
+    when the scan happened to start, so queueing behind other scans cannot push
+    an entry past the next tick and silently double the cadence.
+
+    Two failure modes this avoids:
+
+    * Stamping the pre-run clock gave an entry a lifetime of `ttl - runtime`,
+      i.e. negative when a run outlasted its period, so the cache never hit and
+      every poll re-executed ccusage.
+    * Anchoring to the wall clock ("end of the current minute") expires an entry
+      on write whenever a run starts near a boundary.
 
-    The boundary is anchored to when the scan STARTS, so successive windows tile
-    the clock exactly: a request at the next period boundary always finds the
-    entry stale and triggers one fresh scan, no matter how long the scan took.
+    Post-condition for any run shorter than `ttl - _EXPIRY_MARGIN`: the entry is
+    valid now, and stale by the next poll of the same cadence.
 
     Requests for the same key are coalesced (single-flight): the first caller
     runs ccusage and the rest wait for its result, so N concurrent misses spawn
@@ -147,11 +159,11 @@ def run_ccusage(args: list[str], ttl: float) -> dict:
             if waiter is None:
                 waiter = threading.Event()
                 _inflight[key] = waiter
+                requested_at = now
                 break
         waiter.wait()  # someone else is already running this exact key
     try:
         with _run_gate:
-            started = time.time()
             try:
                 proc = subprocess.run(
                     resolve_ccusage() + args,
@@ -164,9 +176,11 @@ def run_ccusage(args: list[str], ttl: float) -> dict:
                 data = {"error": f"{exc}"}
         is_error = isinstance(data, dict) and bool(data.get("error"))
         window = _ERROR_TTL if is_error else ttl
-        # Expire at the end of the window the scan STARTED in, so windows tile the
-        # clock and the next request triggers exactly one fresh scan.
-        expires_at = (int(started / window) + 1) * window
+        # Expire just before this period ends, measured from the REQUEST, so the
+        # next poll of this cadence always finds it stale even if the scan was
+        # queued behind others. Never let the margin swallow a short window.
+        margin = min(_EXPIRY_MARGIN, window / 4)
+        expires_at = requested_at + window - margin
         with _lock:
             _cache[key] = (expires_at, data)
         return data
@@ -690,14 +704,18 @@ def main() -> None:
         # back-to-back for no benefit.
         #
         # Only reports the browser asks for on load are pre-warmed: the default
-        # view (today), the two always-visible panels (budget=month, 30-day
-        # trend). week/range are omitted on purpose — the UI only fetches them
-        # when the user switches to that tab, so warming them would be a wasted
+        # view (today), the always-visible panels (budget=month, 30-day trend)
+        # and the sessions list, which the first tick also requests. Pre-warming
+        # sessions matters: otherwise it queues behind the other three cold scans,
+        # and a queued run can finish too late to serve the next tick.
+        # week/range are omitted on purpose — the UI only fetches them when the
+        # user switches to that tab, so warming them would be a wasted
         # full-history scan at every boot.
         jobs = [
             lambda: run_ccusage(["daily", "--last", "1", "--json", "--offline"], TTL["/api/today"]),
             lambda: run_ccusage(["monthly", "--last", "1", "--json", "--offline"], TTL["/api/month"]),
             lambda: trend(30),
+            lambda: sessions(period="today"),
         ]
         threads = [threading.Thread(target=job) for job in jobs]
         for t in threads:

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@caius_kong/ccusage-dashboard",
-  "version": "0.2.20",
+  "version": "0.2.22",
   "description": "One-command local dashboard for ccusage: today/week/month/custom cost by model, 30-day trend, monthly budget alert. Numbers straight from ccusage.",
   "license": "MIT",
   "type": "commonjs",