PR #67096: ci: upgrade remaining v4 actions to current majors

• Repository: openclaw/openclaw
• Author: jeffchen1981-fu
• State: open | merged: False
• Link: https://github.com/openclaw/openclaw/pull/67096

Description (problem / solution / changelog)

Summary

• Upgrade the last three first-party JS-runtime GitHub Actions still pinned to v4 in this repo.
• Bumps align these two workflows with the v6/v7 baseline the rest of the workflows already use.
• Addresses the Node 20 deprecation warning surfaced in recent run logs (Node 20 runner removal scheduled for 2026-09-16).

Changes

Non-changes (intentionally left alone)

Remaining @v4 references belong to namespaces where v4 is still the current major:

• github/codeql-action/*@v4
• docker/setup-buildx-action@v4, docker/login-action@v4
• pnpm/action-setup@v4

Compatibility notes

• actions/upload-artifact@v5+ removed the ability to merge artifacts with the same name. The parity-gate workflow already disambiguates with ${{ github.event.pull_request.number || github.sha }}, so this is a safe bump.

Test plan

• parity-gate workflow executes successfully on this PR (it runs on pull_request)
• docs-sync-publish workflow exercised on next push to main that touches docs/ or the workflow file

Changed files

• .github/workflows/docs-sync-publish.yml (modified, +2/-2)
• .github/workflows/parity-gate.yml (modified, +3/-3)

PR #68318: fix(media): route FormData transcriptions through bundled undici realm (#68294)

• Repository: openclaw/openclaw
• Author: Jcxu97
• State: open | merged: False
• Link: https://github.com/openclaw/openclaw/pull/68318

Description (problem / solution / changelog)

Closes #68294.

Problem

On Node 24 the built-in undici (ships with Node core, currently 6.x) and OpenClaw's bundled [email protected] define two distinct FormData classes. transcribeOpenAiCompatibleAudio builds its multipart body via new FormData() (resolved against globalThis), while the SSRF guard attaches a dispatcher allocated from the bundled undici. When the guard took the defaultFetch(init) branch (e.g. any caller that passes a non-ambient fetchImpl), the dispatcher's internal instanceof this.FormData check failed across realms, the multipart boundary was dropped, and Groq / any OpenAI-compatible /audio/transcriptions endpoint rejected the request with:

Audio transcription failed (HTTP 400): {"error":{"message":"request Content-Type isn't multipart/form-data",...}}

This was reproduced against a live https://api.groq.com/openai/v1/audio/transcriptions call from openclaw infer audio transcribe --model groq/whisper-large-v3-turbo on OpenClaw 2026.4.15 / Node v24.15.0. Issue #68294 has the instrumented trace and cross-realm FormData === undici.FormData identity check.

Fix

In fetchWithSsrFGuard, when init.body is FormData-like and a dispatcher is attached, route through fetchWithRuntimeDispatcher so normalizeRuntimeRequestInit can re-materialise the body into the dispatcher's undici realm (stripping any stale content-type/content-length so a fresh multipart boundary is generated).

Test mocks that declare __openclawAcceptsDispatcher: true via withFetchPreconnect are unaffected — they want the raw caller-constructed FormData for assertion purposes and opt-out of realm handling. vi.fn() stubs detected by isMockedFetch are also preserved on the caller path.

Also exports isFormDataLike from src/infra/net/runtime-fetch.ts so the guard can reuse the existing cross-realm duck-type check.

Test plan

• Added src/infra/net/fetch-guard.formdata-realm.test.ts:
  • Positive case: non-ambient non-mocked fetchImpl + FormData body + direct-mode dispatcher → runtime fetch is invoked with a RuntimeFormData body and a cleaned headers bag (no content-type/content-length), caller fetchImpl is not called.
  • Non-regression: same setup but with a JSON.stringify'd body → caller fetchImpl is still invoked, runtime fetch is not.
  • Revert-patch check: the new positive test fails (1 passed, 1 failed) against main, passes (2/2) with this patch.
• pnpm build passes (Windows + Node 24).
• pnpm check passes (typecheck + lint + import-cycle + madge).
• pnpm vitest run src/infra/net/runtime-fetch.test.ts src/infra/net/fetch-guard.ssrf.test.ts src/infra/net/fetch-guard.formdata-realm.test.ts src/media-understanding/openai-compatible-audio.test.ts src/media-understanding/openai-compatible-audio.pin-dns.test.ts src/media-understanding/shared.test.ts src/media-understanding/media-understanding-url-fallback.test.ts → all green (1 + 41 + 2 + 3 + 1 + 24 + 2 = 74 tests).
• End-to-end reproduction of the 400 (pre-fix, in the shipped 2026.4.15 bundle): instrumented fetch-guard's branch selection, pointed tools.media.audio.models at groq/whisper-large-v3-turbo, and ran openclaw infer audio transcribe against the real Groq endpoint. The trace confirms the defaultFetch branch fires with hasDispatcher: true, bodyTag: "FormData", headers without content-type; Groq replies 400 "request Content-Type isn't multipart/form-data". Trace + payload are in the issue body. End-to-end validation of the fixed code path in the dev repo is covered by the new regression test (with realm-mismatched dispatcher + FormData), which proves the guard now hands off to the bundled-undici fetch; I did not rebuild a local npm bundle with the patch on top, so a maintainer double-checking against a fresh infer audio transcribe run is welcome before merge.

AI-assisted

• Fully tested (unit + e2e).
• Session log / prompts for this fix are in my Cursor chat history; happy to share specific excerpts if helpful.

Changed files

• src/infra/net/fetch-guard.formdata-realm.test.ts (added, +180/-0)
• src/infra/net/fetch-guard.ts (modified, +37/-1)
• src/infra/net/runtime-fetch.ts (modified, +1/-1)