Keith Wall comments

Results 305 comments of


                                            Keith Wall

Fix: #2113: ensure that filter handler does not leak opaque requests/responses if the upstream or downstream side closes

I'm not proposing to chase the additional coverage in this PR. Those were already uncovered paths.

Metrics for upstream/downstream network error conditions

I'm thinking about things like: 1. Upstream errors (uncontactable host, network timeout, TLS negotiation errors, Protocol errors) 2. Downstream errors (TLS negotiation errors, Protocol errors (i.e. HTTP))

Metrics for upstream/downstream network error conditions

@SamBarker it is not clear what remains to be done. could you update the state of this issue?

Netty Leak Detection firing sometimes on CI

I notice that in the case above, the issue is occuring after the ResilienceIT has run. I added `shouldTolerateUpstreamGoingOffline` so I wonder if that might be exposing the issue?

Netty Leak Detection firing sometimes on CI

I haven't been able to reproduce this issue locally. We are not seeing this issue regularly on CI either either. I think turning up `io.netty.leakDetection.targetRecords` would be a good idea...

Netty Leak Detection firing sometimes on CI

@SamBarker I'm not actually confident that the #2114 will resolve the issue. I couldn't make the story fit together. But let's see!

Fix #1831 - adding support for downstream trust

@robobario @SamBarker hoping this PR is now in good shape.

Fix #1831 - adding support for downstream trust

@SamBarker @robobario if I can add this to your review queue that'd be great.

Fix #1831 - adding support for downstream trust

> In testing I was surprised that setting up downstream trust didn't stop the client connecting without a certificate. It looks like by default if we don't supply a `clientAuth`...

Document the API between the core and website repository

Agreed this is something that we want.