Skip to content

Add native production smoke checks#72

Open
sonukapoor wants to merge 1 commit into
wasmerio:mainfrom
sonukapoor:production-readiness-validation
Open

Add native production smoke checks#72
sonukapoor wants to merge 1 commit into
wasmerio:mainfrom
sonukapoor:production-readiness-validation

Conversation

@sonukapoor

@sonukapoor sonukapoor commented Apr 30, 2026

Copy link
Copy Markdown
Contributor

This turns part of the 0.x production-readiness roadmap from #8 into a small native smoke path. It is not a production-readiness gate or release sign-off; it gives future readiness work a repeatable starting point for basic runtime checks.

The PR adds make test-production-readiness, a shell runner, two native fixtures, and a short roadmap doc. The first smoke set covers the version path, eval path, built-in module loading, HTTP loopback lifecycle, and repeated cold starts. Each case has a timeout so a stuck runtime invocation fails the smoke run instead of hanging indefinitely.

Safe-mode smoke remains optional with EDGE_PRODUCTION_READINESS_SAFE=1, and network/TLS safe-mode coverage stays on the existing make test-wasix-safe-mode path.

I verified this locally with:

bash -n scripts/run-production-readiness-smoke.sh
git diff --check
make test-production-readiness

The local native smoke run passed 5 checks with 0 failures.

@sonukapoor sonukapoor mentioned this pull request Apr 30, 2026
@sonukapoor sonukapoor force-pushed the production-readiness-validation branch from da35ff9 to 6438b2c Compare May 1, 2026 12:33
@sonukapoor sonukapoor changed the title Add production readiness smoke matrix Add native production smoke checks May 1, 2026
@sonukapoor sonukapoor force-pushed the production-readiness-validation branch from 6438b2c to a1dc054 Compare May 4, 2026 17:28
@sonukapoor

Copy link
Copy Markdown
Contributor Author

@syrusakbary CI is green now after the unrelated WASIX smoke instability was fixed across the open branches.

This PR is scoped to a small native production-readiness smoke set for the 0.x roadmap. If the scope looks aligned, I think it is ready for review.

rbbydotdev added a commit to rbbydotdev/edgejs that referenced this pull request Jun 22, 2026
…sign) → pinpointed the real blocker

Bus-based probes (entry heartbeat posts RC/DRAW/ANSI via the BroadcastChannel, harness
collects window.__probes) proved: the entry's heartbeat setInterval NEVER fires after the
server boot, while CDP caught worker.ts's setInterval firing fine. So opentui's
timer-driven render loop never ticks in the entry/bundle's contextify vm-context env →
only the clear escape (7B) reaches ghostty, no content frames. The worker is HEALTHY
(not blocked) and the bundle IMPORTS + server LISTENS — the wall is now a precise edge
jsloop timer-draining / run-env issue (wasmerio#71/wasmerio#72 family), NOT opentui or the App. Adapter
probes stripped after the finding.
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