Skip to content
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

Fix intermittently failing ChunkedDownloadSpec #256

Merged

Conversation

mikkokar
Copy link
Contributor

Fixes an intermittently failing end-to-end test.

Root cause: Failing assertion was based on origin metrics. However the origin was shared with two other tests which influenced the asserted metric values.

The fix is to add a new backend service that is only used in the failing test, preventing other tests to influence the origin metrics, thus affecting the assertions.

@mikkokar mikkokar requested review from kvosper, dvlato and VivianLopes and removed request for kvosper August 30, 2018 15:31
pom.xml Outdated
@@ -92,7 +92,7 @@
<netty-tcnative.classifier>linux-x86_64</netty-tcnative.classifier>

<!-- General Versions -->
<guava.version>16.0.1</guava.version>
<guava.version>18.0</guava.version>
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should this change be included in this PR?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nope

@@ -44,12 +46,14 @@ class ChunkedDownloadSpec extends FunSpec
with TestClientSupport
with Eventually {

val (originOne, originOneServer) = originAndCustomResponseWebServer("NettyOrigin")
val (originOne, originOneServer) = originAndCustomResponseWebServer("NettyOrigin-01")
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The solution is fine but I would expect that we just create the origin in each test / setup method if they can't be reused?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It is the styx server that would have to be created in each test/setup cycle.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's also possible, but I was just thinking of limiting the scope of the origins ( they can be created with ,e.g., a random name in each test). But since , as you say, there's only one Styx instance it makes sense to set all of them up in the fixture.

…ateway read timeout."

test by adding a separate origin whose metrics are not influenced by the
preceding two tests.
@mikkokar mikkokar force-pushed the fix-failing-ChunkedDownloadSpec branch from b7430e0 to e73c1fb Compare August 30, 2018 15:43
@mikkokar mikkokar merged commit 8bed0dc into ExpediaGroup:styx-1.0-dev Aug 31, 2018
@mikkokar mikkokar deleted the fix-failing-ChunkedDownloadSpec branch August 31, 2018 08:14
mikkokar added a commit to mikkokar/styx that referenced this pull request Oct 3, 2018
Fix "Proxies long lasting HTTP Chunked downloads without triggering gateway read timeout."
test by adding a separate origin whose metrics are not influenced by the
preceding two tests.

(cherry picked from commit 8bed0dc)
mikkokar added a commit that referenced this pull request Oct 3, 2018
Fix "Proxies long lasting HTTP Chunked downloads without triggering gateway read timeout."
test by adding a separate origin whose metrics are not influenced by the
preceding two tests.

(cherry picked from commit 8bed0dc)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants