Initialize Trace Context for Service Bus Trigger using message "Diagnostic-Id"
Nobody has claimed this yet.
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 38/100
- Issue type
- Bug
- Clarity
- Mostly clear
- Activity status
- Stale
- Tech stack
- azure, typescript
- Domain
- backend, observability
Research direction
Start by reproducing the Service Bus topic-to-subscription trigger described in the issue and inspect where the worker initializes context.traceContext. Verify the Service Bus message's Diagnostic-Id is used, and confirm built-in request/response logging and context.log entries share the resulting correlation context.
Written by the indexing model from the issue text.
Description
Investigative information
Please provide the following:
Test was run locally, but if needed can setup a "on cloud" reproduction.
Repro steps
- Create a Service Bus Triggered function (Topic -> Subscription)
- Connected with AppInsights
- Add some traces via
context.log - throw an error so as the processed messages gets moved to the DLQ (makes it easier to debug)
- Fire a service bus event for subscription
Expected behavior
When a Service Bus triggered function is executed, I would expert the context.traceContext to be initialized using the Service Bus message Diagnostic-Id.
Actual behavior
The function seems to just initialize a brand new traceContext (not correlated to anything).
Known workarounds
Using the AppInsights wrapWithCorrelationContext, a traceContext can be initialized with the Diagnostic-Id being manually overridden as the traceParent.
// Default export wrapped with Application Insights FaaS context propagation
export default async function contextPropagatingHttpTrigger(context, message) {
// overwrite with the proper traceparent from the message.
const sbTraceParent = context.bindingData.applicationProperties['diagnostic-Id'];
if (sbTraceParent) {
context.traceContext.traceparent = sbTraceParent;
}
const correlationContext = appInsights.startOperation(context, req) as CorrelationContext;
// Wrap the Function runtime with correlationContext
return appInsights.wrapWithCorrelationContext(async () => {
try {
appInsights.defaultClient.trackTrace({
message: 'Correct Trace Context',
});
//wrong operation_Id
context.log('Incorrect Trace Context');
return await trigger(context, message);
} catch (e) {
context.log.error(e);
throw e;
} finally {
// Track Request on completion
appInsights.defaultClient.flush();
}
}, correlationContext)();
}
However, doing so only partially works.
- The "out of the box" request/response logging will still be done using the initial
traceContext - Any calls to
context.logwill still use the initial trace context.
Message In Service Bus
Request Logged Against Initial TraceContext
Traces from AppInsights Correlation Context
- Dominant language
- TypeScript
- Stars
- 110
- Forks
- 52
- Avg merge
- 7h 33m
- Merged PRs (30d)
- 1
Getting set up
This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from Azure/azure-functions-nodejs-worker
-
Handle valid prerelease Node.js versions without failing worker initializationPossibly taken @TsuyoshiUshio claimed this 59 days ago. Open
Difficulty 2/5 1-3 hours Newbie friendliness 74/100
-
area:nodejs-functions dependencies engineering tests
Difficulty 5/5 Over a week Newbie friendliness 35/100
-
Specialization race: double startApp() with stale require cache leaves worker on default v3 model with all functions unloadablePossibly taken @swapnil-nagar claimed this 65 days ago. Open
Difficulty 5/5 Over a week Newbie friendliness 30/100
Azure/azure-functions-nodejs-worker#838 · 1 comment ·
-
c-ares DNS misconfiguration on Windows Consumption causes mongodb+srv:// and dns.resolve*() failuresOpen
Difficulty 4/5 3-5 days Newbie friendliness 64/100
Azure/azure-functions-nodejs-worker#830 · 1 comment ·
-
Difficulty 4/5 3-5 days Newbie friendliness 48/100
All issues in Azure/azure-functions-nodejs-worker
Similar issues
-
type: bug
Difficulty 2/5 1-3 hours Newbie friendliness 79/100
Maintainers usually reply within 1 day
-
0️⃣ phase/new
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
-
Difficulty 1/5 Under an hour Newbie friendliness 70/100
microsoft/playwright#43640 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 70/100