WASM SDK functional tests fail with gRPC-Web "missing trailer" against local dashmate gateway

[shumkov]

Expected Behavior

yarn workspace @dashevo/wasm-sdk test:functional should pass against the
local dashmate network started by ./.github/actions/local-network. This job
runs as Packages functional tests / Run functional tests in CI whenever
version-changed=true (release bumps + any PR touching root Cargo.toml).

Current Behavior

Every WASM SDK functional test fails with the same root error:

grpc error: code: 'Unknown error', message: "protocol error: missing
grpc-status trailer, stream was terminated without a final status
(possible truncation by a proxy or load balancer)"

84 tests fail; 18 raw trailer errors and 74 downstream "no available
addresses to use" / 10 "expected null to exist" cascades — all from the
same underlying issue.

Wallet + SDK functional tests (yarn workspace @dashevo/wallet-lib test:functional and yarn workspace dash test:functional) pass against
the same gateway endpoint (https://127.0.0.1:2443) in the same job, just
before the WASM SDK suite runs.

Possible Solution

The WASM SDK uses tonic_web_wasm_client::Client (see
packages/rs-dapi-client/src/transport/wasm_channel.rs:16), which speaks
gRPC-Web over fetch and expects trailers encoded as a final
0x80-prefixed body frame. JS Wallet/SDK functional tests use native gRPC
over HTTP/2 (real HTTP trailers) and work fine.

Most likely the dashmate local gateway either:

1. Doesn't apply envoy's grpc_web filter at the 2443 listener, so
   responses come back as native gRPC with HTTP/2 trailers (invisible to
   fetch).
2. Has middleware between dapi and the gateway that strips the body-frame
   trailer.

Possible fix paths (any one):

• Server: enable/repair envoy grpc_web filter on the local-network
  gateway so trailers are emitted as the body frame tonic-web-wasm-client
  expects.
• Client: switch the WASM SDK's transport to a non-fetch-based path
  when running under Node (e.g. tonic over native HTTP/2 in
  cfg(not(target_arch = "wasm32")) mode, which the rs-dapi-client crate
  already has — extend it to cover the Node-mocha + WASM build).
• CI: scope the WASM SDK functional run to a nightly-only job and
  unblock release-bump PRs. Least preferred — defeats the test.

Steps to Reproduce (for bugs)

1. Check out any commit where Packages functional tests is triggered
   (any release-bump on v3.1-dev, or a PR that bumps the workspace
   Cargo.toml version).
2. CI runs Packages functional tests / Run functional tests.
3. The Run WASM SDK functional tests step fails with the trailer error
   above; the local network is already up at this point (Start local network succeeded; Run Wallet functional tests and
   Run SDK functional tests both passed against the same gateway).

Confirmed-reproducing CI runs:

• v3.1-dev 2e6fc3270e (CHANGELOG-only release-bump) — run 26205709462
• PR feat: platform-address funding from asset-lock proofs #3671 — run 26182658484 (twice in a row, same failure)

Context

• This is a pre-existing issue that surfaces on every release-bump CI
  run and any PR that bumps a workspace Cargo.toml version. It blocks
  release-bump checks from going green.
• PR test(wasm-sdk): fix flaky functional tests during local network warmup #3569 (test(wasm-sdk): fix flaky functional tests during local network warmup) addressed a warmup race in prefetchLocalReady() but
  not this trailer issue.
• Cascade detail: dashmate local has a single dapi seed at 127.0.0.1:2443.
  The first WASM SDK call fails with the trailer error, rs-dapi-client bans
  the seed in its retry pool, and every subsequent test in the same
  WasmSdk instance fails immediately with "no available addresses to
  use". Tests with their own before all create-ops then produce a
  secondary "expected null to exist" cascade.
• Cross-network sanity check (not yet done — would isolate client vs
  server): point the WASM SDK functional tests at testnet via
  prefetchTestnet() to see whether the same client code works against a
  gateway known to handle gRPC-Web framing correctly.

Your Environment

• Branch: v3.1-dev (tip 2e6fc3270e at filing time)
• CI workflow: .github/workflows/tests-packges-functional.yml → step
  Run WASM SDK functional tests
• Local network: dashmate composite action
  .github/actions/local-network/action.yaml
• Transport: packages/rs-dapi-client/src/transport/wasm_channel.rs uses
  tonic_web_wasm_client::Client (gRPC-Web over fetch)
• Test entry: packages/wasm-sdk/tests/functional/**/*.spec.ts,
  invoked via mocha + ts-node/esm, gateway URL
  https://127.0.0.1:2443 (from default_local_addresses() in
  packages/wasm-sdk/src/sdk.rs:22)

Tracking branch already created for the fix attempt:
fix/wasm-sdk-functional-grpc-web-trailer

[thephez]

fwiw, I hit the issue trying to use Evo SDK (anything newer than dev.1) when trying to use testnet. This happened when running tests on both the platform tutorials and evo-sdk-website repos.