Don't enforce span name length limit for spans the SDK logs

[bidetofevil]

Goal

Names of spans we record internally can be longer than than the custom performance traces that we have a name length restriction for. Make the validate not apply to spans logged by the SDK, i.e. internal = true.

[bidetofevil]

• Hook up Activity Open tracing component #1348
• Remove startup trace recording callback once it's logged startup #1347
• Create callback mechanism to run code post app startup #1346
• Create annotation to opt into activity open tracing #1345
• Component to map lifecycle events to the activity open events #1320
• Add comopnent to create an activity open trace based on a sequence of events #1319
• Add emb.type for spans that track activity opening #1318
• Rename properties and test code related to activity lifecycle tracking and testing #1317
• Don't enforce span name length limit for spans the SDK logs #1125 👈
• main

This stack of pull requests is managed by Graphite. Learn more about stacking.

Join @bidetofevil and the rest of your teammates on Graphite

[codecov]

Codecov Report

Attention: Patch coverage is 83.33333% with 1 line in your changes missing coverage. Please review.

Project coverage is 82.93%. Comparing base (27567c7) to head (27d973f).
Report is 2 commits behind head on main.

Files with missing lines	Patch %	Lines
...droid/embracesdk/internal/spans/SpanServiceImpl.kt	75.00%	0 Missing and 1 partial ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #1125      +/-   ##
==========================================
+ Coverage   82.84%   82.93%   +0.09%     
==========================================
  Files         484      484              
  Lines       11041    11041              
  Branches     1699     1699              
==========================================
+ Hits         9147     9157      +10     
+ Misses       1152     1144       -8     
+ Partials      742      740       -2     

Files with missing lines	Coverage Δ
...droid/embracesdk/internal/spans/EmbraceSpanImpl.kt	89.40% <100.00%> (ø)
...droid/embracesdk/internal/spans/SpanServiceImpl.kt	88.88% <75.00%> (ø)

... and 3 files with indirect coverage changes

[github-actions]

Dependency Review

✅ No vulnerabilities or license issues or OpenSSF Scorecard issues found.

OpenSSF Scorecard

Package	Version	Score	Details

Scanned Manifest Files

[github-actions]

This PR is stale because it has been open 20 days with no activity. Remove stale label or comment or this PR will be closed in 10 days.

[fractalwrench]

IMO the SDK should still enforce a limit that prevents span names from being unbounded, but I'd be happy for it to be longer than what we allow for customers. Is increasing the span name length for customers so that only one limit applies universally also a simpler option?

(This all assumes the backend hasn't made any assumptions about span name length, too)

[bidetofevil]

I wanna say there's already an implicit length that is enforced at the OTel SDK level (there is for most span things), so if we can configure that to what we want, lets use that. If not, I'll add another mechanism for this.

What's reasonable for us - 2K chars?

[fractalwrench]

Sounds reasonable!

[fractalwrench]

LGTM

[bidetofevil]

Merge activity

• Sep 11, 12:42 PM EDT: @bidetofevil started a stack merge that includes this pull request via Graphite.
• Sep 11, 12:43 PM EDT: Graphite rebased this pull request as part of a merge.
• Sep 11, 1:15 PM EDT: @bidetofevil merged this pull request with Graphite.