Conception de l’arbre de traces des sous-agents (Phase 3 du P3)

Issue #3731 — Phase 3 du tracing hiérarchique des sessions. Ajoute un span qwen-code.subagent afin que les invocations de sous-agents soient isolées et disposent d’une structure de traces requêtable, au lieu d’être entremêlées silencieusement sous le span parent qwen-code.interaction.

S’appuie sur la Phase 1 (#4126), la Phase 1.5 (#4302) et la Phase 2 (#4321).

Problème

Aujourd’hui, chaque exécution de AgentTool.execute s’exécute sous le span qwen-code.interaction parent. Trois pathologies :

1. Entremêlement des sous-agents concurrents. coreToolScheduler.ts:728 marque AGENT comme compatible avec la concurrence — Promise.all exécute jusqu’à 10 sous-agents en parallèle. Leurs spans LLM-request / tool / hook s’attachent tous au span d’interaction parent partagé, de sorte que les outils d’exploration des traces ne peuvent pas distinguer « cette requête LLM appartient au sous-agent A » de « celle-ci appartient au sous-agent B ».
2. Aucun span pour la frontière du sous-agent lui-même. Il existe un LogRecord qwen-code.subagent_execution (émis depuis agent-headless.ts:268,329) relié à un span du même nom via LogToSpanProcessor, mais c’est un marqueur autonome, pas un parent qui imbrique les spans LLM / tool / hook du sous-agent en dessous.
3. Les sous-agents fork / background flottent librement. Les chemins fire-and-forget (runInForkContext / background) survivent au AgentTool.execute parent et émettent des spans à travers plusieurs tours utilisateur suivants. Le span de l’outil parent est déjà terminé lorsque ces spans apparaissent, donc context.active() d’OTel n’aide pas — ils s’attachent à l’interaction qui était active au moment du déclenchement, ou à aucune.

Surface existante (inchangée)

Hors du périmètre (reporté)

• Agrégation de l’utilisation des tokens par sous-agent (gen_ai.usage.* additionné sur tous les spans LLM à l’intérieur d’un sous-agent). Appartient à la Phase 4 (décomposition des requêtes LLM).
• Migration du LogRecord qwen-code.subagent_execution vers le nouveau span en tant qu’événements de span. RUM et métriques sont étroitement couplés au LogRecord ; reporté à un suivi qui pourra renégocier les 3 consommateurs ensemble.
• Agrégation automatique des coûts. Même raison — nécessite d’abord l’utilisation des tokens.
• Suppression du marqueur concurrent: true de l’outil AGENT. La concurrence est correcte ; nous l’instrumentons, nous ne la contraignons pas.

Références (preuves des décisions)

Conception — six décisions, chacune justifiée

D1 — Cycle de vie du span : l’appelant ouvre, le callee s’exécute à l’intérieur de context.with(span, fn)

agent.ts (appelant) construit le span. Le corps — qu’il soit attendu (runFramed) ou fire-and-forget (runInForkContext / background) — s’exécute à l’intérieur de runInSubagentSpanContext(span, fn), qui appelle otelContext.with(trace.setSpan(active, span), fn).

Où exactement dans AgentTool.execute le span s’ouvre-t-il ? Ouvrez-le juste AVANT la configuration spécifique au type d’invocation (createAgentHeadless / createForkSubagent etc.) — de sorte que le temps de configuration (construction de la config, reconstruction du ToolRegistry, câblage du ContextOverride) SOIT inclus dans la durée de qwen-code.subagent. Les opérateurs qui cherchent « pourquoi ce sous-agent est lent ? » voient l’image complète. La configuration est généralement << temps LLM, donc c’est sans bruit.

Alternative envisagée : ouvrir après la configuration, exclure le temps de config. Rejetée car la configuration du sous-agent est un travail qui lui est attribuable — la cacher rend le calcul de durée totale erroné lors de la somme de tous les spans de sous-agents.

Pourquoi pas uniquement par le callee : au moment où le corps du fork/background s’exécute réellement, l’appelant est déjà revenu. context.active() d’OTel renvoie alors le contexte ambiant transporté par l’environnement d’exécution asynchrone — ce qui pour un void fire-and-forget après la fin du parent est peu fiable. Le span parent est déjà fermé ; un rattachement après coup est incorrect.

Pourquoi pas uniquement par l’appelant : le mode foreground fonctionne correctement ainsi, mais les spans fork/background doivent continuer à émettre des spans enfants (LLM / tool / hook) après que AgentTool.execute a retourné. Ces spans enfants ont besoin que context.active() renvoie le span du sous-agent — ce qui ne se produit que si le corps s’exécute explicitement à l’intérieur de context.with(subagentSpan, body).

Les deux extrémités sont nécessaires. La conception est le pont — l’appelant crée le span + la stratégie de traceId selon le type d’invocation, puis passe la main via runInSubagentSpanContext.

D2 — traceId hybride : foreground = span enfant, fork/background = nouveau traceId + Lien

Charge utile du Lien :

tracer.startSpan(
  'qwen-code.subagent',
  {
    kind: SpanKind.INTERNAL,
    links: [
      {
        context: invokerSpanContext,
        attributes: { 'qwen-code.link.kind': 'invoker' },
      },
    ],
  } /* contexte explicite = racine, n'hérite pas de l'actif */,
);

Possibilité de requêtage inter-traces via l’identifiant de session : gen_ai.conversation.id est défini sur chaque span de sous-agent (foreground et racine liée), donc une requête ARMS par session.id retourne à la fois la trace de l’interaction parente ET les traces des sous-agents racines liées. Le Lien lui-même apparaît dans l’interface utilisateur de la trace parente comme « Engendré : sous-agent X (autre trace) » pour permettre la navigation.

Pourquoi pas toujours enfant : un sous-agent background de 4 heures gonfle la durée chronologique de la trace parente à 4 heures ; la taille de la trace dépasse les limites de plusieurs backends (la limite de 25 000 exécutions de LangSmith est la borne documentée la plus claire). Les sous-agents foreground que l’utilisateur attend réellement n’ont pas ce problème car ils sont temporellement englobés.

Pourquoi pas toujours racine liée : le foreground brise l’arbre de traces naturel. Une invite utilisateur qui exécute un sous-agent Explore synchrone DEVRAIT montrer un seul arbre, pas deux traces liées.

D3 — TTL : conscient du type, sous-agent fork/background = 4h, autres = 30min

session-tracing.ts:124 définit SPAN_TTL_MS = 30 * 60 * 1000. La passe de nettoyage à :144-152 spécialise déjà tool.blocked_on_user pour y apposer decision: 'aborted' + source: 'system'. L’esprit est déjà conscient du type.

Changement : introduire un TTL par type :

const SPAN_TTL_MS_DEFAULT = 30 * 60 * 1000; // 30min
const SPAN_TTL_MS_LONG = 4 * 60 * 60 * 1000; // 4h
 
function ttlFor(ctx: SpanContext): number {
  if (
    ctx.type === 'subagent' &&
    ctx.attributes['qwen-code.subagent.invocation_kind'] !== 'foreground'
  ) {
    return SPAN_TTL_MS_LONG;
  }
  return SPAN_TTL_MS_DEFAULT;
}

À l’expiration du TTL, les spans de sous-agents reçoivent :

{
  'qwen-code.span.ttl_expired': true,
  'qwen-code.span.duration_ms': age,
  'qwen-code.subagent.status': 'aborted',
  'qwen-code.subagent.terminate_reason': 'ttl_swept',
}

Pourquoi pas 30min fixe : des sous-agents longs légitimes (analyse de gros dépôts, builds lents, tâches de recherche approfondie) seraient marqués à tort comme ayant expiré. 4h couvre le 99e percentile sans être trop laxiste pour que les vraies suspensions passent inaperçues.

Pourquoi pas pas de TTL : un crash de processus / OOM / kill -9 → le span reste dans la Map activeSpans pour toujours. Le filet de sécurité de 30 min protège contre cela ; les sous-agents fork/background ont simplement besoin d’une fenêtre plus large, pas d’une suppression.

D’où vient 4h : limite supérieure pragmatique pour des tâches d’agent non triviales (recherche approfondie longue / analyse de grands codebases). Configurable via constante si les données de production montrent que nous avons tort.

D4 — Rétention des LogRecords : conserver l’émission, ignorer le pont LogToSpanProcessor

Le LogRecord SubagentExecutionEvent a 3 consommateurs en aval (vérifié par audit du dépôt) :

Ignorer le pont (le seul changement dans LogToSpanProcessor) :

// log-to-span-processor.ts — dans onEmit, après deriveSpanName
const skipBridge = new Set<string>([
  EVENT_SUBAGENT_EXECUTION, // couvert par le span natif qwen-code.subagent
]);
if (skipBridge.has(eventName)) return;

Impact sur les consommateurs de traces : les tableaux de bord qui filtrent sur le nom de span qwen-code.subagent_execution commenceront à retourner zéro résultat. Ils doivent être mis à jour vers qwen-code.subagent. À noter dans les notes de version.

Pourquoi ne pas supprimer le LogRecord : c’est l’entrée pour RUM et les métriques. Le supprimer serait une refactorisation sur 3 systèmes ; hors du périmètre ici.

Pourquoi ne pas garder les deux : la trace montrerait deux spans par sous-agent (qwen-code.subagent + qwen-code.subagent_execution) portant des informations redondantes — source de confusion pour les opérateurs lisant les traces, volume de spans dupliqué.

D5 — Nom du span + attributs : conformité hybride à la spécification, préfixe fournisseur pour les extensions

Nom du span : qwen-code.subagent (correspond à la convention de codebase Phase 1/2 : qwen-code.interaction, qwen-code.tool, qwen-code.hook, …).

La spécification OTel GenAI dit que le nom de span canonique est invoke_agent {gen_ai.agent.name} — mais dit aussi « les systèmes/cadriciels GenAI individuels PEUVENT spécifier des formats de nom de span différents. » Nous utilisons notre propre nom et définissons gen_ai.operation.name='invoke_agent' afin que les outils conscients de la spécification identifient toujours le span. Les opérateurs lisant notre arbre de traces voient une nomenclature cohérente qwen-code.*.

Type de span : INTERNAL (invocation de sous-agent intra-processus, selon la spécification).

Ensemble d’attributs :

• status === 'completed' → SpanStatus { code: OK }
• status === 'failed' → SpanStatus { code: ERROR, message: truncated(error.message) }
• status === 'cancelled' ou 'aborted' → SpanStatus { code: UNSET } (conforme à la convention de la Phase 2)

Pourquoi une double émission sur id + name : la spécification est en Development (un cran avant Experimental). OTEL_SEMCONV_STABILITY_OPT_IN=gen_ai_latest_experimental existe pour adhésion optionnelle. Les noms d’attributs de la spécification peuvent être renommés avant Stable. La double émission est le même motif que celui utilisé en Phase 2 pour call_id → tool.call_id ; supprimez la clé vendeur lorsque la spécification atteint Stable.

Pourquoi qwen-code.subagent.* (et non qwen.subagent.*) : toutes les clés existantes préfixées par un vendeur dans constants.ts utilisent qwen-code.* (qwen-code.user_prompt, qwen-code.tool_call, etc.). La cohérence interne prime sur la préférence de nommage OTel, puisque les opérateurs interrogent ARMS par préfixe.

Cardinalité : les attributs de span ne sont pas des étiquettes de métriques dans OTel ; les attributs clés UUID (id, parent_agent_id, invoking_request_id) sont sans danger au niveau de la span. Ne les promouvez pas en étiquettes de métriques plus tard.

~10-15 attributs par span (selon le type d’invocation, l’échec, l’imbrication). Même ordre que qwen-code.tool.

D6 — Champ AgentContext.depth ajouté directement

AgentContext (agent-context.ts:32) n’est pas exporté — seuls les helpers (getCurrentAgentId, runWithAgentContext, getRuntimeContentGenerator, runWithRuntimeContentGenerator) le sont. Aucune rupture en aval au niveau TypeScript. Les 6 lecteurs connus via getCurrentAgentId() ne lisent que agentId ; l’ajout de depth?: number leur est invisible.

interface AgentContext {
  agentId: string;
  subagentName: string;
  invokingRequestId: string;
  invocationKind: 'spawn' | 'resume';
  isBuiltIn: boolean;
  depth?: number; // NOUVEAU — valeur par défaut 0 dans les lecteurs
}

runWithAgentContext utilise déjà le spread { ...current, agentId }, donc depth survit inchangé dans les sites d’appel existants. Mettez à jour runWithAgentContext pour auto-incrémenter depth en interne — aucun appelant n’a besoin de connaître depth :

function runWithAgentContext<T>(agentId: string, fn: () => T): T {
  const parent = agentContextStorage.getStore();
  const next: AgentContext = {
    ...parent,
    agentId,
    depth: (parent?.depth ?? -1) + 1, // auto-incrémentation
  };
  return agentContextStorage.run(next, fn);
}

Sous-agent de premier niveau : pas de parent ALS → depth: 0. Imbriqué : profondeur du parent +1.

Un nouvel accesseur minuscule getCurrentAgentDepth(): number retourne agentContextStorage.getStore()?.depth ?? 0 — utilisé par startSubagentSpan pour remplir qwen-code.subagent.depth.

Pourquoi pas un ALS séparé juste pour la télémétrie : cela dupliquerait la même forme de contexte que nous maintenons déjà. Mauvais. Réutilisez celui existant.

API Helper (session-tracing.ts)

// constants.ts
export const SPAN_SUBAGENT = 'qwen-code.subagent';
 
// session-tracing.ts
export interface StartSubagentSpanOptions {
  agentId: string;
  subagentName: string;
  invocationKind: 'foreground' | 'fork' | 'background';
  isBuiltIn: boolean;
  parentAgentId?: string;
  depth: number;
  invokingRequestId?: string;
  sessionId: string;
  modelOverride?: string;
  invokerSpanContext?: SpanContext; // requis pour fork / background (source du Link)
}
 
export interface SubagentSpanMetadata {
  status: 'completed' | 'failed' | 'cancelled' | 'aborted';
  terminateReason?: string;
  resultSummaryPresent?: boolean;
  error?: string;
  errorType?: string;
}
 
export function startSubagentSpan(opts: StartSubagentSpanOptions): Span;
export function endSubagentSpan(
  span: Span,
  metadata: SubagentSpanMetadata,
): void;
export function runInSubagentSpanContext<T>(
  span: Span,
  fn: () => Promise<T>,
): Promise<T>;

runInSubagentSpanContext est la primitive d’isolation :

export function runInSubagentSpanContext<T>(
  span: Span,
  fn: () => Promise<T>,
): Promise<T> {
  const ctx = trace.setSpan(otelContext.active(), span);
  return otelContext.with(ctx, fn);
}

startSubagentSpan se ramifie en interne selon invocationKind :

function startSubagentSpan(opts: StartSubagentSpanOptions): Span {
  const attributes = buildSpanAttributes(opts);
  const tracer = getTracer();
 
  if (opts.invocationKind === 'foreground') {
    // Enfant de la span active courante (span de l'outil appelant)
    return tracer.startSpan(SPAN_SUBAGENT, {
      kind: SpanKind.INTERNAL,
      attributes,
    });
  }
 
  // fork / background : racine liée (linked root)
  return tracer.startSpan(SPAN_SUBAGENT, {
    kind: SpanKind.INTERNAL,
    attributes,
    links: opts.invokerSpanContext
      ? [
          {
            context: opts.invokerSpanContext,
            attributes: { 'qwen-code.link.kind': 'invoker' },
          },
        ]
      : undefined,
    root: true, // force un nouveau traceId ; ignore le contexte actif comme parent
  });
}

Câblage du cycle de vie

Premier plan nommé (le chemin commun)

// agent.ts:~2154
// Récupérer le cadre ALS parent pour définir parentAgentId sur la span. La
// profondeur du nouvel enfant est calculée automatiquement dans
// runWithAgentContext (D6) — nous la lisons via getCurrentAgentDepth() une fois
// que nous sommes À L'INTÉRIEUR du cadre ALS enfant. Deux étapes :
const parentAgentId = getCurrentAgentId();  // AVANT d'entrer dans le cadre enfant
 
// ... l'appel runFramed existant entre dans runWithAgentContext(hookOpts.agentId, ...) ...
 
// À L'INTÉRIEUR de runFramed, nous pouvons lire la profondeur de l'enfant :
//   const depth = getCurrentAgentDepth();
//
// Placement pratique : transmettez `depth` comme variable de fermeture, définie
// après que runWithAgentContext prend effet — OU calculez-la comme
// `(getCurrentAgentDepth() outside) + 1` du côté appelant (plus simple).
const depth = getCurrentAgentDepth();  // en dehors du cadre ; l'enfant sera ceci + 1
// (définissez qwen-code.subagent.depth = depth dans les arguments de startSubagentSpan)
 
const span = startSubagentSpan({
  agentId, subagentName, invocationKind: 'foreground',
  isBuiltIn, parentAgentId, depth, invokingRequestId, sessionId,
  modelOverride,
  // invokerSpanContext omis — foreground hérite naturellement via context.with
});
let metadata: SubagentSpanMetadata = { status: 'aborted' };
try {
  await runInSubagentSpanContext(span, () =>
    runFramed(() => this.runSubagentWithHooks(...)),
  );
  metadata = { status: 'completed' /* + resultSummaryPresent */ };
} catch (error) {
  metadata = {
    status: signal.aborted ? 'aborted' : 'failed',
    error: error instanceof Error ? error.message : String(error),
    errorType: error?.constructor?.name,
  };
  throw error;
} finally {
  endSubagentSpan(span, metadata);
}

Fork (fire-and-forget)

const invokerSpanContext = trace.getSpan(otelContext.active())?.spanContext();
const span = startSubagentSpan({
  ..., invocationKind: 'fork', invokerSpanContext,
});
void runInForkContext(() =>
  runInSubagentSpanContext(span, async () => {
    let metadata: SubagentSpanMetadata = { status: 'aborted' };
    try {
      await runFramedFork();
      metadata = { status: 'completed' };
    } catch (error) {
      metadata = {
        status: signal.aborted ? 'aborted' : 'failed',
        error: error instanceof Error ? error.message : String(error),
      };
    } finally {
      endSubagentSpan(span, metadata);
    }
  }),
);
// AgentTool.execute retourne immédiatement FORK_PLACEHOLDER_RESULT ;
// la span vit à travers les interactions suivantes de la session parente.

Arrière-plan

Même forme que fork, avec invocationKind: 'background' et bgEventEmitter au lieu de eventEmitter. TTL de 4h (identique à fork — règle de type de D3).

Isolation concurrente — la garantie phare

Trois invocations simultanées de sous-agent depuis une seule invite utilisateur (le modèle émet 3 blocs AGENT tool_use → coreToolScheduler.runConcurrently exécute 3 executeSingleToolCall en parallèle ; chacun ouvre sa propre span qwen-code.tool selon la Phase 2) :

qwen-code.interaction                         [traceId=T0]
├─ qwen-code.tool [agent call #A]
│  └─ qwen-code.subagent (A, foreground)     [traceId=T0, child]
│     ├─ qwen-code.llm_request
│     └─ qwen-code.tool [...]
│        └─ qwen-code.tool.execution
├─ qwen-code.tool [agent call #B]
│  └─ qwen-code.subagent (B, foreground)     [traceId=T0, child]
│     └─ qwen-code.llm_request
└─ qwen-code.tool [agent call #C]
   └─ qwen-code.subagent (C, fork)           [traceId=T1, linked root]
      └─ qwen-code.llm_request                [traceId=T1]
         └─ ...                               [traceId=T1, peut émettre des heures plus tard]

context.with(span, runX) pour chacun de A, B, C s’exécute en concurrence. AsyncLocalStorageContextManager (déjà enregistré automatiquement par NodeSDK à sdk.ts:273) délimite par fibre ; pas d’interférence. Les spans LLM / outil / hook enfants de chaque sous-agent voient span via context.active() dans leur propre chaîne asynchrone.

Le fork (C) forme une trace séparée — ses spans enfants héritent de traceId=T1 même lorsqu’elles sont émises à travers plusieurs interactions suivantes de la session parente. Une requête ARMS par session.id renvoie à la fois T0 et T1; le Link depuis la racine de T1 vers la span qwen-code.tool invocatrice de C fournit une navigation explicite.

Fichiers à modifier

Total : 9 fichiers, ~430 LOC. Plus gros que les commits typiques de Phase 2 mais justifié — le changement TTL touche un fichier séparé, le skip LogToSpanProcessor est un fichier séparé, et les fichiers de test doublent. Diviser aboutirait à une surface de télémétrie incomplète.

Si la revue critique la taille : divisez en 2 PR — (A) helpers de télémétrie + tests, (B) câblage agent.ts + tests e2e. Les helpers atterris en premier ne changent pas le comportement à l’exécution.

Stratégie de test

Cas limites

Rollback

La modification est additive au niveau OTel — les tableaux de bord existants qui ne filtrent pas sur les noms de spans liés aux sous-agents continuent de fonctionner. Les consommateurs de traces qui regroupent par span parent verront de nouveaux nœuds qwen-code.subagent entre qwen-code.tool et qwen-code.llm_request ; à documenter dans les notes de version.

Le changement comportemental est le saut du LogToSpanProcessor — les tableaux de bord qui consommaient auparavant la span qwen-code.subagent_execution renvoient zéro. Atténuation : conserver le LogRecord intact (RUM + métriques le voient encore) ; seul le pont de span est supprimé. Les requêtes existantes basées sur les logs ne sont pas affectées.

Chemin de rollback : annuler la seule PR. Les nouvelles helpers de span ne sont invoquées que depuis agent.ts ; supprimer le câblage + le saut du LogToSpanProcessor restaure le comportement antérieur à l’identique.

Implications d’échantillonnage

Pour la valeur par défaut actuelle de qwen-code (selon tracer.ts:shouldForceSampled() — parentbased + always_on sinon always_on), chaque span est échantillonnée, donc la divergence n’a pas d’impact. Pour les déploiements utilisant des échantillonneurs probabilistes (par ex. traceidratio=0.1), cela signifie :

• Une invite utilisateur peut être échantillonnée (T0 entièrement capturée) mais sa fork (T1) peut être abandonnée, ou l’inverse.
• Les opérateurs lisant le parent T0 voient “Lien : sous-agent C (T1)” — cliquer dessus peut renvoyer une 404 si T1 n’a pas été échantillonnée.

Atténuation : documenter pour les opérateurs. Si la capture complète du sous-agent est importante, forcer l’échantillonnage pour les fork/background via un futur bouton de configuration. Hors périmètre ici.

Attributs sensibles (intégration #4097)

Réutiliser la porte existante includeSensitiveSpanAttributes. Quand elle est vraie, définir sur la span du sous-agent aux points d’accrochage du cycle de vie où les données sont disponibles :

Tout cela est déjà protégé par la porte ; le modèle de #4097 est d’appeler la helper addSubagentSensitiveAttributes(span, opts) depuis l’intérieur du corps. Détail d’implémentation — la conception note simplement le point d’intégration.

Ordonnancement

• Indépendant de #4367 (attributs de ressource — en relecture). Pas de contrainte d’ordre de fusion, mais gen_ai.conversation.id sur les spans de sous-agent bénéficie du déplacement de session.id hors ressource de #4367. Recommandation : merger d’abord #4367 pour que la source de vérité getSessionId() soit stable.
• Indépendant de la phase 4 (décomposition de requête LLM / TTFT). La phase 4 s’attache aux spans qwen-code.llm_request qu’elles soient sous un sous-agent ou une interaction. Recommandation : phase 3 avant phase 4 pour que les métriques par tentative de la phase 4 puissent être agrégées par sous-agent.

Questions ouvertes

1. gen_ai.provider.name : la spec l’exige mais écrit la description pour le fournisseur LLM, pas pour le framework agent. Mettre 'qwen-code' est la meilleure interprétation ; si une révision future de la spec ajoute une variante agent.provider.name, nous devrions changer.
2. Nom de span qwen-code.subagent vs spec invoke_agent {name} : cohérence interne choisie. Si l’adoption d’outils GenAI-aware croît et que invoke_agent ${name} devient critique pour l’auto-découverte, nous pouvons changer — le nom de span est l’élément le plus rebrandable d’OTel.
3. Avertissement soft à profondeur ≥ 5 : nombre arbitraire. Pourrait être un bouton de configuration. Reporter jusqu’à ce que les données de production montrent un besoin.
4. SubagentExecutionEvent.result contient toute la sortie LLM, qui est volumineuse : aujourd’hui cela gonfle le volume des LogRecords. Le plan de migration (LogRecord → événements de span) est reporté mais mérite d’être fait une fois que l’agrégation de tokens-usage atterrit dans la phase 4.
5. Les spans de pont de log à l’intérieur d’une fork aboutissent sur le traceId dérivé de la session, pas sur le T1 de la fork : voir les cas particuliers. La correction est le problème plus large “la span d’interaction n’hérite pas du contexte racine de la session” soulevé dans le thread sessionId-vs-traceId — une conception séparée qui affecte toutes les spans natives, pas seulement le sous-agent. Hors périmètre.