Skip to content

ci: add pkg.pr.new preview workflow#2

Merged
NathanFlurry merged 8 commits into
mainfrom
add-pkg-pr-new
Mar 10, 2026
Merged

ci: add pkg.pr.new preview workflow#2
NathanFlurry merged 8 commits into
mainfrom
add-pkg-pr-new

Conversation

@NathanFlurry

Copy link
Copy Markdown
Member

Summary

  • add a dedicated pkg.pr.new workflow for pull requests and main pushes
  • scope preview publishing to the secure-exec package and publish only built dist artifacts
  • add a policy test for the workflow and relax a brittle node runtime-driver timeout assertion

Validation

  • pnpm check-types
  • pnpm test

@pkg-pr-new

pkg-pr-new Bot commented Mar 10, 2026

Copy link
Copy Markdown

Open in StackBlitz

pnpm add https://pkg.pr.new/rivet-dev/secure-exec@2

commit: 9576ac5

@NathanFlurry NathanFlurry merged commit be38532 into main Mar 10, 2026
2 checks passed
NathanFlurry added a commit that referenced this pull request Jul 1, 2026
SECURE_EXEC_XTRACE gates an [xtrace] hex dump of every unix-socket payload (tagged dir + remote path)
at the sidecar read/write boundary; experiments/wasm-gui/scripts/xdecode.py decodes the X11 stream
per direction (request opcodes; reply/event/error type + sequence). Zero cost when unset.

Used on the 2-party lxpanel<->Xvfb render stall: data delivery is BYTE-COMPLETE both ways (client
sends == server receives, and vice versa — nothing lost/unflushed). The server replies up to seq 301
then stops; lxpanels final requests in the stuck first-GTK-draw dispatch are an XRENDER drawing batch
plus GetInputFocus (op 0x2b, expects a reply). Both ends then sit idle in net_poll. So the blocker is
NOT data loss and NOT a GTK draw spin — it is a cross-VM poll-wakeup edge case where, mid first draw,
the server stops processing/replying to a delivered request and both guests park in poll.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
NathanFlurry added a commit that referenced this pull request Jul 1, 2026
… render diagnosis

Tool #2 (X11 wire tap + xdecode.py) and tool #3 (wasm-frame symbolizer for livelocked guests) are
committed and cracked the render diagnosis: both guests spin in net_poll, data delivery is complete,
the X server sits idle in WaitForSomething without replying to a delivered first-draw RENDER request.
The earlier prediction that C names survive the build was wrong (fpcast-emu + -Oz strip them) — which
is exactly why tool #3 was needed.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
NathanFlurry added a commit that referenced this pull request Jul 1, 2026
…er root to an unknown ext opcode

- scripts/xreassemble.py: reassembles the FULL client/server X11 byte streams (handling the setup
  request/reply + BigRequests) and matches requests to replies by sequence, so the exact unanswered
  request is visible. SECURE_EXEC_XTRACE=<n> now sets the per-payload capture cap (default 256; large
  for full reassembly).
- ActiveUnixSocket::poll: try_recv first, so a guest non-blocking drain (net.poll(fd,0)) never misses a
  delivered request via the recv_timeout(ZERO)-returns-Timeout-with-data-pending std gotcha. Strictly
  more correct (did not by itself unblock the render).

DIAGNOSIS (tools #2/#3): lxpanel creates the panel toplevel + sets its DOCK/_NET_WM properties but the
toplevel is NEVER mapped — GTK queued its MapWindow in the GLib loop, which is stuck in its first
dispatch. lxpanel waits for a GetInputFocus reply (op 0x2b) that never arrives; the server received all
bytes (delivery is byte-symmetric) yet sits idle in net_poll. Root lead: the first-draw batch sends
requests with major opcode 0x89=137, but Xvfb's registered extensions use opcodes 128/130/132/134/138 —
NO extension owns 137. An unknown-opcode request mis-handled by the server desyncs the request stream
(server waits for bytes to finish a phantom request; client waits for its reply) = the deadlock. Next:
confirm which client lib emits op 137 / fix Xvfb's unknown-opcode handling (platform layer).

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
NathanFlurry added a commit that referenced this pull request Jul 1, 2026
…fpcast arity tuning + marshallers

A deep feasibility research agent (read the toolchain + V8 runtime) proved the user-named "typed-function-references"
does NOT fix the ~13.4s GObject cascade: call_ref type-checks exactly like call_indirect, so a GObject UB cast
mismatch still traps -- typed-func-refs/GC cannot run the mismatched calls faster. The real cost is binaryen
fpcast-emu uniform max-arity padding + per-call trampoline, not the call opcode. V8-here runs GC-wasm fine (V8 130
default-on), so not blocked, just the wrong layer. Also corrected: no max-func-params@128 in-repo; link-xapp.sh:24
uses BARE --fpcast-emu (binaryen default arity).

REAL Root-1 fix (cheapest-first): (1) QUICK WIN hours/one-line -- --pass-arg=max-func-params@<measured-true-max>
(padding scales with arity; GObject closures 1-4 ptr args); (2) days -- force per-signature C marshallers to kill
g_cclosure_marshal_generic then drop/scope --fpcast-emu; (3) weeks -- per-arity trampoline tables. Spec Root-1 item
+ PERF-FINDINGS.md + status-log T69 updated. Also captured: #2 in-place pwrite caveat is real (RootFileSystem uses
the default VirtualFileSystem::pwrite read_file-clone via self.overlay; fix needs dispatch-chain forwarding).

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
NathanFlurry added a commit that referenced this pull request Jul 1, 2026
…pivot to multi-app levers

Measured @64/@28/@26 (re-fpcast from saved prefpcast, no relink): css-bench CSS parse 894->681ms (24%, dense
GObject), but gtk-hello REAL-APP construction only 3734->3635ms (2.6% -- a simple app is one-time-font/theme bound,
not arity bound). Both render-correct, smaller binary. The arity quick win was already banked @128->@64 (3.7x);
@64->@28 is marginal + overrides a deliberate 2.5x safety margin (measured max 25) -> keeping the @64 default.
Root-1 arity = done; remaining Root-1 lever = per-signature marshallers (days). MEASUREMENT-DRIVEN PIVOT: single-app
construction (~3.7s, tuned) is not the multi-app bottleneck; Root-2 serialization is. Next: #2 in-place pwrite
(framebuffer throughput, cuts service-thread load) then Root-2 multiplex. Numbers in M8-STATUS-LOG T70.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
NathanFlurry added a commit that referenced this pull request Jul 1, 2026
…ration research + ROOT2 trace forward

XUBUNTU-SPEC.md: added the living LINUX-SUPPORT-LEDGER.md constraint (catalog every native/platform-layer fix that
makes unmodified Linux software run; append on each fix; treat as a required progress artifact).

GOBJECT-FPCAST-INTEGRATION.md (research subagent): the GObject wasm fpcast cost is binaryen --fpcast-emu uniform
arity padding (taxes the correctly-typed vfunc majority too). Ranked fix: #1 NOW (hours, low-risk) drop
max-func-params @64 -> ~@32 toward measured true-max @25 (too-low fails at BUILD time, safe); #2 (weeks, the
structural fix) a vendored binaryen selective-fpcast pass using wasm-gc ref.test (V8 130 has it) to keep
correctly-typed call_indirect native via call_ref and adapt only mismatched sites (= emscripten#23952 / Pyodide
ref.test). Rejected: Pyodide 0.19 JS trampolines (needs finite patchable sites; breaks sync-import V8 model),
clang thunk-gen (custom clang), typed marshallers (signal emission not construction).

host/src/main.rs: forward SECURE_EXEC_ROOT2_TRACE to the sidecar (built earlier with native CC).

Co-Authored-By: Claude Opus 4.8 (1M context) <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