test(fastmcp): Span streaming tests

[alexander-alderman-webb]

Description

The following tests are not parametrized since they have no assertions on spans:

• test_fastmcp_tool_with_none_return()
• test_fastmcp_tool_with_no_arguments()
• test_standalone_fastmcp_specific_features()
• test_mcp_fastmcp_specific_features()
• test_fastmcp_prompt_async()

---

Adapting Tests

sed commands used for converting transaction context managers:

• sed -i '' 's/start_transaction(name="standalone fastmcp tx")/sentry_sdk.traces.start_span(name="custom parent")/g'
• sed -i '' 's/start_transaction(name="fastmcp tx")/sentry_sdk.traces.start_span(name="custom parent")/g'

sed commands used for converting event capture:

• sed -i '' 's/capture_events,/capture_items,/g'
• sed -i '' 's/events = capture_events()/items = capture_items("event", "transaction", "span")/g'
• sed -i '' 's/tx["spans"]/spans/g'
• sed -i '' 's/assert len(tx["spans"]) == 1/assert len(spans) == 2/g'
• sed -i '' 's/span = tx["spans"][0]/span = spans[0]/g'
• sed -i '' 's/span = tx["spans"][0]/span = next(item.payload for item in items if item.type == "span")/g'
• sed -i '' '/(tx,) = events/d'

sed commands used for converting op:

• sed -i '' 's/["op"]/["attributes"]["sentry.op"]/g'
• sed -i '' 's/span["op"]/span["attributes"]["sentry.op"]/g'

sed commands used for converting origin:

• sed -i '' 's/["origin"]/["attributes"]["sentry.origin"]/g'

sed commands used for converting description:

• sed -i '' 's/description/name/g'

sed commands used for converting data to attributes:

• sed -i '' 's/["data"]/["attributes"]/g'

sed commands to remove transaction assertions:

• sed -i '' '/assert tx["type"] == "transaction"/d'

Issues

Reminders

• Please add tests to validate your changes, and lint your code using tox -e linters.
• Add GH Issue ID & Linear ID (if applicable)
• PR title should use conventional commit style (feat:, fix:, ref:, meta:)
• For external contributors: CONTRIBUTING.md, Sentry SDK development docs, Discord community

[github-actions]

Codecov Results 📊

✅ 1917 passed | ⏭️ 318 skipped | Total: 2235 | Pass Rate: 85.77% | Execution Time: 3m 43s

All tests are passing successfully.

✅ Patch coverage is 100.00%. Project has 12733 uncovered lines.

---

Generated by Codecov Action

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit 503a5ba. Configure here.}

[ericapisani]

I had followed a somewhat similar pattern in another PR and had received feedback that we're trying to avoid this approach of selectively getting spans like this (filtering and matching on the op) because it removes some of the implicit assumptions that we're making about the amount of spans that we're emitting and their order.

Maybe something to sync about when we're all online so that we're all using the same approach going forward 😄

[alexander-alderman-webb]

In this case, the logic in the else: branch for the transaction-based variant has the same filter.

In general I'm trying to stay as close as possible to this philosophy (from the review comment you linked).

I'd advocate for following the logic in the old branch as close as possible, without any extra filtering or sorting of spans

If there are other improvements to the tests we can still discuss and make them in a follow-up but I'd consider them out of scope for porting the tests to span-first.

What do you think?

[ericapisani]

If there are other improvements to the tests we can still discuss and make them in a follow-up but I'd consider them out of scope for porting the tests to span-first.

Yeah that's fair to leave these improvements out of scope for this PR, I wouldn't want this to be overloaded with a number of different changes.

My earlier comment was more to note the inconsistency we have if testing the implicit assumptions is important within this project, and wanting to ensure tests are ported over to the correct approach as part of the migration process if we can fit it in since the old version of the tests will be removed soon and we likely won't come back to this afterwards.

[alexander-alderman-webb]

Gotcha. I think there are different levels of implicit assumptions:

• Lines similar to (span, ) = spans have an implicit assumption that there is only one span, as otherwise the test fails with a ValueError.
• Lines like (client_span, tool_span, ) = spans also have an ordering assumption. There is an implicit assumption that exactly 2 spans have been captured, and that the client_span is captured before the tool_span.

As for preferring one approach over another, I think it depends if you only test positive features (the span that I intend to create is there), or also the absence of other spans. I'm not aware of either approach being prescribed over the other.

I also don't think we provide a guarantee on the ordering of spans, so lines like (client_span, tool_span, ) = spans probably just exist because it's the shortest syntax to extract the spans 🤷 .