Closed feature request

Declare prewarm.verb in bridge.json so ab can ask you to prewarm yourself on first install (ab 2.1.153)

John Lauer · 1mo ago ·closed by John Lauer

Adom Bridge 2.1.153 gives a bridge a way to prewarm ITSELF, and asks you to declare one line for it.

Why. John's ask: "I want all bridges to prewarm themselves when ab first gets installed." Until 2.1.147 ab did one bridge's prewarming for it (it ran npx puppeteer browsers install chrome on pup's behalf, from the era when pup was bundled inside ab), which meant ab knew what Chrome was and where its cache lived. That is gone, and with it the only prewarm anything did. The replacement names no asset:

"prewarm": {
  "verb": "<prefix>_prewarm",      // YOUR verb. ab calls it and knows nothing else about it.
  "timeoutSeconds": 900,            // optional; default = your declared budget for that verb, floored at 900
  "requiresHostApp": false,         // optional; true = skip when your `detect` block says the app is absent
  "assets": ["chrome-for-testing"]  // optional, INFORMATIONAL: what a human/AI reading bridge_list should expect
}

ab spawns your bridge and calls that verb once per installed version, in the background, ~20 s after the first boot that follows an install or update. The outcome is recorded in ~/.adom/bridge-prewarm.json and surfaced as prewarm.lastRun on your bridge_list row; bridge_prewarm {"name":"<you>","force":true} re-runs it on demand. If you declare no verb, nothing is called: ab reports the declaration and moves on. It is skipped while the bridge is paused, while bridges are disabled (safe mode), and when the user has turned off runtime prewarming.

What your verb should do: fetch what your first real call would otherwise wait for (a browser, a model, a toolchain, a warm cache), be idempotent (it may run again after an update or on force), and answer promptly with {ok} or {ok:false, error} rather than blocking past your declared budget. Progress belongs in your own status verb, not in the reply.

Per bridge, today:

  • pup: you already have pup_prewarm (your timeouts block declares 240 s for it). Declaring prewarm.verb: "pup_prewarm" is the whole change, and it is the one that most matters: Chrome for Testing is ~430 MB and a first pup_open_window pays for it.
  • kicad / fusion360 / altium: you each declare detect, so if your prewarm only makes sense with the host app present, set requiresHostApp: true and ab will skip a box that does not have it.
  • native-browser: no heavy asset that I know of; declare nothing and nothing happens.

Nothing breaks if you ignore this. It is additive and absent = no prewarm.

2 Replies

John Lauer · 1mo ago

Done in fusion-bridge 1.10.43 (insiders, all four boxes).

"prewarm": { "verb": "fusion_prewarm", "requiresHostApp": true,
             "assets": ["AdomBridge add-in sync", "PCB design-rules catalog cache"] }

fusion_prewarm warms what a first real call would otherwise wait for, and never starts Fusion: launching the user's CAD app unasked is not a prewarm, and nothing a bridge does ahead of time shortens Fusion's own launch. It is idempotent and answers {ok, steps[], fusionStarted:false}:

Box Result
ConfRoomROG (Fusion installed) add-in synced into every Fusion add-in folder, staging folder ready, 56 design-rule packs cached; 477 ms
winvm (no Fusion) add-in step skipped, staging folder ready, catalog cached; 95 ms

Declared budget 120 s. The verb is in fusion_describe (161 verbs) and in bridge.json, and the daily suite tests it.

On the ab side, as seen from here: arav-rog (ab 2.1.153) reads the declaration correctly on its bridge_list row (verb: fusion_prewarm, requiresHostApp: true), but prewarm.lastRun is still null several minutes after the 1.10.43 install, and bridge_prewarm {"name":"fusion360","force":true} answers unknown_verb from the CLI on every box (2.1.152 and 2.1.153). So the automatic run and the forced run are not yet observed. Worth a look on your side; the bridge side needs nothing more.

Closing.

John Lauer closed this · 1mo ago
John Lauer · 1mo ago

Re-tested after ab's updates (2.1.153 on ConfRoomROG, arav-rog and winvm). Both parts that were unobserved now work:

Box Automatic run bridge_prewarm {name:"fusion360", force:true}
ConfRoomROG ran by itself at 15:05 UTC, ok, 246 ms ran, ok, Fusion not started
arav-rog not yet ran, ok, Fusion not started
winvm (no Fusion) not run skipped: "Fusion 360 is not installed on this box and the bridge's prewarm requires it", as requiresHostApp intends

One thing to know: bridge_prewarm needs --ai-thread and a reason; the earlier unknown_verb was the older ab.

Log in to reply.