diagnostics_channel: opt-in subscriber suppression
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 5/5
- Tempo stimato
- Più di una settimana
- Idoneità per principianti
- 45/100
- Tipo di issue
- Funzionalità
- Chiarezza
- Abbastanza chiara
- Stato di attività
- Attiva
- Stack tecnologico
- javascript, node.js
- Ambito
- backend
Direzione di ricerca
Inizia dai punti di ingresso di node:diagnostics_channel indicati nella proposta, in particolare Channel.prototype.publish e Channel.prototype.runStores, e verifica come vengono gestite le registrazioni di subscribe e bindStore. Determina l’API di soppressione e il relativo comportamento con AsyncContextFrame, quindi verifica che gli iscritti che hanno scelto di aderirvi vengano ignorati, mentre gli altri iscritti mantengano il comportamento esistente lungo i percorsi asincroni indicati.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
What is the problem this feature will solve?
APM agents and other tools that subscribe to diagnostics channels often
need to suppress nested instrumentation when their own internal code calls
into an instrumented library. Example: a tracer's HTTP exporter
sends a span over HTTP, the HTTP client is instrumented, the exporter
recurses unless the nested call is suppressed.
Every implementation I have looked at solves it the same way: a custom
AsyncLocalStorage carrying a { noop: true } marker, plus a wrapper
closure around every subscribe and bindStore registration that reads
the marker and short-circuits. Datadog's dd-trace-js does it and I believe the other major APMs do equivalent things. That wrapper runs on every publish, not
only on the suppression path. Thus, we pay one extra JS frame, one extra ALS lookup,
one extra branch per subscribed handler, on the hot path of every channel
in the process.
What is the feature you are proposing to solve the problem?
Move the suppression check inside Channel.prototype.publish and
Channel.prototype.runStores, gated by per-subscription opt-in:
const { channel, suppressed } = require('node:diagnostics_channel')
const kMyTracer = Symbol('my-tracer')
const ch = channel('apm:foo:bar')
ch.subscribe(handler, { suppressedBy: kMyTracer })
ch.bindStore(als, transform, { suppressedBy: kMyTracer })
suppressed(kMyTracer, () => instrumentedCall())
suppressedBy names the Symbol that identifies the suppression scope. suppressed(symbol, fn) enters that scope on the active AsyncContextFrame. Subscribers that opted in are skipped while the scope is active. Subscribers that did not opt in keep firing. That gives multi-APM coordination, and it does not change semantics for any existing caller.
Wins: The userland wrapper closure on every subscribed handler goes away. The check folds into the publish loop where diagnostic_channel already iterates subscribers, and V8 inlines it against the (always-empty in production) marker.
Vendors stop re-implementing the same ALS dance, each with their own subtle differences in how the marker propagates across setImmediate, queueMicrotask, and unhandled-rejection paths.
There are probably some details to be fledged out but I wanted to get some feedback about the overall idea first. @bengl @timfish @Qard @trentm and others: opinions?
What alternatives have you considered?
No response
- Lingua principale
- JavaScript
- Stelle
- 122k
- Fork
- 37.4k
- Merge medio
- 4g 4h
- PR unite (30g)
- 276
Guida per i contributori
Apri la guida per i contributori
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di nodejs/node
-
doc
Difficoltà 2/5 1-3 ore Idoneità per principianti 65/100
-
build
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 88/100
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 84/100
-
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 90/100
-
feature request
Difficoltà 2/5 1-3 ore Idoneità per principianti 68/100
Issue simili
-
bug customer-eng Durable Agents Inngest status: needs triage
Difficoltà 2/5 1-3 ore Idoneità per principianti 82/100
-
optimization optimization:agents-md-curator
Difficoltà 2/5 1-3 ore Idoneità per principianti 75/100
githubnext/gh-aw-cao#13475 ·
-
[BUG]: "Clear All" in Settings doesn't clear the saved analysis, old data comes back after reload Apertabug
Difficoltà 2/5 1-3 ore Idoneità per principianti 88/100
AOSSIE-Org/OrgExplorer#253 · 1 commento ·
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 88/100
oxc-project/oxc#26944 ·
-
ai-observability bug team/ai-observability
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100