This repository has pull requests disabled (has_pull_requests: false), so I am submitting the tested companion patch here for review.
The bridge deletes execution requests after a fixed 30-second wait. PCB routing
can continue inside EDA, so callers lose late results and may incorrectly repeat
an operation. The window-selection response also references an undefined
activeWindowId variable, causing the request to hang.
Add asynchronous /tasks and /routing submission with queryable stages,
elapsed time, bounded logs, native errors, and final results. Keep the legacy
/execute wait limit but return a task ID on HTTP 504 and retain late results.
Record connection loss as an unknown outcome, verify result ownership, and
preserve the original target window in responses.
Fix the window-selection response and routing documentation field names.
Describe native progress/cancellation limitations and partial routing semantics.
Validation: 13 tests covering HTTP/WebSocket behavior, a real 30-second timeout,
late results, window ownership, partial completion, disconnects, and bounded
history. npm run test:gateway additionally runs 21 compiled-gateway tests and
one HTTP/WebSocket integration test against the companion gateway build.
Native auto routing also passed. Native clearing still hangs in the tested client and is documented
as an unresolved upstream issue.
Native API reproduction: easyeda/pro-api-sdk#38.
This PR retains the operation state; it does not fix or close the native clearing issue.
Reproduce the tests
The patch includes the standalone bridge tests and the compiled-gateway integration harness.
git clone --branch feat/routing-task-observability https://github.com/asmoyou/easyeda-api-skill.git
git clone --branch feat/routing-task-observability https://github.com/asmoyou/eext-run-api-gateway.git
cd eext-run-api-gateway
npm ci
npm run lint
npx tsc --noEmit
npm run build
cd ../easyeda-api-skill
npm ci
npm test
npm run test:gateway
35 tests pass: 13 bridge/task tests, 21 compiled-gateway tests, and one cross-module HTTP/WebSocket test. Native auto routing was verified separately on a minimal PCB with two nets; both were routed. The separate native clearing hang remains unresolved.
The task history is bounded and in memory. Percentage progress and cancellation are not claimed, because the native routing API does not expose them.
This repository has pull requests disabled (
has_pull_requests: false), so I am submitting the tested companion patch here for review.The bridge deletes execution requests after a fixed 30-second wait. PCB routing
can continue inside EDA, so callers lose late results and may incorrectly repeat
an operation. The window-selection response also references an undefined
activeWindowIdvariable, causing the request to hang.Add asynchronous
/tasksand/routingsubmission with queryable stages,elapsed time, bounded logs, native errors, and final results. Keep the legacy
/executewait limit but return a task ID on HTTP 504 and retain late results.Record connection loss as an unknown outcome, verify result ownership, and
preserve the original target window in responses.
Fix the window-selection response and routing documentation field names.
Describe native progress/cancellation limitations and partial routing semantics.
Validation: 13 tests covering HTTP/WebSocket behavior, a real 30-second timeout,
late results, window ownership, partial completion, disconnects, and bounded
history.
npm run test:gatewayadditionally runs 21 compiled-gateway tests andone HTTP/WebSocket integration test against the companion gateway build.
Native auto routing also passed. Native clearing still hangs in the tested client and is documented
as an unresolved upstream issue.
Native API reproduction: easyeda/pro-api-sdk#38.
This PR retains the operation state; it does not fix or close the native clearing issue.
Reproduce the tests
The patch includes the standalone bridge tests and the compiled-gateway integration harness.
35 tests pass: 13 bridge/task tests, 21 compiled-gateway tests, and one cross-module HTTP/WebSocket test. Native auto routing was verified separately on a minimal PCB with two nets; both were routed. The separate native clearing hang remains unresolved.
The task history is bounded and in memory. Percentage progress and cancellation are not claimed, because the native routing API does not expose them.