The question is about when rootTraceContext gets reused after extraction failure. Looking at the recent commit, there was
  a bug where rootTraceContext wasn't being reset between invocations, causing unintentional caching.
Based on the extraction flow, the rootTraceContext would be reused (before the recent fix) in these scenarios:

  Event payloads that would reach XRay fallback extraction:

  1. Plain object events without recognized structure - Events that don't match any of the supported event types (HTTP, SNS,
   SQS, Kinesis, EventBridge, etc.) and have no custom extractor configured.
  2. Events where all extraction methods fail - For example:
    - HTTP events with malformed or missing trace headers
    - SNS/SQS events without proper trace context in message attributes
    - Kinesis events with corrupted or missing trace data
    - Events where the Lambda context itself has no X-Ray trace information
  3. Malformed events - Events that are not objects or have unexpected structure that causes extractors to return null.

  Example event payloads that would reach XRay extraction:
  // Plain custom event with no trace headers
  { "customData": "value", "timestamp": 123456789 }

  // HTTP event with missing/invalid trace headers  
  { "headers": {}, "body": "..." }

 // SNS event with no trace context in message attributes
  { "Records": [{ "Sns": { "Message": "...", "MessageAttributes": {} } }] }