Improve tracing of HTTP/2 PINGs #57747
Conversation
|
Tagging subscribers to this area: @dotnet/ncl Issue Details#57617 can be a worrying reliability issue. In case there will be other reports, it is very important to have the ability to collect traces that can help hunting down a potential bug in HttpClient or Kestrel. Currently we are not logging received PING content at all, which prevents investigation based on customer data. This is a minimal-risk (log only) addition to #54755, which I believe we should backport to 6.0 (including RC2, and maybe RC1 if it can meet the bar). Contributes to #57617.
|
|
@antonfirsov for 6.0 backport, can we somehow easily check that when the logging is enabled, nothing bad happens and/or that we get what we need? (e.g. with induced error) |
|
CI failures: System.Threading.Tasks.Tests - known problem #57331, re-running tests |
|
I pushed a test improvement to make sure both failure cases ( Did a local run of all flow control tests having an EventListener attached, and everything worked as expected. |
|
/azp run runtime-libraries-coreclr outerloop |
|
Azure Pipelines successfully started running 1 pipeline(s). |
|
/backport to release/6.0 |
|
Started backporting to release/6.0: https://github.com/dotnet/runtime/actions/runs/1158715829 |
|
/backport to release/6.0-rc1 |
|
Started backporting to release/6.0-rc1: https://github.com/dotnet/runtime/actions/runs/1161483669 |
ghost
locked as resolved and limited conversation to collaborators
4 participants
#57617 can be a worrying reliability issue. In case there will be other reports, it is very important to have the ability to collect traces that can help hunting down a potential bug in HttpClient or Kestrel. Currently we are not logging received PING content at all, which prevents investigation based on customer data.
This is a minimal-risk (log only) addition to #54755, which I believe we should backport to 6.0 (including RC2, and maybe RC1 if it meets the bar).
Contributes to #57617.