blender - the Blender bridge

ab 2.0.61 is out. One fix in it generalizes to every bridge, and there is a new SDK audit item I need each of you to run.

ab was answering a bridge's verbs itself

John filed adom/adom-bridge#86 against the fusion bridge's verbs. ab core carried its own ~250-line fusion_start that launched Fusion directly, plus its own fusion_dismiss_blocking_dialogs, and only fell back to the bridge when local discovery failed. So on a normal Windows box the bridge's handler never ran. Callers got ab's key set (addinReady, dialogsDismissed) instead of the bridge's (addinConnected, startKind, progress, timings, windowEtiquette).

Both verbs now forward to the bridge first and return its response verbatim. ab's implementation survives only as a labeled fallback for a bridge too old to answer, and says so in _hint.

Why you should care even though this was a fusion verb. The failure is SILENT and it inverts blame. Nothing errors. The caller gets a plausible, well-formed response that simply is not yours. From the outside it reads as "that bridge did not implement the contract" and sends the investigation at your repo instead of mine. In this case ab dropped the fusion bridge's measured progress block on the exact verb the progress rule was written for, one day after that rule went in as REQUIRED. If you had concluded your progress work was not reaching anyone, you might have been right, and it would not have been your bug.

A second tell worth knowing: ab had invented dialogsDismissed, a field that has never existed in the fusion repo. If ab returns a field you have never implemented, that is proof ab is answering, not forwarding.

New SDK audit item: NOT INTERCEPTED

Added to the SDK audit checklist (adom-bridge-sdk-audit), shipping with the next pkg. Stated here so you have it now:

For each of your slowest or most-structured verbs, call YOUR OWN port directly and diff the response key set against the same verb routed through adom-bridge. They must match. If ab's answer is missing fields yours returns, or carries fields you have never implemented, ab core is answering that verb and your handler never ran. Check after ANY ab upgrade.

What I need from you

1. Run that check against your slowest and most structured verbs, especially anything with a lifecycle (*_start, *_open, *_launch, *_close, window or dialog handling). If ab is intercepting anything of yours, reply here with both key sets side by side and I will de-intercept it. I would rather fix these in one batch than one issue at a time.
2. Confirm your progress block now reaches callers. The measured-progress rule (percent, ETA, cold vs warm, confidence:"measured") went into the SDK as REQUIRED on 8/18. If you have implemented it, verify it survives the trip through adom-bridge and not just on your own port. If you have not started it yet, that is the one contract I most want landed.
3. Tell me what else ab is doing to you that you have been working around. Interception is one shape of "ab overstepping". If there is another, I want it filed rather than absorbed.

Also in 2.0.61, relevant only if you have a web surface: the Web Control CORS preflight now reflects the headers a page asks for, so X-Adom-WebControl-Secret no longer fails preflight before reaching the human consent gate (adom/adom-bridge#87, Colby). And a correction to ab's own docs that was misleading people: ab does NOT allow-list web origins. Any page can reach ab over loopback; the per-origin human Allow/Deny prompt is the control.

blender specifically.

Your cold starts and long renders are exactly the case the measured-progress rule exists for, so item 2 above is the one I care most about from you. A render or a heavy scene load with no percent and no ETA is the worst version of "is it working or is it hung" for a user.

blender_run_python is also one of the exec-class verbs gated by the bridge-declared risk field rather than a hardcoded name in ab. If you have not declared risk in your bridge.json, do that, so ab gates you generically instead of me being tempted to special-case Blender in core.