fix(common): graceful fallback when LambdaTraceProvider is unavailable#1176
fix(common): graceful fallback when LambdaTraceProvider is unavailable#1176
Conversation
#1173) XRayTraceId now probes for LambdaTraceProvider.CurrentTraceId on first access and caches the result. When the type is not available (customers on Amazon.Lambda.Core < 2.8.0), it falls back to reading the _X_AMZN_TRACE_ID environment variable — matching pre-3.1.0 behaviour — instead of throwing a TypeLoadException at runtime. Closes #1173
Instance method was setting a static field. Refactored to accept a Func<string> fallback so the method can be fully static.
There was a problem hiding this comment.
Pull request overview
This PR prevents runtime TypeLoadException for customers running Amazon.Lambda.Core < 2.8.0 by making PowertoolsConfigurations.XRayTraceId gracefully fall back to the _X_AMZN_TRACE_ID environment variable when LambdaTraceProvider is unavailable, while preserving the LambdaTraceProvider.CurrentTraceId path when present.
Changes:
- Add a first-access probe + cached availability flag for
LambdaTraceProvider, with env-var fallback onTypeLoadException. - Isolate the
LambdaTraceProvider.CurrentTraceIdcall behind a[MethodImpl(NoInlining)]method to avoid eager type loading. - Add unit tests covering provider-available, fallback, and cached behavior paths.
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 5 comments.
| File | Description |
|---|---|
libraries/src/AWS.Lambda.Powertools.Common/Core/PowertoolsConfigurations.cs |
Introduces a cached probe for LambdaTraceProvider availability and env-var fallback for XRayTraceId. |
libraries/tests/AWS.Lambda.Powertools.Common.Tests/Core/PowertoolsConfigurationsTest.cs |
Adds unit tests for XRayTraceId provider vs fallback behavior and caching behavior. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
libraries/src/AWS.Lambda.Powertools.Common/Core/PowertoolsConfigurations.cs
Show resolved
Hide resolved
libraries/tests/AWS.Lambda.Powertools.Common.Tests/Core/PowertoolsConfigurationsTest.cs
Outdated
Show resolved
Hide resolved
libraries/tests/AWS.Lambda.Powertools.Common.Tests/Core/PowertoolsConfigurationsTest.cs
Outdated
Show resolved
Hide resolved
libraries/tests/AWS.Lambda.Powertools.Common.Tests/Core/PowertoolsConfigurationsTest.cs
Show resolved
Hide resolved
libraries/tests/AWS.Lambda.Powertools.Common.Tests/Core/PowertoolsConfigurationsTest.cs
Outdated
Show resolved
Hide resolved
- Thread safety: replace bool? with int + Volatile.Read/Write for atomic access to _traceProviderState across concurrent invocations - Tests: add try/finally with ResetTraceProviderState to prevent cross-test contamination of static state - Tests: Assert.NotNull on reflection field lookups so tests fail loudly if the field is renamed - Tests: rename caching test to clarify it covers cached-unavailable path, not the initial probe - Tests: remove invalid assertion on return value (LambdaTraceProvider returns null in test env with no active trace)
|
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## develop #1176 +/- ##
===========================================
- Coverage 79.43% 79.42% -0.01%
===========================================
Files 302 302
Lines 12636 12654 +18
Branches 1505 1507 +2
===========================================
+ Hits 10037 10051 +14
- Misses 2141 2145 +4
Partials 458 458 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
|
@aws-powertools/powertools-lambda-net No related issues found. Please ensure 'pending-release' label is applied before releasing. |



fixes #1173
Summary
Changes
Fixes
TypeLoadExceptionfor customers onAmazon.Lambda.Core < 2.8.0who upgrade Powertools Logging to 3.1.0+.XRayTraceIdnow probes forLambdaTraceProvider.CurrentTraceIdon first access via a[MethodImpl(NoInlining)]isolated method, caches the result, and falls back to the_X_AMZN_TRACE_IDenvironment variable when the type is unavailable. No reflection — AOT-compatible.User experience
Before: Customers on
Amazon.Lambda.Core < 2.8.0get aTypeLoadExceptionat runtime when the logger tries to resolveLambdaTraceProvider.After: The logger gracefully falls back to reading the
_X_AMZN_TRACE_IDenvironment variable (matching pre-3.1.0 behaviour). Customers onAmazon.Lambda.Core >= 2.8.0continue to get correct per-invocation trace ID isolation for LMI.Checklist
Is this a breaking change?
RFC issue number:
Checklist:
Acknowledgment
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.
Disclaimer: We value your time and bandwidth. As such, any pull requests created on non-triaged issues might not be successful.