Following on https://github.com/garyd203/xraysink/issues/22

I noticed the use of AsyncContext for FastApi, is this using the xraysink or aws sdk? Is it needed?

I've attempted an implementation with either and have found that my async request handlers are unable to retrieve the context. This leads to AttributeErrors or just general errors where the segment cannot be found

My question is, how can I make xray trace my calls to the database, this would be a background task. Currently you can see that the task is running but it does not give me information about the host and also the task is repeated, what is this due to?

AWS-RAY conf

This is aws-trace

This is my async task

Very cool - thanks for the FastAPI middleware. Since the middleware means we don't have to decorate each function, i have the opposite problem - a situation where i'd like to exclude tracing for a particular endpoint. Is there a pattern for that which the AWS X-Ray SDK uses in cases like that? A function decorator? A path config used by the middleware?

I'm trying to get this going, but feeling like the documentation is confusing.

xray_recorder.configure(context=AsyncContext(), service="my-cute-little-service")

# Create a FastAPI app with various middleware
app = FastAPI()
app.add_middleware(MyTracingDependentMiddleware)  # Any middleware that is added earlier will have the X-Ray tracing context available to it
app.add_middleware(BaseHTTPMiddleware, dispatch=xray_middleware)

• which BastHTTPMiddleware is this referring to?
• what is xray_middlewhere
• do we import xraysink anywhere?
• I'm using decorators on my endpoints @xray_recorder.capture_async("status") should I continue using these?

In some scenarios (e.g. health check of lambda function behind ALB/multi target group), there is no host headed provided. It seems that with the fastapi integration, this breaks execution of this library. I added a fallback, which in the best case would be configurable later.

relates to https://github.com/garyd203/xraysink/issues/65

Whenever a new commit is pushed to master (TBD: Or maybe some other trigger like setting a tag???), automatically do a minor version release, with associated version bumping and whatnot.

desired actions:

• validate we are on master
• run tests (again)
• bump package version (in multiple places) from 1.2.3-rc to 1.2.3
• ~check git tag matches in-code version~
• do poetry build, smoke test on artifact, then poetry publish
• add git tag (and implied github release)
• bump package version to 1.2.4-rc for continued development

Ideas for a trigger:

1. X create an issue by me, with a specifically formatted subject, or special label
2. X use a deployment ?? Not sure that makes conceptual sense
3. do a release. That's back to front though, I feel.
4. X also rely on the workflow_run:completed event for a dependent workflow
5. create a tag. this is identical to creating a release, really.
6. -->> manually run the workflow https://docs.github.com/en/actions/managing-workflow-runs/manually-running-a-workflow

one method that might work:

• use a script to bump version strings and add tag, and push upstream
• have a workflow that listens for the tag and does the rest

subsegment parents should work correctly. Use case is a request handler that spawns multiple asyncio tasks, and then gathers them all together to compose the response (eg. tartiflette)

My working theory is that aws-xray-sdk has a bug where it copies a reference to the context dictionary onto a new task, rather than deep/shallow -copying the values. This menas that subsegments do push/pop on the same list, so the push/pop could be interleaved in an incorrect order.

This bugfix should definitely be moved into the upstream aws-xray-sdk-python repo as a PR.

• [x] Use the standard coverage module
• [x] integrate with a normal pytest run using pytest-cov
• [x] read doc for plugin and main module to find interesting features
• [x] configure
• [ ] https://github.com/wemake-services/coverage-conditional-plugin if necessary
• [ ] set static contexts
• [x] set up to show "something" in a PR. don't worry about 3rd party tools (boo!). Options:
  • https://github.com/orgoro/coverage
  • https://github.com/marketplace/actions/python-coverage-comment <- probably better, but more complex to setup
  • https://github.com/marketplace/actions/code-coverage-summary mebbe
• [x] configure badge in readme
  • functionality in python-coverage-comment via shields.io
  • https://github.com/marketplace/actions/coverage-py-badge
• [x] check plugin works for a real code change

Add a default bug+usage checklist to help users find problems on their own. Perhaps also add to doco. See some ideas for content in the discussion in #88

When FastAPI runs a non-async dependency or handler, it puts it into an internal thread pool so that the async execution doesn't get blocked. I'm pretty sure that the trace context doesn't get propagated into that thread pool (see Sean's problem in #88), which is obviously undesirable. It'd be nice if this worked seamlessly instead.

We probably need a new context (or just extend the existing no-bugs AsyncContext in xraysink) which can hook into FastAPI's specific non-async dispatch in order to add the trace context to those calls. Size could be fairly large!

Hi, I am trying to utilize this library to implement X-Ray into my FastAPI api.

I have the following code:

    xray_recorder.configure(context_missing="LOG_ERROR")
    xray_recorder.configure(service="API DEV")
    xray_recorder.configure(plugins=("ECSPlugin",))
    xray_patch_all()
    app.add_middleware(BaseHTTPMiddleware, dispatch=xray_middleware)

But on each request I send, I see the daemon only receives 1 segment. Usually with a response time of 0.04ms, which definitely isn't the case. I see that this segment is sent before the response is even sent to the client.

Along with this, the following is logged in my application: cannot find the current segment/subsegment, please make sure you have a segment open

Is there a working example of this working with FastAPI? Am I missing something here? Thanks!

The documentation assumes you know what you are doing, and that you only want to fix some of the known problems. As an alternative use case ,provide a convenience function that patches everything global and returns the recorder object