A reference issue is on the sentry-cocoa repository which describes thing in detail.

It also links related PRs:

getsentry/sentry-python#856
getsentry/sentry-java#1082

One more related PR: getsentry/sentry-dotnet#640

Transaction docs doesn't contain an example of a full valid transaction payload. It has an example showing contexts.trace and spans but not the rest of the fields. Ideally, there should be an example of a minimum valid transaction payload (with only required fields set) and a maximum valid transaction payload (with all of the fields set).

source #221

This is a follow-up to an incident we had -- this won't prevent the root cause of the incident, but it is important that this is documented well.

In SDK Expected Features we need some guideline of what we expect from integrating with HTTP clients in SDKs, when that's possible.

For example:

• Add a breadcrumb to the Scope (so error events show that request)
  • Mention the breadcrumb categories and types that make sense here. Include HTTP status.
  • category could be the name of the HTTP integration. Type is http. Docs
• Get some metrics (that for now can go as breadcrumb.data Example: bytes In, Bytes Out).
• Should the SDK raise an event if a 5xx comes? If so what contexts.. If not, how does it propagate context upstream?

If Performance Monitoring is supported by the SDK:

• Create a Span, child to the current Span bound to the Hub
• Finish the span as success or failure depending on response HTTP status (500 is a failed Span)
  • We need to align/discuss 4xx and other status code range.
• Include sentry-trace id to propagate a transaction downstream. Link to specific docs.

Link to some examples:

.NET
Java
Python

on Java/.NET we don't discard Spans that are not finished, we send as it is, but Python discards them.
Relay drops unfinished spans so we remove them from a transaction before sending.

https://github.com/getsentry/sentry-python/blob/master/sentry_sdk/hub.py#L497-L505

what are the trade-offs here? what would be the right approach? I'd prefer to unify this behavior, either on Python or Mobile SDKs.

In the beginning, I wanted to finish all spans automatically when the transaction.finish was called, but this was likely hiding bugs on the client's code (finishing without status? meh), so we've decided to send it as it is.

cc @bruno-garcia @untitaker @Tyrrrz @maciejwalkowiak @brustolin @rhcarvalho

Was running through the Azure devops integration page. The documentation links the Azure Devops site to create a new application while also providing instruction on what to set. In situations like these, the external link shouldn't replace the tab as its still needed.

As discussed on the call with @bruno-garcia and @maciejwalkowiak, the docs on transaction & span (i.e. the performance feature) are lacking. Currently, it's really hard to implement this feature correctly as it requires a lot of guessing, reverse-engineering and asking people questions, all of which should ideally be answered by the documentation.

Issues:

• Transaction docs doesn't contain an example of a full valid transaction payload. It has an example showing contexts.trace and spans but not the rest of the fields. Ideally, there should be an example of a minimum valid transaction payload (with only required fields set) and a maximum valid transaction payload (with all of the fields set).
• Transaction/span schemas are missing from https://github.com/getsentry/sentry-data-schemas/blob/main/relay. Adding them would be very helpful. (Issue raised here getsentry/sentry-data-schemas#2 )
• The docs on transaction mention that "Transactions are Events enriched with Span data". Does it imply that all event fields are valid and make sense on transaction? For example, would having exception data make sense on transaction? Currently, it's not clear what is the actual contract of the transaction payload.
• The docs should mention that relay may return 200 OK on invalid transactions (not sure if by design or a bug). For example, a transaction that doesn't have contexts.trace will get accepted by the relay but won't show up on the portal. Generally speaking, a list of common issues and solutions would be nice.
• The docs say that "transactions are events with span data", but only briefly mention that the span data is actually stored inside contexts.trace. I think this part should be emphasized because it makes no sense from the consumer perspective, but at the same time has critical implications on the design of the SDK.
• The docs say that the span data is included within contexts.trace, but it's not completely true. Some fields like start/end timestamps and description are included on the object itself, despite also being part of "span data". There is an example of contexts.trace in the docs, but again, it's not clear whether it's exhaustive or not. What about tags and data, are they also on contexts?
• The docs on spans don't cover the span_id/parent_span_id/sampled fields and potentially some others. What is the list of fields required/allowed on spans?
• SpanId and ParentSpanId appear to be half the length of other Id fields (i.e. 16 characters instead of 32). The docs don't cover how these IDs are generated, nor say anything about this limitations. Some SDKs are generating these IDs by truncating UUIDs, which is wrong. There should be some guidance regarding this. Edit: looks like it's not actually a problem
• The docs on spans start with "This interface is an object with a single values attribute containing an ordered list of Span objects. Spans in the list don't have to be ordered, they will be ordered by start / end time on the Server.", which is not true. The span does not have a values attribute (at least to my knowledge).
• The docs on spans show an array of spans as an example, which is confusing as it's not clear whether the span itself contains other spans or is just a list of spans from the transaction.
• The docs mention that transaction is a hierarchy of spans, but doesn't cover how they are stored. Does each span contain its own list of spans? Or do the spans gets projected onto a planar list inside of the transaction?
• The docs don't provide information regarding how the transaction and event get linked together.
• The docs on transaction/spans should link to https://develop.sentry.dev/sdk/unified-api/tracing. I had no idea this article existed and it could have probably answered many of my questions.
• Apparently, when running on the backend, the op must always be set to http.server. Would be nice if this was documented too.

The docs don't provide information regarding how the transaction and event get linked together.

ideally, https://develop.sentry.dev/sdk/event-payloads/contexts/ should document the trace object and required fields

The Scope has a transaction field and it exposes a setter.

https://develop.sentry.dev/sdk/unified-api/#scope

This is now diverging because of the performance feature.
Should we keep it or not? does it get replaced by the performance feature or not?

on .NET
The transaction field still exists and coexists with the performance feature, they are totally separated features, they don't touch each other.

While on Java, the transaction does not exist anymore, it got replaced by the performance feature, which means, calling setTransaction on Java, reads the active transaction in the scope and overwrites its name.

We should document & unify this behavior.

@rhcarvalho @bruno-garcia @Tyrrrz @maciejwalkowiak @HazAT @brustolin

https://develop.sentry.dev/sdk/event-payloads/contexts/

Apparently, it's the same as a Span, that's what I learn here https://develop.sentry.dev/sdk/event-payloads/transaction/#contextstrace
if so, it'd be nice to add an Entry to the Contexts page and link to the Spans one

@brustolin

Some edge cases to agree on the behavior:

• Transactions should have a max number of spans. If new spans are added once the max is reached, the SDK should drop them and ideally use the internal logging to help debugging.
  • This is to help avoid a transaction that never finishes, ending up on a OOM or just sluggish performance.

The goal is to avoid that a user error, or an integration error that ends up with a leaked transaction that, doesn't cause a app crash. This is particularly important on long running processes.

Python sends up to 1k spans to the server. To clarify at which point it truncates off, but the goal here is to avoid keeping objects around forever if the transaction is never finished.

Item Handling Errors goes to https://develop.sentry.dev/sdk/overview/#request-compression
Item Concurrency (Scope and Hubs): goes to https://develop.sentry.dev/sdk/overview/#transfer-encoding

I've tried to figure this out and fix by myself, but it turns out that when running locally (http://localhost:8000/sdk/overview/#handling-errors) everything works fine.

Not sure what's the root cause, but @HazAT already experienced the same problem.
Ping me if I can be of any help.

context: getsentry/sentry-java#1170

@rhcarvalho @HazAT does it make sense to make op an Enum or is it really a plain string? is somewhere documented which ops does our frontend renders nicely? what is used for? etc...

Hi, I was directed to ask questions about session duration to this pull request:

Situation: I have a CLI command that I wish to track duration between commands, one command opens something, the other closes something. In this case, the longer period between session is better. Unlike tracking durations of web request fulfillment, I need to track how long the user has a session open, where "open" means they are using the product. Short durations mean that they aren't really using the product.

What I have tried and would like validation of is the following:

    const timestamp = new Date()
    if (params.clean) { // this is the end of a session, log the duration to sentry
        const startTimestamp: string = await session.get('timestamp')
        const duration = (timestamp as any) - (new Date(startTimestamp) as any)  // in ms

        if (duration) {
            Sentry.getCurrentHub().startSession({ duration, ignoreDuration: false })
            Sentry.getCurrentHub().endSession()
        }
    } else { // This is the start of the session, set the session timestamp.
        Sentry.getCurrentHub().startSession({ ignoreDuration: true })
        await session.set('timestamp', timestamp.toISOString())
        Sentry.getCurrentHub().endSession()
    }

Here, 'clean' means the user is closing a session, otherwise, the session is being opened. We track the start timestamp in our own session object and then calculate the duration from this when the 'clean' is given.

I have also tried:

            Sentry.captureMessage(util.format('%O', { duration: durationSeconds, params, session }))

But I am not sure how this would be useful.

Perhaps this is what I need to do:

    if (params.clean) { // this is the end of a session, log the duration to sentry
        const started: string = await session.get('timestamp')
        if (started) {
            const duration = (new Date() as any) - (new Date(started) as any) // in ms
            const sentrySession: SessionContext = {
                sid: randomUUID(),
                init: true,
                //@ts-ignore
                started: started,
                duration,
                status: SessionStatus.Exited,
                ignoreDuration: false,
                //@ts-ignore
                attrs: {
                    release: '@c6o/cli'
                }
            }
            Sentry.getCurrentHub().startSession(sentrySession)
            Sentry.getCurrentHub().endSession()
        }
    } else { // This is the start of the session, set the session timestamp.
        await session.set('timestamp', new Date().toISOString())
    }

Will this work to record the duration for our open/clean cycles of usage so that we can visualize the results in a dashboard or in the performance area of the Sentry website?

How should this be done?

Originally posted by @robblovell in #323 (comment)

Environment

Document transaction.measurements on https://develop.sentry.dev/sdk/event-payloads/transaction/

Steps to Reproduce

https://develop.sentry.dev/sdk/event-payloads/transaction/

Expected Result

transaction.measurements data structure should be documented

Actual Result

transaction.measurements isn't documented, we have an internal page.

On the SDK development overview page, there is a paragraph saying:

For a list of all supported attributes and interfaces in event payloads, see Event Payloads.

Unfortunately, the link is broken at the moment.

I managed to find https://github.com/getsentry/develop/blob/master/src/docs/sdk/event-payloads/overview.mdx in the meantime :)

Based on https://develop.sentry.dev/sdk/unified-api/tracing#new-span-and-transaction-classes
to finish a transaction or a span, you need to call finish which is meant to be used either if it's a successful or errored transaction.

one needs to:

transaction.status = OK
// or
transaction.status = INTERNAL_ERROR

// and
transaction.finish()

what's about making it more user friendly:

transaction.success() // infers `status = OK` (200)
// or

transaction.error() // infers `status = UNKNOWN` (500)
// or
transaction.error(status = UNKNOWN) // if Language supports default params.

it'd be easier to use and also reducing boilerplate.

same applies for spans

@rhcarvalho @bruno-garcia @Tyrrrz @maciejwalkowiak @HazAT @brustolin

https://develop.sentry.dev/sdk/event-payloads/span/

This is the source code:

This is what is rendered:

So there are things like event_id that were never included in the source and appears in the output, and also things like span_id that is included in the source but doesn't show up in the output.

Maybe as part of SDK Features.

Transports should

• Use TCP keep-alive
• Use connection pooling
• Limit number of concurrent calls to Relay (typically and historically 1 request-at-a-time when sending errors; reconsider for transactions and sessions)
• Set client (read/write) timeout
• Report User-Agent sentry-<platform>/<version> or browser-defined as appropriate

The docs on transaction mention that "Transactions are Events enriched with Span data". Does it imply that all event fields are valid and make sense on transaction? For example, would having exception data make sense on transaction? Currently, it's not clear what is the actual contract of the transaction payload.

Source #221

We currently have a long list of span statuses. Those were inherited from an old, pre-1.0, version of the OpenTelemetry specification.

OpenTelemetry moved on to drastically simplify SpanStatus following OTEP 136.

[...] an existing set of error types without first clearly defining their use and how they might be set has caused confusion.

The extensive list of statuses, without a clear mapping and dubious use across platforms we support (browser, desktop, mobile, web servers, etc), has caused confusion in Sentry too, both for SDK maintainers and end users. For example:

• #307
• Users confused if a span marked as "internal error" means an error in Sentry or in the SDK or in their own code

This issue tracks re-aligning with OpenTelemetry, what means today replacing the existing statuses with:

• Unset (default)
• Ok
• Error

See https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/trace/api.md#set-status for details.

The docs mention that transaction is a hierarchy of spans, but doesn't cover how they are stored. Does each span contain its own list of spans? Or do the spans gets projected onto a planar list inside of the transaction?

source #221

The new Trace Contexts page documents a trace_id that is a UUID, while in the Performance product we do not use UUIDs (neither for trace_id nor span_id).

Reference:

https://develop.sentry.dev/sdk/event-payloads/transaction/#anatomy

trace_id:
Required. Determines which trace the Span belongs to. The value should be 16 random bytes encoded as a hex string (32 characters long).

I'm using sentry-onpremise and I cannot find any info about setting up and using geoip2 in sentry. All I have is a fact that it works in sentry.io (for example, in user settings - session history), and an error in logs:

sentry.utils.geo: settings.GEOIP_PATH_MMDB not configured

I've also seen some GitHub issues with questions about geoip - they've all been closed without any proper explanation. There is no information on the Sentry community forum either - just some unanswered questions.

See also:
getsentry/self-hosted#310

Would it be possible to add to the breadcrumps documentation any limitations ?
On that page (probably) develop/src/docs/sdk/event-payloads/breadcrumbs.mdx

Specially:

• What is the maximum size of a breadcrump message & data ?

• How many breadcrump can be sent per sessions ?

We're exploring APIs that will automatically bind a new transaction to the scope.

So instead of the current documented:

var tran = Sentry.startTransaction('a');
Sentry.configureScope(s -> s.transaction = tran);

It becomes:

// Already binds to scope:
var tran = Sentry.startTransaction('a');

// Or to skip binding it to the scope:
var tran = Sentry.startTransaction('a', bindToScope: false);

Calling tran.finish() results in a call to an internal API such as Sentry.resetTransaction(this) which will compare the reference bound to the scope, and if it's still the same, it'll remove itself. Atomically.

Questions:

1. Does this make sense?
2. Should the default be: bind to scope: true?
3. What happens when there's already something bound to the scope?

• Don't override?
  • User will expect to have that transaction propagated but that won't be the case.
• Finish the old transaction with context: Superseded by TransactionXYZ
  • This will help troubleshoot things though our automatic transactions can be causing this and "breaking" user-defined transaction.
• Override it and don't mess with the old transaction?
  • Likely means it'll just be GC'ed and all data would be lost.

It would be nice if an event has a response interface, just like the request interface.

An application makes a request and gets a response. This response can lead to crashes, by having data with which the application cannot work. Just knowing the request isn't as helpful as having the response as well.

This is especially useful for integrations like getsentry/sentry-dart#473 where HTTP requests can be captured as an exception if the status code is considered "bad". Example: Imaging you want to catch every status code from 400 to 499 as an exception and send it to Sentry. The responses from 400 to 499 often include hints on what's wrong with the request (wrong combination of parameter or whatnot). This information is lost because responses aren't recorded.
This in turn makes this kind of events hard to fix.

Having responses can be useful in non server applications such as mobile or desktop apps, but also for micro-services and servers which communicate via HTTP.

cc @bruno-garcia and @marandaneto because they wanted to hear my insights and learnings from getsentry/sentry-dart#473

If you click on an anchor it doesn't preserve the current page, instead, it always jumps to /

http.server for HTTP servers
http.client for HTTP clients

Context: #242
Also getsentry/sentry-java#1165 (comment)

Python does http for HTTP clients
https://github.com/getsentry/sentry-python/blob/ca828c9486f4a0030a744849a4e8e10c5a1c7aeb/sentry_sdk/integrations/stdlib.py#L81

as only http alone is ambiguous, I'd prefer to be more specific.

Let's fix this on Python (and what else?) and write it down on the docs?

Describe your problem

RFC 4648 defines a standard base64 encoding, and an alternate encoding that is typically used in URLs and file names.

These are the alphabets in each:

const encodeStd = "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/"
const encodeURL = "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789-_"

The spec should define clearly what set of 64 characters are expected.

The lack of padding is also part of the RFC, so could be referred to in the docs -- https://www.rfc-editor.org/rfc/rfc4648.html#section-3.2

Java does have Sentry.startSession and Sentry.endSession so if one decides to do its own instrumentation, that's possible.

https://develop.sentry.dev/sdk/sessions/#exposed-api

here the exposed API only states available thru the Hub.

Java hides getCurrentHub, it's package-private.

Cocoa has SentrySDK.currentHub() public so one could SentrySDK.currentHub().startSession() but it doesn't have SentrySDK.startSession directly on the Static API.

Is there a reason why? should we unify this?

@bruno-garcia @philipphofmann
tagging @mitsuhiko as the initial API design.

I’m getting my dev environment setup and I’m using zsh so the very first step is confusing:

My familiarity with the differences between zsh/bash are limited to say the least but I feel like I should still be able to setup my env properly. What file should I be updating here? I understand that I need to update ~/.zshrc with eval "$(pyenv init -)" but then how do I reload the command line if I’m using zsh?

We leverage different performance entries like https://developer.mozilla.org/en-US/docs/Web/API/PerformanceNavigationTiming and https://developer.mozilla.org/en-US/docs/Web/API/PerformanceResourceTiming to generate spans on a pageload transaction.

We should document what Browser APIs we use and why so that user's get a better understanding of what is being tracked. We should also cover what heuristics we use to trim idle transactions.

Not sure if this lives in docs.sentry.io, develop.sentry.io or in the SDK repo itself.

op is part of our Span spec, but we don't have a list of used ops anywhere.

In the section where we detail HTTP Client features we mention the operation http.client, but we don't further elaborate.

In addition with operations breakdown, the product now depends on op values. We should make that clear in the develop docs. We default breakdowns to use http, db, resource, and browser operations, and relay has logic for reading/using the operation name

This issue serves two purposes. First to start formalizing a list of ops that should be used by the sdks and second to track the inclusion of that list in the develop docs somewhere.

https://develop.sentry.dev/environment/#docker-mac-specific

Search for like, init-docker or devserver --workers and you won't get any hits on that page, when in fact they're there but in code blocks.

context: https://github.com/getsentry/sentry/pull/26296/files#r643399068

The new spec #407 was merged and while going through in details a few questions came up:

• We'll only add the data to the envelope item header if:
  • We're creating an envelope from a transaction
  • Or a transaction is bound to the scope (e.g: trace info exists in the scope)
• For this first iteration, we'll just add to envelope headers, no need to add to tracestate? Given we're not adding support to the backend to read it (at least in Java/.NET)?
• Or are the first use cases using Python so we should send out the tracestate so they can use it there?
• On the server side, we read some user data. Do we bind that to the scope and override whatever is there? Or what if the user code already resets user after our middleware runs. Data would just change.
• Same with DSN public key, do we propagate that downstream? The server will be using its own, so what is its use?
• Context freezing: When we're continuing a trace, that means it's frozen from the start? The scope data of that service doesn't play a role at all?
• We only need the envelope item header stuff when the content of the envelope contains a transaction?
• I assume this should be an opt-in, particularly while it's an experimental thing. What should we name the option? EnabledExperimentalTraceContextPropagation?

See #18

We should be able to do this at least for <Link> components. Surprised Gatsby wouldn't do anything by default, but I'd bet someones already solved this problem for us.

Add a new expected feature (perhaps below the HTTP client section) to describe the opt-in feature of request body:

Support for application/x-www-form-urlencoded for example in ASP.NET Core:

https://github.com/getsentry/sentry-dotnet/blob/7d008a9fc437d86d6eeff33300f2ba0160c74a9c/src/Sentry/Extensibility/FormRequestPayloadExtractor.cs#L9-L25

Options:

https://github.com/getsentry/sentry-dotnet/blob/a9304a0a4b4702d0e62e2703d55c66483d27a0e5/src/Sentry/Extensibility/RequestSize.cs#L6

https://github.com/getsentry/sentry-dotnet/blob/7d008a9fc437d86d6eeff33300f2ba0160c74a9c/src/Sentry.AspNetCore/SentryAspNetCoreOptions.cs#L23-L30

The motivation for Small, Medium was that we'd be free to redefine what they mean. For example: as we increase the max envelope size, we can make Medium a larger number.

If the user has set the TracesSampleRate to 0 to disable it and hasn't set TracesSampler to anything, then their web app may still be starting and sending transactions if it receives an incoming HTTP request with a Sentry trace header. At least that's how it works in ASP.NET Core right now. Is this a desired behavior?

Originally posted by @Tyrrrz in #264 (comment)

The documentation on breadcrumbs is missing device events like the ones which are used by Android.

See for example:

• https://github.com/getsentry/sentry-java/blob/main/sentry-android-core/src/main/java/io/sentry/android/core/PhoneStateBreadcrumbsIntegration.java#L95-L97
• https://github.com/getsentry/sentry-java/blob/main/sentry-android-core/src/main/java/io/sentry/android/core/AppComponentsBreadcrumbsIntegration.java#L75-L96

Right now sampling happens on startTransaction for Java, .NET, Python, and probably the others too.

The problem I see here is, a transaction.status could be set at a later point if an error has occurred.

I'd like to use the status to properly sample my transactions, I'd like higher sampling if there's an error.
This is not possible right now as it's being sampled or not already in the startTransaction and status might not be available, yet.

A possible solution would be to sample only on finish when the transaction should have its full payload.

cc @rhcarvalho @bruno-garcia @Tyrrrz @maciejwalkowiak @HazAT @brustolin

Hi there,
we have recently upgraded to sentry 10 and are a bit overwhelmed with the number of components that are now included with sentry. In order to better understand which service does what and to monitor it accordingly, it would be great to have some kind of overview of the architecture. This would be especially useful in regards to the various data stores/queues like kafka, rabbitmq, redis, etc.

It would be great if you could provide such an overview. In the best case, this could be a diagram of sorts, but just a written section would suffice as well probably.

Steps to Reproduce

Trigger an unknown HTTP response code (that does not match any span status code) or an exception so span either won't have a status or it'll diverge across SDKs

Expected Result

All SDKs match the default status in such cases:

an exception was thrown, maybe INTERNAL_ERROR
HTTP response code does not match any span status code, set maybe UNKNOWN? we could also make this based on HTTP code range.

eg HTTP response code is 502, we don't have such span status code, what's the default for 5xx range?
eg HTTP response code is 402, same as above, what's the default for 4xx range?

This should be aligned across SDKs for a better experience.

Actual Result

Android OkHttp sets INTERNAL_ERROR as status if there was an error or HTTP response code does not match span status code;
Java Spring sets no status at all;
.NET sets Unknown;

This change: #240 seem to have broken things.

It moved it to the sdk folder (note performance.mdx there, but not item in the menu showed up)

I added a redirect to the old URL: https://develop.sentry.dev/sdk/unified-api/tracing which returns 404 but renders the content at the bottom of the page

If a sampling decision is received by the parent transaction, should the trace sampling callback be invoked? I believe the answer is yes since this is the strategy to drop transactions generally. But we need to communicate well how customers can inspect the parent sampling decision.

@untitaker mentioned the Python SDK sets a sampling context parent_sampled key (with 0/1 as value?).
Is this the way to go and if so should we define in the spec and add this to all SDKs?

I suggest we then add a common customer facing documentation that explains how to deal with this. With code samples in each language accessing this information and using it when making the sampling decision

The docs on spans don't cover the span_id/parent_span_id/sampled fields and potentially some others. What is the list of fields required/allowed on spans?

https://develop.sentry.dev/sdk/event-payloads/span/

Source #221

We currently have this one note for User Feedback. Recently the API was added to more SDKs and to help outside contributors and new SDK developers ramp up, we need a dedicated page describing how to build this.

Relevant PRs:

• getsentry/sentry-cocoa#805
• getsentry/sentry-java#1017
• getsentry/sentry-dotnet#559

Also relevant to write API docs for is onCrashedLastRun which is relevant for Desktop and Mobile apps.

• getsentry/sentry-cocoa#808

One suggestion is to link to code blocks (through a git sha instead of /master for example) to help see different implementations.

The docs should clarify that there's an endpoint for it, brought up by @ueman below. The general gist of it is on the comment below.

Hello,
I am referring to this document

https://github.com/getsentry/develop/blob/master/src/docs/sdk/envelopes.mdx

I am experiencing an issue, and the docs don't have an example of sending a binary file to sentry via the envelope endpoint.

I am trying to upload a minidump, which is binary, and it seems to not work because of the special characters that break the envelopes header.
No amount or type of escaping helps.
I believe this to be a bug, but since the docs do not have an example of uploading a binary file I am not sure.

Even if only this is the data payload it does not go through,

miniDump = 'MDMP��a�';
{"type":"attachment","length":${miniDump.length}, "content_type":"application/octet-stream","filename":"UE4Minidump.dmp","attachment_type":"event.minidump"}

The error is
{ detail: 'invalid event envelope', causes: [ 'missing newline after header or payload' ] }
If you could provide an example of uploading binary files or note if there is an escaping mechanism, that would be truly appreciated.

If you have any questions I am open to them also

Beyond the CoC and contribution guidelines, some of our teams use a set of unwritten conventions for communicating on GitHub. Two that specifically come to mind are:

• If a pull request gets approved and receives comments/suggestions in the same review, then it is generally good to merge as-is. The comments are to be treated as optional and should be applied at the discretion of the author.
• Not all comments/suggestions are equally important. Some are mere opinions, while block approval. To do this, we sometimes use a hint like nit: or even the more elaborate LOGAF scale.

Do some of these sound useful to write down and encourage on GH?