Dashboard › Code › Session sdb6786b891f
sdb6786b891f1b182Edit applied successfully.
1.3.13
---installed in env vs events (events were bun 1.3.14)---
"typecheck": "bun --filter '*' typecheck",
"test": "bun test",
"build": "bun --filter '*' build",
"postinstall": "bun --filter '@loreai/gateway' build"
"@types/bun": "^1.2.0",
"typecheck": "bun --filter '*' typecheck",
"test": "bun test",
"build": "bun --filter '*' build",
"postinstall": "bun --filter '@loreai/gateway' build"
"@types/bun": "^1.2.0",
Events were on bun 1.3.14. Let me check the latest Bun release and search their repo for WASM shared/growable memory issues that match our symptom (large allocation failing in a worker thread under --compile).
[]
...output truncated...
Full output saved to: /home/byk/.local/share/opencode/tool-output/tool_e941b0f0e001WfzJUkrt3AVp0Z
,"assignees":[],"dismissed_at":null,"dismissed_by":null,"dismissed_reason":null,"dismissed_comment":null,"fixed_at":"2026-04-14T13:24:51Z","auto_dismissed_at":null},{"number":144,"state":"fixed","dependency":{"package":{"ecosystem":"npm","name":"vite"},"manifest_path":"pnpm-lock.yaml","scope":"runtime","relationship":"transitive"},"security_advisory":{"ghsa_id":"GHSA-v2wj-q39q-566r","cve_id":"CVE-2026-39364","summary":"Vite: `server.fs.deny` bypassed with queries","description":"### Summary\n\nThe contents of files that are specified by [`server.fs.deny`](https://vite.dev/config/server-options#server-fs-deny) can be returned to the browser.\n\n### Impact\n\nOnly apps that match the following conditions are affected:\n\n- explicitly exposes the Vite dev server to the network (using `--host` or [`server.host` config ...
<path>/home/byk/.local/share/opencode/worktree/55fa901aca64a01fa4b5c2abce1c85c1c27475e7/swift-squid/package.json</path>
<type>file</type>
<content>
1: {
2: "name": "@sentry/craft",
3: "version": "2.27.0-dev.0",
4: "description": "The universal sentry workflow CLI",
5: "main": "dist/craft",
6: "repository": "https://github.com/getsentry/craft",
7: "author": "Sentry",
8: "license": "MIT",
9: "bin": {
10: "craft": "dist/craft",
11: "sentry-craft": "dist/craft"
12: },
13: "devDependencies": {
14: "@aws-sdk/client-lambda": "^3.984.0",
15: "@eslint/js": "^9.17.0",
16: "@google-cloud/storage": "^7.14.0",
17: "@octokit/plugin-retry": "^7.1.2",
18: "@octokit/request-error": "^7.0.0",
19: "@octokit/rest": "^21.0.2",
20: "@sentry/esbuild-plugin": "^2.23.0",
21: "@sentry/node": "^10.27.0",
22: "@types/async": "^3.0.1",
23: "@types/aws4": "^1.5.1",
24: "@types/cli-table": "^0.3.0",
25: "@types/extract-zip": "^2.0.1",
26: ...
Now let me get the full dependabot alerts output and filter for open alerts only:
Alert #164 [open] - CRITICAL Package: vitest (manifest: pnpm-lock.yaml) Vuln range: < 4.1.0 Fix: 4.1.0 CVE: CVE-2026-47429 / GHSA-5xrq-8626-4rwp Summary: When Vitest UI server is listening, arbitrary file can be read and executed Alert #163 [open] - CRITICAL Package: vitest (manifest: package.json) Vuln range: < 4.1.0 Fix: 4.1.0 CVE: CVE-2026-47429 / GHSA-5xrq-8626-4rwp Summary: When Vitest UI server is listening, arbitrary file can be read and executed Alert #162 [open] - HIGH Package: tmp (manifest: pnpm-lock.yaml) Vuln range: < 0.2.6 Fix: 0.2.6 CVE: CVE-2026-44705 / GHSA-ph9p-34f9-6g65 Summary: tmp has Path Traversal via unsanitized prefix/postfix that enables directory escape Alert #161 [open] - HIGH Package: tmp (manifest: package.json) Vuln range: < 0.2.6 Fix: 0.2.6 CVE: CVE-2026-44705 / GHSA-ph9p-34f9-6g65 Summary: tmp has Path Traversal via unsanitized prefix/postfix that enables directory escape
Total open alerts: 4
Good. There are 0 security advisories and 4 open dependabot alerts covering 2 distinct vulnerabilities. Let me explore how these packages are used in the codebase to understand the upgrade implications.
{
"url": "https://api.github.com/repos/oven-sh/bun/releases/320260981",
"assets_url": "https://api.github.com/repos/oven-sh/bun/releases/320260981/assets",
"upload_url": "https://uploads.github.com/repos/oven-sh/bun/releases/320260981/assets{?name,label}",
"html_url": "https://github.com/oven-sh/bun/releases/tag/bun-v1.3.14",
"id": 320260981,
"author": {
"login": "Jarred-Sumner",
"id": 709451,
"node_id": "MDQ6VXNlcjcwOTQ1MQ==",
"avatar_url": "https://avatars.githubusercontent.com/u/709451?v=4",
"gravatar_id": "",
"url": "https://api.github.com/users/Jarred-Sumner",
"html_url": "https://github.com/Jarred-Sumner",
"followers_url": "https://api.github.com/users/Jarred-Sumner/followers",
"following_url": "https://api.github.com/users/Jarred-Sumner/following{/other_user}",
"gists_url": "https://api.github.com/users/Jarred-Sumner/gists{/gist_id}",
"starred_url": "https://api.github.com/users/Jarred-Sumner/starred{/owner}{/repo}",
...
{
"total_count": 4,
"incomplete_results": false,
"items": [
{
"url": "https://api.github.com/repos/oven-sh/bun/issues/31158",
"repository_url": "https://api.github.com/repos/oven-sh/bun",
"labels_url": "https://api.github.com/repos/oven-sh/bun/issues/31158/labels{/name}",
"comments_url": "https://api.github.com/repos/oven-sh/bun/issues/31158/comments",
"events_url": "https://api.github.com/repos/oven-sh/bun/issues/31158/events",
"html_url": "https://github.com/oven-sh/bun/issues/31158",
"id": 4491402431,
"node_id": "I_kwDOFVKCyc8AAAABC7Vcvw",
"number": 31158,
"title": "Event loop permanently dies when Go CGo .so + WASM coexist on Linux (SIGPWR storm)",
"user": {
"login": "gogakoreli",
"id": 12997449,
"node_id": "MDQ6VXNlcjEyOTk3NDQ5",
"avatar_url": "https://avatars.githubusercontent.com/u/12997449?v=4",
"gravatar_id": "",
"url": ...
This is a goldmine. The latest Bun is still 1.3.14 (released May 12) — so Seylan/Onur are already on the newest Bun; upgrading Bun won't help. But the search surfaced two directly relevant Bun bugs, both still open, both Linux x64, both involving shared WASM memory in worker threads — exactly our configuration ({shared:true} memory, ORT threaded WASM, run in a worker_thread):
These strongly corroborate the hypothesis: Bun's threaded/shared WASM is buggy, and the issues are concentrated on Linux x64 (Onur's 10,917 events) with macOS less affected (Seylan's 7) — matching our Sentry distribution exactly. Critically, the maintainers note "Node.js works correctly" for #25677, which validates both fallback directions in the plan: (a) numThreads=1 → non-shared memory avoids the SharedArrayBuffer path, and (b) Node SEA is a known-good runtime.
Let me do one targeted search for the OOM-specific symptom to see if there's an even more on-the-nose issue, then finalize.