Coverage failed to send but travis succeeded? about dart-coveralls

[eseidelGoogle]

Looks like the last successful coverage report was from Feb 20th:
https://coveralls.io/builds/10291701

The the job I reported on above was from Today (March 1st).

[nilsdoehring]

You mean by providing --throw-on-error, or --throw-on-connectivity-error option? I can't remember having tested those explicitly, so I'll do that and will change travis.sh, accordingly.

At least, our side seems to work fine, as the last successful coverage is from Feb 23, after I had merged PR #64. Merges and commits before that are also there.

[eseidelGoogle]

Seems like it's worth fixing travis-coveralls-submission to be known-to-work for our repo here before publishing. Just to sanity check that the current code is working in at least one config. :)

[eseidelGoogle]

I was able to reproduce the "Bad Gateway" error locally, and then it succeeded on retry (I also have seen it fail multiple times in a row).

We currently don't have any back-off logic in the retries which may be related. We also might be tickling the coveralls endpoint in a bad way.

For example, just now:

Sending coverage information. JSON length: 35537
Coverage information sent.
Error sending
Exception: Bad Gateway
Retrying 1 of 2.
Sending coverage information. JSON length: 35537
Coverage information sent.
200 OK
Response:
{"message":"Job #2.1","url":"https://coveralls.io/jobs/23426545"}
Coveralls Job #2.1 – https://coveralls.io/jobs/23426545

[eseidelGoogle]

It's possible that our usage of the API is dated and influencing the bad gateways?
#70

[nilsdoehring]

When testing almost all config combinations of the report command with several of my repos, I only encountered a failed upload once, and attributed it to the internet being the internet :-) Thanks for looking into it!