Skip to content

Reliability: fix result correlation (ES3 toISOString) + read-only bridge-status probe#33

Open
juansilvadesign wants to merge 1 commit into
Dakkshin:mainfrom
juansilvadesign:fix/bridge-reliability
Open

Reliability: fix result correlation (ES3 toISOString) + read-only bridge-status probe#33
juansilvadesign wants to merge 1 commit into
Dakkshin:mainfrom
juansilvadesign:fix/bridge-reliability

Conversation

@juansilvadesign

Copy link
Copy Markdown

Summary

The file-based bridge couldn't reliably tell a fresh result from an old one, which made the very first "is this even working?" diagnosis painful. This PR fixes the root causes and adds a read-only way to confirm the panel is alive. All changes are backward-compatible.

What was broken

  1. toISOString throws in ExtendScript. The panel stamps each result via new Date().toISOString(), but ExtendScript's Date is ES3 and has no toISOString. The call throws, the surrounding try/catch swallows it, and the result is written without its correlation fields (_commandExecuted, _responseTimestamp). That silently broke waitForBridgeResult(), which matches on _commandExecuted — so, for example, the compositions resource could only ever time out.
  2. Staleness was judged by wall-clock mtime. get-results returned "Result file appears to be stale" whenever the result file's mtime was more than 30s old. On a shared/mounted bridge dir (e.g. WSL /mnt/c driving Windows AE) clock skew and simple re-reads trip that on perfectly correct data.
  3. No read-only liveness check. The only "is the panel alive?" tool, run-bridge-test, applies effects to the open project.

Changes

  • Add an ES3 toISOString polyfill in the panel so result-stamping succeeds.
  • Correlate results to requests by a per-command commandId (echoed back by the panel as _commandId) instead of wall-clock mtime. get-results and waitForBridgeResult now match on it, and the false "stale" path is gone. If the panel predates the field, it falls back gracefully to returning the raw content.
  • Add bridge-status — a read-only liveness probe (ping) that reports whether the panel is open and its round-trip latency, without mutating the project.
  • Support AE_MCP_BRIDGE_DIR so the server and panel can rendezvous on a shared folder when the MCP host and After Effects run in different OS contexts (WSL ↔ Windows). The panel honours the same variable via $.getenv.

Testing

npm run build (esbuild) passes; the panel .jsx passes a syntax parse. The bridge round-trip and bridge-status were exercised against After Effects 2024 on Windows, driven from Node in WSL.

Notes

A companion PR (community tool bundle) lives in a separate branch to keep this one focused on reliability.

🤖 Generated with Claude Code

…probe

The bridge could not reliably tell a fresh result from a stale one, which made
initial diagnosis painful. Root causes and fixes:

- ExtendScript's Date has no toISOString (ES3), so the panel's result-stamping
  threw and was swallowed, writing results WITHOUT their correlation fields. Add
  an ES3 toISOString polyfill so stamping succeeds.
- Correlate results to requests by a per-command `commandId` (echoed back by the
  panel as `_commandId`) instead of a wall-clock "file older than 30s" heuristic,
  which false-positives on shared/mounted bridge dirs (e.g. WSL /mnt/c) and on
  simple re-reads. get-results and waitForBridgeResult now match on commandId.
- Add `bridge-status`: a read-only liveness probe (ping) that reports whether the
  panel is open and its round-trip latency, WITHOUT mutating the project (unlike
  run-bridge-test, which applies effects).
- Support `AE_MCP_BRIDGE_DIR` to point both sides at a shared bridge folder when
  the MCP host and After Effects run in different OS contexts (WSL <-> Windows).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant