Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Middlewares should create subsegments only when in the Lambda context running under a Lambda environment #138

Closed
chanchiem opened this issue Feb 27, 2019 · 1 comment
Assignees
Labels

Comments

@chanchiem
Copy link
Contributor

The current behavior of the Middlewares is that it opts to generate subsegments only if the current execution environment is in lambda, otherwise it generates segments.

This is problematic if customers choose to create their own custom context and proceed to use that context in a Lambda environment. If for example the custom context is designed to allow users to call put_segment and end_segment, the middlewares would still call begin_subsegment if the context is run in a Lambda environment.

The expected behavior of the middleware is to only generate subsegments if it's in a Lambda context running in the Lambda environment, and if the middleware is run otherwise, it should only generate segments.

@chanchiem chanchiem added the bug label Feb 27, 2019
@chanchiem chanchiem self-assigned this Feb 27, 2019
@chanchiem chanchiem changed the title Middleware should create subsegments only when in the lambda context and lambda environment Middlewares should create subsegments only when in the lambda context and lambda environment Feb 27, 2019
@chanchiem chanchiem changed the title Middlewares should create subsegments only when in the lambda context and lambda environment Middlewares should create subsegments only when in the Lambda context running under a Lambda environment Feb 27, 2019
@chanchiem
Copy link
Contributor Author

chanchiem commented Feb 27, 2019

Case Study: Using the default Context in a Lambda environment

Prior to PR #127, using the default Context (as opposed to the LambdaContext) in a Lambda environment would generate a valid root segment. This happened because the trace ID was propagated from the lambda container and received from the middleware in the SDK to construct a segment whose trace ID matched the Lambda-generated ID. Although this is not a fully supported work around, the introduction of the PR should not change the behavior of what originally happened. The original service graph that used the default Context in Lambda prior to the PR looked like this:
image
Although this is valid for functional purposes, it doesn't provide the expected service graph because there is no causal relationship between the middleware and the Lambda function.

And for completeness, this is what the Service graph looks like after the PR using the LambdaContext in a Lambda environment as intended:
image


With the introduction of the PR, middlewares generated subsegments inside Lambda environments and caused SegmentMissingExceptions whenever the default Context was used. This issue points out that middlewares should still exhibit the same behavior and attempt to beginSegments whenever a context other than the LambdaContext is used.

chanchiem added a commit to chanchiem/aws-xray-sdk-python that referenced this issue Feb 27, 2019
…nvironment (aws#138)

* Added unit tests to ensure these frameworks generate segmentby default and
subsegments if in lambda context and environment.
chanchiem added a commit to chanchiem/aws-xray-sdk-python that referenced this issue Feb 27, 2019
…nvironment (aws#138)

* Added unit tests to ensure these frameworks generate segmentby default and
subsegments if in lambda context and environment.
chanchiem added a commit to chanchiem/aws-xray-sdk-python that referenced this issue Feb 27, 2019
…nvironment (aws#138)

* Added unit tests to ensure these frameworks generate segmentby default and
subsegments if in lambda context and environment.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant