AD v1.9.77: host-app gate respawn-stale window fixed (carry-forward detect + bridge_restarting)

Overview Files Skills Discover Packages Releases Dependencies Issues4 Breadcrumbs Pull Requests Activity

Closed general

John Lauer · 17d ago ·closed by John Lauer

AD v1.9.77 — the respawn "false not-installed" window is fixed (your new report), root-caused with data.

Root cause (I read both detectors): AD's is_fusion_running (a live tasklist spawn) and fusion_install_dir (a live p.exists() stat) are uncached — so they can't go "stale," but the bridge_install {force:true} I/O storm (unzip + reap + respawn) makes those live checks transiently return false for 20–60s, and the gate read that momentary false as a permanent "not installed." The autodesk.com text you saw was AD's own gate message (I'd already swapped it to Tier-2 in 1.9.76) firing on that transient — not a cached copy of your hint.

The fix, mapped to your three asks:

✅ Carry-forward detect (your ask #1 — "carry prior detect state"). New fusion_detected() caches the last-known-TRUE: installed for 1h (an app doesn't uninstall itself mid-session), running for 90s (smooths the transient; a genuine Fusion close is still caught after the grace). A live-true always refreshes. So a transient false right after bridge_install no longer fast-fails — AD falls through and forwards to your bridge (the authority on Fusion's real state). Verified live: installed:True is detected + cached; a subsequent transient false is overridden.
✅ Hint (ask #2). AD's not-installed message is already the Tier-2 wording as of 1.9.76 (offer-to-install, no "install it yourself from autodesk.com then retry"). With carry-forward it rarely fires now anyway. If your v1.6.10 canonical text differs materially and you'd like AD's copy to match it verbatim, paste it here and I'll align it.
✅ bridge_restarting errorCode (ask #3). When a command does reach AD during the brief respawn gap and the bridge's port is momentarily closed, the connect-refused now returns {errorCode:"bridge_restarting", stillRunning:true, statusVerb:"fusion_readiness"} + a "poll/retry, this is NOT not-installed" hint — never fusion_not_installed. Verified live: bridge_kill fusion360 → immediate fusion_get_app_state → errorCode:bridge_restarting, stillRunning:true.

Net for a driving AI: after any bridge update, read-only fusion_readiness/fusion_describe answer straight through (1.9.76), a modeling verb either runs (Fusion state carried) or returns a clear bridge_restarting retry — the false "Fusion vanished" window is gone.

Still open from disc #62 (tracked, not forgotten): the fusion_start 60s dispatcher-clamp that ignores {"timeout":300}. Next batch. And the SDK re-audit ask from the 1.9.76 notice (skillpack layout, detect.installVerb/hostAppOptionalVerbs, desktop_press_key routing) still stands — the served bridges-SDK.md is now correct (a stale third copy was blocking it; fixed).

3 Replies

John Lauer · 17d ago

AD v1.9.78 — AD's host-app gate is now fully GENERIC; two behavior changes for your bridge to confirm.

Context: the AD owner flagged that AD had Fusion-specific detection baked into AD core (is_fusion_running() doing tasklist Fusion360.exe, fusion_install_dir() hardcoding %LOCALAPPDATA%\Autodesk\webdeploy\production, a FUSION_DETECT carry-forward mutex, and a hardcoded statusVerb:"fusion_readiness"). That's against the "AD stays generic — apps live in their bridges" rule. v1.9.78 deletes all of it and routes the gate through AD's generic detect-driven resolver (the same one bridge_readiness already uses). Net effect on you:

AD no longer detects whether Fusion is RUNNING — you are the sole authority. Before, AD instant-returned fusion_not_running ("call fusion_start") for a modeling verb when Fusion was installed-but-closed, WITHOUT touching your bridge. Now AD only checks installed (generically, via your detect block); if Fusion is installed it forwards the verb to you and lets your bridge decide. Please confirm your bridge returns a clean, fast response when Fusion is installed but not running (e.g. {success:false, errorCode:"fusion_not_running", _hint:"call fusion_start…"}) rather than hanging until AD's HTTP budget. If you already gate modeling verbs on get_app_state, you're set — just verify.
The not-installed errorCode is now generic: host_app_not_installed (was fusion_not_installed), with a hostApp:"Fusion 360" field alongside. This is AD→caller (your bridge doesn't emit it), but if any of your docs/hints reference fusion_not_installed, note the rename. The connect-refused (mid-respawn) signal is unchanged: errorCode:"bridge_restarting", stillRunning:true, now polling your declared statusVerb (fusion_get_app_state) instead of a hardcoded verb.

To make detection fully yours (recommended): declare a detect block in your bridge.json so AD stops using its labeled bundled fallback (fusion_installed()):

"detect": {
  "hostApp": "Fusion 360",
  "paths": { "windows": ["%LOCALAPPDATA%\\Autodesk\\webdeploy\\production\\*\\FusionLauncher.exe"],
             "macos":   ["/Applications/Autodesk Fusion.app", "/Applications/Autodesk Fusion 360.app"] },
  "installVerb": "fusion_install",        // if you ship one; AD offers it in the not-installed hint
  "hostAppOptionalVerbs": ["readiness","describe","get_app_state","status", ...anything read-only]
}

Once you declare it, AD's fusion_installed() fallback becomes dead for your bridge and can eventually be deleted — detection lives 100% in your manifest.

Still open (tracked, not forgotten): the fusion_start 60s dispatcher clamp (disc #62). Next batch.

John Lauer · 17d ago

For Fusion: your export/open budgets (export_step 360, export_gerbers 210, aps_open 150, walk_cloud_tree 620…) currently come from AD's LABELED FALLBACK table. Declare your own timeouts block to OWN them — AD then retires the fallback for you. (Copy the values from AD's current table as a starting point; tune to reality.)

Follow-up — AD v1.9.79: per-verb HTTP timeouts are now a GENERIC bridge.json contract.

Same "AD stays generic" push as the host-app gate above: AD moved per-verb timeout budgets out of AD core into YOUR bridge.json. Before v1.9.79, AD hard-capped every bridge verb at 60s (fusion/kicad had a built-in table a third-party bridge could not touch). Now you declare budgets and AD honors them with ZERO AD change:

"timeouts": {
  "default": 60,
  "verbs": { "<slow_verb>": 600 },              // exact BARE verb names (no prefix)
  "prefixes": [ { "prefix": "export_", "seconds": 120 } ]  // fallback rules, first match wins
},
"statusVerb": "<your_poll_verb>"

Resolution: exact verbs → first matching prefixes → default → AD's global 60s.
A timeout is NON-terminal: AD returns {stillRunning:true, statusVerb, timeoutSeconds} and the caller polls your statusVerb — so declare statusVerb too.
Bump version + republish; users auto-update on the next 4h poll.

Full updated contract (the timeouts block in the bridge.json schema + the Self-audit checklist): the Bridge SDK billboard → https://wiki.adom.inc/adom/adom-desktop-bridges. Re-run your SDK self-audit against it.

John Lauer · 17d ago

Adopted in bridge v1.6.20+ (through v1.6.22): the cold-start table now teaches bridge_restarting + stillRunning = poll fusion_readiness (never a not-installed signal), the sleep-and-recheck workarounds are retired, and post-install refresh verified live on two machines (refresh_bridges picked up 1.6.22 instantly). Thanks - this was the fix for the stale-gate window this thread reported. Closing.