On Linux, argue view <request-id> opens the viewer but the report never renders.
The page shows:
"Failed to decompress report data. The hash payload may be corrupt."
Env: Ubuntu (GNOME), Chrome as default browser, argue-cli 0.6.1, Node 24.
The payload is fine, it's the handoff that breaks. What I checked on a 205 KB result.json:
- encodes to 65,850 chars, well under
MAX_ENCODED_BYTES
- gzip -> base64url -> gunzip round-trips clean
- the same URL renders fine in headless Chromium, and when pasted into the address bar
So it only fails when xdg-open carries the URL. My guess is that with Chrome already running, the URL goes to the live instance over a channel that caps well below ARG_MAX and the fragment gets cut. The budget comment in view.ts is written around macOS open / ARG_MAX, which isn't the binding limit here. Smaller reports work by luck of size, so this looks intermittent.
Patch I'm running locally: in launchBrowser, if the URL is longer than ~8k chars, write it into a temp HTML file as a <meta http-equiv="refresh"> and pass that short path to xdg-open / open / start instead. The browser then does the navigation internally, so nothing crosses a process boundary.
On Linux,
argue view <request-id>opens the viewer but the report never renders.The page shows:
The payload is fine, it's the handoff that breaks. What I checked on a 205 KB
result.json:MAX_ENCODED_BYTESSo it only fails when
xdg-opencarries the URL. My guess is that with Chrome already running, the URL goes to the live instance over a channel that caps well below ARG_MAX and the fragment gets cut. The budget comment inview.tsis written around macOSopen/ ARG_MAX, which isn't the binding limit here. Smaller reports work by luck of size, so this looks intermittent.Patch I'm running locally: in
launchBrowser, if the URL is longer than ~8k chars, write it into a temp HTML file as a<meta http-equiv="refresh">and pass that short path toxdg-open/open/startinstead. The browser then does the navigation internally, so nothing crosses a process boundary.