-
Notifications
You must be signed in to change notification settings - Fork 775
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Validate OTLP exporter continues to export after RpcException #3788
Validate OTLP exporter continues to export after RpcException #3788
Conversation
Codecov Report
Additional details and impacted files@@ Coverage Diff @@
## main #3788 +/- ##
=======================================
Coverage 87.41% 87.41%
=======================================
Files 280 280
Lines 10755 10755
=======================================
+ Hits 9401 9402 +1
+ Misses 1354 1353 -1
|
@alanwest do we plant to merge this, and build on more tests based on this foundation? The existing integration tests (which uses a real collector) should be sufficient for most cases, we need to add more, only if it has shortcomings, that can be covered here... |
Yes, I think this will provide a good foundation for testing retry #1779. We need a "bad acting" collector - one that can return error status codes. I'd like to implement retry soon. |
It's run via docker-compose, but could have been done using the in-process ASP.NET Core test framework. However, my hope is that we can expand on this to also test .NET Framework. The existing test server runs in both .NET FW and .NET. (its a separate issue to check why we did not leverage asp.net core for .NET tests!) |
This is something I looked into in the past when I implemented the original integration test with the real collector. That is, my first choice was to try to avoid using docker. However, as I recall, HttpListener has limitations with regards to HTTP2 and gRPC. I'm trying to dig up my findings from the past, but no luck yet... I'd be happy to dig in again and retrace my steps. |
Got it, if this is specifically to cover .NET FW apps. Else we can use Asp.Net Core host, which can cover gRPC/Http2. |
Correct. the ideal non-docker solution would use ASP.NET Core host for .NET and something like HttpListner for .NET Framework. I refreshed my memory a bit on HttpListener. On Windows, HttpListener relies on Http.Sys. Http.Sys does support Http/2 on recent versions of Windows. It requires https which creates a bit of a headache for generating test certs for the CI. But the real blocker is that HttpListener provides no way to set trailing metadata and a gRPC status code. Perhaps we just punt on concerning ourselves with testing .NET Framework. |
This would be an option as well... |
That's fair. I'll rework things to just test .NET using the in-process host. |
@cijothomas decided to just merge it? Good by me, though I was going to un-dockerize it. |
Sorry I was thinking and my mouse clicked merge.. (have a new feature enable to auto-click...sometimes causes things like this) |
No worries! I'll open a separate PR with the changes. |
Attempt to reproduce #3740.
This PR introduces a mock OpenTelemetry collector that can mimic failed requests. It's run via docker-compose, but could have been done using the in-process ASP.NET Core test framework. However, my hope is that we can expand on this to also test .NET Framework.
The test configures the mock collector to first respond with an
Unimplemented
status code followed by anOK
on the subsequent request.