Not registering the Transaction name for OPTION requests

[lucas-zimerman]

Package

Sentry.AspNetCore

.NET Flavor

.NET Core

.NET Version

3.1.27

OS

Linux

SDK Version

3.11.1

Self-Hosted Sentry Version

No response

Steps to Reproduce

I noticed on a project that I monitor that all OPTION requests have unknown transaction names, other types of requests have the transaction name, I didn't stop to check the internal code to see what's going on but decided to register before I forget that happened.

Expected Result

A formatted transaction name.

Actual Result

[mattjohnsonpint]

Any chance we could get a minimal repro? Thanks.

[SimonCropp]

@lucas-zimerman the repro could perhaps use a similar approach to https://github.com/getsentry/sentry-dotnet/blob/main/test/Sentry.AspNetCore.Tests/VersioningTests.cs#L22

[lucas-zimerman]

@mattjohnsonpint @SimonCropp

EDIT 2: I could not repro it, but I'll keep investigating it

EDIT 3: It may be related to users calling an endpoint with the wrong Method (GET ...path, where path only accepts POST), in this case it defaults the method to OPTIONS. Now what I really dont know is why the status code I saw was ok 🤣

OldMessage.

I was only able to repro it within .NET Core 3.1 (Only tested on .NET 6 and .NET Core 3.1).

![image](https://user-images.githubusercontent.com/8229322/184058417-585b1af5-bf7b-4d2d-902e-d1143f9f659f.png)

It seems flaky as I shown on the picture, at some runs it stores the transaction name, but there is other times where it gives a Unknown Route as a path, it also seems to only be happening on the Option Route.


Sample: https://github.com/getsentry/sentry-dotnet/tree/sample/option-tracing-issue

I amrunning the following test 
sentry-dotnet\test\Sentry.AspNetCore.Tests\VersioningTests.cs -> SimpleOptionRoute

I didn't validate if Verify is working or not, all I did was add a breakpoint to check the payload content on line 132.

EDIT: Oh there's a weird behavior, despite setting the test runner to run in .NET Core 3.1, it was running on .NET 6 for the first run and the later ones were running on .NET Core 3.1

[lucas-zimerman]

Ok so the issue seems related to how the Request is being received:

curl \
 -X OPTIONS \
 --compressed \
 -H "Accept: */*" \
 -H "Accept-Encoding: gzip" \
 -H "Accept-Language: pt-BR,pt;q=0.9,en-US;q=0.8,en;q=0.7, en-AL;q=0.1" \
 -H "Access-Control-Request-Headers: authorization,content-type" \
 -H "Access-Control-Request-Method: GET" \
 -H "Cdn-Loop: cloudflare" \
 -H "Cf-Connecting-Ip: 🟨🟨🟨" \
 -H "Cf-Ipcountry: BR" \
 -H "Cf-Ray: 🟨🟨🟨" \
 -H "Cf-Visitor: {\"scheme\":\"https\"}" \
 -H "Host: 🟨🟨🟨" \
 -H "Origin: 🟨🟨🟨" \
 -H "Referer: 🟨🟨🟨/" \
 -H "Sec-Fetch-Dest: empty" \
 -H "Sec-Fetch-Mode: cors" \
 -H "Sec-Fetch-Site: same-site" \
 -H "User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/103.0.5060.114 Safari/537.36 OPR/89.0.4447.64 AtContent/92.5.3164.65" \
 -H "X-Forwarded-For: 🟨🟨🟨" \
 -H "X-Forwarded-Host: 🟨🟨🟨" \
 -H "X-Forwarded-Port: 443" \
 -H "X-Forwarded-Proto: https" \
 -H "X-Forwarded-Server: traefik-ingress-controller-nktzn" \
 -H "X-Real-Ip: 🟨🟨🟨" \
 "http://🟨🟨🟨"

The issue seems related to the parameter -X OPTIONS , Not entirely sure what's the goal of it, but it surely messes up with the Request. Requests without this field seems to be working just fine.

[SimonCropp]

@lucas-zimerman can u share your controller code?

[SimonCropp]

@lucas-zimerman i put s=together what i think should be a repro: https://github.com/getsentry/sentry-dotnet/pull/1859/files

and TheTransaction does show up in the payload. is my repro incorrect?

[lucas-zimerman]

@SimonCropp sorry for the confusion, after further investigation on this issue, it seems related to this: https://github.com/axios/axios/issues/475#issuecomment-253212139

Basically the client sends two requests one with the Method OPTIONS to see if it's able to perform the request and then the desired request with the correct method and data.

Maybe we should ignore Pre-flighted requests to not cause confusion?

[lucas-zimerman]

• The pre-flight request and the request transactions as example.

• Header sample from a Pre-flight request:

-H "Access-Control-Request-Headers: authorization" 
-H "Access-Control-Request-Method: POST" 

[SimonCropp]

@lucas-zimerman

Maybe we should ignore Pre-flighted requests to not cause confusion?

i would still like to be able to repro, and debug into it, before we make that call. with that in mind can u help modify https://github.com/getsentry/sentry-dotnet/pull/1859/files to replicate the problem

[lucas-zimerman]

@SimonCropp sample test created: https://github.com/getsentry/sentry-dotnet/pull/1874

[bruno-garcia]

We agreed to avoid sending transactions for HTTP OPTIONS