start.node: node.js imports node:http before start.instrument runs, so HTTP instrumentation misses the server
維護者通常 1 天內回覆
評估
- 難度
- 4/5
- 預估耗時
- 1-2 天
- 新手友好度
- 30/100
- Issue 類型
- 缺陷
- 描述清晰度
- 基本清楚
- 活躍度
- 活躍
- 技術堆疊
- node.js, typescript, vite
研究方向
The problem is the static import order in the emitted dist/server/node.js, where node:http loads before start.instrument runs inside ./server.js. Start in the plugin code that generates the node entry and check how it orders the node:* imports relative to the instrument and handler imports. Done means that with instrument set, the instrument module runs before node:http is loaded, and a build with the option shows that order.
由索引模型根據 Issue 內容生成。
描述
@solidjs/vite-plugin 3.0.0-next.50, solid-js 2.0.0-rc.15, Node 26.
With start: { node: true, instrument: './src/instrumentation.ts' }, the emitted dist/server/node.js starts with static imports:
import { createServer } from 'node:http';
// …node:fs, node:path, node:stream/promises…
import { handleRequest } from './server.js';
./server.js is where the start.instrument wrapper runs (await import(instrument); await import(handler)). Static imports are evaluated first, so node:http is already loaded when the instrument module runs. OpenTelemetry's HTTP instrumentation (@opentelemetry/auto-instrumentations-node / instrumentation-http) then misses the server: there is no HTTP server span for any request. The same instrument module works when it is passed as node --import ./dist/instrumentation.js.
The option's docs say the module "runs to completion before anything else in the server graph loads" on every surface. For start.node the entry itself breaks that.
What we see: we run an instrument module that starts the OpenTelemetry NodeSDK, and serve through the node entry (createListener from dist/server/node.js). Run that way, the collector gets no HTTP SERVER span for any request. With the same module passed as node --import, every request gets one. The import order above is the reason as far as we can tell. We have not reduced it to a standalone repo.
Suggestion: when instrument is set, have the node entry await it before the node:* imports. One way is to emit await import(instrument) at the top of node.js and load the rest of the entry through a dynamic import. Another is to load node:http lazily inside serve / createListener.
We pass --import for now, so the option is unused in our apps.
- 主要語言
- TypeScript
- 星號
- 522
- 分支
- 73
- 平均合併
- 1 天 8 小時
- 30 天內合併 PR
- 31
環境準備
- 沒有 Dockerfile 或 Docker Compose 檔案
- 沒有 Pull Request 範本
- 閱讀貢獻指南
從這裡開始
- 先讀完整個 Issue，再讀專案的貢獻指南。
- 在 Issue 下留言說明你要接手 —— 這能避免兩個人做同樣的事。
- Fork 儲存庫，在一個分支上完成修改。
- 送出 Pull Request，並在描述裡引用這個 Issue 編號。
solidjs/solid-vite-plugin 的其他 Issue
-
Vitest config is dropped when test.server.deps.external already lists solid-js可能已有人在做 @RaphaelFakhri 今天認領。 未關閉
難度 2/5 1-3 小時 新手友好度 78/100
solidjs/solid-vite-plugin#454 ·
維護者通常 1 天內回覆
-
Test environment detection doesn't consider Vitest workspaces可能已有人在做 @carloitaben 於 58 天前認領。 未關閉1.x
難度 2/5 1-3 小時 新手友好度 78/100
solidjs/solid-vite-plugin#205 · 1 則留言 · 2 個 reaction ·
維護者通常 1 天內回覆
-
難度 4/5 3-5 天 新手友好度 56/100
solidjs/solid-vite-plugin#456 ·
維護者通常 1 天內回覆
-
serverFunctions.components (dev): server-functions client is duplicated when @solidjs/web is in optimizeDeps.exclude, so post-boot server components resolve to undefined可能已有人在做 關聯的 PR 仍在進行中或已合併。 未關閉
難度 3/5 1-2 天 新手友好度 58/100
solidjs/solid-vite-plugin#428 ·
維護者通常 1 天內回覆
-
[3.0.0-next.50 / next] Dev with a host-owned SSR environment: the first server-function call after startup, a restart or a new "use server" file waits a fixed 1 s可能已有人在做 關聯的 PR 仍在進行中或已合併。 未關閉
難度 3/5 1-2 天 新手友好度 58/100
solidjs/solid-vite-plugin#427 ·
維護者通常 1 天內回覆
查看 solidjs/solid-vite-plugin 的全部 Issue
相似的 Issue
-
難度 2/5 1-3 小時 新手友好度 76/100
radix-ui/primitives#4228 ·
維護者通常 1 天內回覆
-
難度 2/5 1-3 小時 新手友好度 66/100
-
難度 2/5 1-3 小時 新手友好度 70/100
SignalK/freeboard-sk#1093 ·
維護者通常 1 天內回覆
-
難度 2/5 1-3 小時 新手友好度 76/100
維護者通常 1 天內回覆
-
[测试] 等待仓库加载后再记录多仓库排序基线可能已有人在做 @myot233 今天認領。 未關閉
難度 2/5 1-3 小時 新手友好度 84/100
維護者通常 1 天內回覆