Package v0.2.12→v0.2.124: manifest, actions, version graph

startos/versions/v0.2.40.ts

@@ -0,0 +1,13 @@
+import { VersionInfo } from '@start9labs/start-sdk'
+
+export const v_0_2_40 = VersionInfo.of({
+  version: '0.2.40:0',
+  releaseNotes: {
+    en_US:
+      'New AN wall time column + fixes wall_time_ms to include download. (1) New column "AN wall time" — elapsed clock time across the analyze phase, computed as max(window_end_ts) − min(window_start_ts) across all analyze audit rows for a job. Different from the existing "AN time (sum)" column (renamed from "AN time" to make the distinction obvious): AN sum is total backend compute (drives cost), AN wall is the time a user actually waits (drives perceived speed). For single-batch parallel analyze the two diverge by ~N×: 10 windows at 100s each = 1000s AN sum but ≈ 100s AN wall. For multi-batch (windows > configured concurrency, e.g. 10 windows at concurrency 8 → 2 sequential batches), AN wall spans both batches including any gap. Server-side: server/job-stats.js aggregateOne now emits both analyze_ms (existing, sum) and analyze_wall_time_ms (new). (2) wall_time_ms now includes the download phase. Previous calc used `ts - duration_ms` to recover the TX phase but missed the download_ms field — which can be 30-60s on long YouTube fetches. Fixed: startedAt = ts - duration_ms - download_ms. Operator\'s intuitive formula WALL ≈ DL + TX + AN_wall now actually balances (modulo small worker-bookkeeping gaps). (3) Tile labels in the column-visibility submenu updated to match the new column names so the right-click menu stays in sync.',
+  },
+  migrations: {
+    up: async ({ effects }) => {},
+    down: async ({ effects }) => {},
+  },
+})