I’m trying to file a flaky test issue for failing ...
# general
h
I’m trying to file a flaky test issue for failing contrib shard, but am unclear what test is actually failing. Someone mind helping me to parse the logs? https://api.travis-ci.org/v3/job/467047088/log.txt
Maybe it’s this line:
contrib/avro/tests/java/org/pantsbuild/contrib/avro:avro[
? That’s the most recent Pants line I see before stderr and stack trace
a
Looks like it was a network connectivity issue downloading the errorprone jar from maven?
r
You can Ctrl-F for
:: problems summary ::
👌 1
It failed to fetch a jar
h
Okay that’s helpful. Thank you both! And it looks like it failed to fetch the JAR during the
contrib/avro/tests/java/org/pantsbuild/contrib/avro:avro
tests, right?
Do we open
flaky-test
issues for networking problems?
r
Please do! It’s great to have them documented 🙂
👌 1
e
I'm not sure I agree with that! There is flaky expected - which is any test that uses network, and there is flaky unexpected - we wrote a bad test or are using non-deterministic data structures. The former are probably never going away, the latter we should always be able to squash.
So from a label perspective, it seems to me network flakes just add noise to cleanup efforts. I advocate for a separate label or just not doing this.
👍 1
h
@enough-analyst-54434 thoughts on a new tag
expected-flaky
? I’d be happy to make right now!
a
what are your thoughts on adding retries to particularly flaky network requests?
👍 1
e
I don't believe there is such a thing as particularly flaky network requests. I would guess maven central, pypi and cargo central are all about as stable.
a
there was that go download with the meta import tag that kept flaking? i need to page back into that
h
I like retries. Could increase the number of timeouts we get, but better that than flaky imo. Either way, I like the idea of still somehow cataloging in GitHub issues so that when you’re debugging the failure you don’t have to reproduce the effort some already put in to seeing if the failure is a flake
👍 1
a
in that case the answer might be to change what we are making requests for
e
Let me put it this way. Over the last few days I've fought flakes with a vengeance and the incidence of network to our bugs was maybe 1/10
I think our buggy tests are a much bigger problem
👍 3
a
ok, that makes sense
i would feel more comfortable with a separate tag with much less priority? and tickets would only be made if there is relevant background or investigation, or an idea on how to fix them? i do 100% agree the buggy tests are the focus and this might help me to focus on that -- but i'm not wedded to the thought
e
I'm fine with a separate tag.
👍 1
h
Okay, I’m thinking either a label
acceptable-flaky-test
or
expected-flaky-test
a
ci-network-failure
or
low-priority-flaky-test
?
e
network-flaky
👍 2
a
@hundreds-father-404 are you planning to make an issue with that tag for the above issue? a description on that tag that says it's lower priority might be helpful, not sure how github surfaces those descriptions in the ui
h
Yes, making the label right now this is what I have for description:
Copy code
Flaky test resulting from network issues, implying the flake does not result from a bug in our code
❤️ 1
a
thanks!
❤️ 1
e
Thanks folks
💯 2
a
thanks for being the adult in the room and acknowledging the flakiness needs to be addressed! this increases my sanity tenfold
❤️ 1
h
I’ll update the email thread to loop everyone in on this
👌 1
a
we can update that label in the future when the sun begins to degrade and we have to guard against cosmic rays (pants will be around until then along with my brain in a jar (file))
😂 1
👌 1