Ensure we handle the scenario the payment service code expects there to be an active span but finds none

[keyoke]

I am proposing a very minor change to handle when auto-instrumentation is disabled( similar to #2124 ) for the payment service. In this scenario, an exception is raised but I would expect it to be handled gracefully.

Changes

Added some very simple logic to check if the current active span is undefined, if it is we create a new span & mark this as the active span.

Merge Requirements

For new features contributions, please make sure you have completed the following
essential items:

• CHANGELOG.md updated to document new feature additions
• Appropriate documentation updates in the docs
• Appropriate Helm chart updates in the helm-charts

Maintainers will not merge until the above have been completed. If you're unsure
which docs need to be changed ping the
@open-telemetry/demo-approvers.

[linux-foundation-easycla]

The committers listed above are authorized under a signed CLA.

• ✅ login: puckpuck / name: Pierre Tessier (7f1bed4)
• ✅ login: julianocosta89 / name: Juliano Costa (2d4be41)
• ✅ login: keyoke / name: GarethE (e1f72f3, 2f9eb59, 28e0d1a, 29eb717)

[julianocosta89]

@pichlermarc I would love to hear your opinion here

[puckpuck]

I understand if the SDK is disabled, the service should not throw an error which is what #2124 discusses.

I struggle to understand in what scenario we need to start a trace if one does not exists.

[pichlermarc]

I struggle to understand in what scenario we need to start a trace if one does not exists.

I agree - in my opinion the way to address the problem of the crashing app would be either to:

• optional chain on the span object obtained via getActiveSpan() wherever it's used
  • example: span.setAttributes({...}) -> span?.setAttributes({...})
• create and end an internal span always no matter if a trace was already started or not to which you can attach any attributes and errors you like, while retaining semantics for the grpc span that's likely being modified here (since that one is strictly supposed to follow the gRPC semconv anyway and modifying error status may interfere with that).

[github-actions]

This PR was marked stale due to lack of activity. It will be closed in 7 days.

[julianocosta89]

@pichlermarc this is the issue I've mentioned to you during KubeCon.
Would you mind taking a look?

[github-actions]

This PR was marked stale due to lack of activity. It will be closed in 7 days.

[pichlermarc]

@julianocosta89 - sorry for the delay. This looks good.
Thank you @keyoke for working on this 🙂