Fixing timeouts about codecov-action HOT 30 CLOSED

Hi all,

We identified a bug within Minio that seems to be causing these timeouts to occur. Our engineers have already merged a PR to fix this, and in the process, some other issues have sprung up which we've also PRed into the Minio repo. We're working hard to get those other fixes merged and a new version of Minio deployed with our infra as soon as possible, so I apologize for the delay in addressing this.

Ib

from codecov-action.

Hi @tillkruss, thank you for bringing this up! We're investigating this internally - it seems to be a server-side issue which is impacting users with a large number of report uploads. Will post an update here when we've diagnosed and fixed this fully

from codecov-action.

I'm still running into this issue as well: https://pipelines.actions.githubusercontent.com/WMazgylCfCu4ko1Ltxzy3Jxgf9FHIkKNNu6qjxJ2D1DT9WzVqF/_apis/pipelines/1/runs/118/signedlogcontent/28?urlExpires=2020-06-22T05%3A07%3A00.2620951Z&urlSigningMethod=HMACV1&urlSignature=FQBl0NtgxYMJRYkVf3%2Br9xEedvqiW7HjTHXsOWcRmVI%3D

from codecov-action.

Same issue just hit us today - any progress?

from codecov-action.

We're still having this issue crop up frequently (though irregularly) for coreutils MacOS test uploads (see https://github.com/rivy/rs.coreutils/runs/725847137?check_suite_focus=true and https://github.com/uutils/coreutils/runs/769224500?check_suite_focus=true).

I posted a similar note on the community board.

Where would you prefer to discuss it?

from codecov-action.

@thomasrockhu: Was the original issue resolved? How are cookies related to the CI timeouts?

Also the community boards link you posted isn't working.

from codecov-action.

I'm going to close out this issue, because many of the comments are due to different issues.

However, it doesn't solve the issue. We're still having this issue from time to time.

from codecov-action.

Switch to 1.0.10

from codecov-action.

This seems to now be fixed in my GHA builds (no config changes; still using codecov/codecov-action@v1).

from codecov-action.

Great.

We have a single workflow, but 16 runs with different configurations.

from codecov-action.

Same issue here, stacktrace:

/home/runner/work/_actions/codecov/codecov-action/v1/dist/index.js:292
      throw error;
      ^

Error: connect ETIMEDOUT 35.199.43.247:443
    at TCPConnectWrap.afterConnect [as oncomplete] (net.js:1054:14) {
  errno: 'ETIMEDOUT',
  code: 'ETIMEDOUT',
  syscall: 'connect',
  address: '35.199.43.247',
  port: 443
}

from codecov-action.

I have the exact same problem in pyatv. Really annoying to have to restart all the time.

from codecov-action.

Same issue happening to me.

from codecov-action.

And for us...

Run codecov/codecov-action@v1
/home/runner/work/_actions/codecov/codecov-action/v1/dist/index.js:292
      throw error;
      ^

Error: connect ETIMEDOUT 35.199.43.247:443
    at TCPConnectWrap.afterConnect [as oncomplete] (net.js:1129:14) {
  errno: 'ETIMEDOUT',
  code: 'ETIMEDOUT',
  syscall: 'connect',
  address: '35.199.43.247',
  port: 443
}

from codecov-action.

@ibrahim0814: Any update on the deployment?

from codecov-action.

We're hitting this issue intermittently for coreutils MacOS test uploads (see https://github.com/rivy/rs.coreutils/runs/725847137?check_suite_focus=true).

Was the fix mentioned here merged?

from codecov-action.

As another data point, also seeing intermittent failures:

from codecov-action.

Has the problem gotten worse lately? I'm barely able to merge things because of problems with codecov.

from codecov-action.

Almost every pr failed. 😔

from codecov-action.

Not working here either.

Codecov warning: connect ETIMEDOUT x.x.x.x:443

from codecov-action.

Hi everyone, we recently encountered an incident over the past few days that is the most likely root cause for the recent uptick in timeouts. We have since resolved that issue. Please let me know if continue to experience this, or leave a post on our community boards

from codecov-action.

I'm going to close out this issue, because many of the comments are due to different issues.

from codecov-action.

Fair enough. It is a little bit easier for us to track this on the community boards. @JekaMas @tillkruss has this happened to you recently after the fix? If so, if you can provide commit SHAs or the Codecov output, that would be extremely helpful.

Again, preference is towards the boards, but I understand if this fits better into your workflows.

from codecov-action.

FWIW I'm also seeing this on GitHub Actions: https://github.com/qutebrowser/qutebrowser/runs/834775872?check_suite_focus=true#step:10:1

from codecov-action.

@mmoayyed Hmm, shouldn't v1 always point at the newest v1 (i.e. v1.0.10) rather than v1.0.0?

from codecov-action.

@The-Compiler, it should have, but 1.0.10 was released on the same day. It could have just been an issue with timing, but hopefully this should be resolved for you. I'm going to close out this issue now, but if it crops up, please feel free to make a support post on our community boards.

from codecov-action.

I am still seeing this issue regularly - see this build from a few hours ago.

from codecov-action.

FYI @thomasrockhu your link to the community boards should be to https://community.codecov.io but it takes me to https://github.com/codecov/codecov-action/issues/community.codecov.io which is a 404.

from codecov-action.

Whoops! thanks @adamtheturtle

from codecov-action.

This just happened again, on 1.0.12, after 11 minutes.

from codecov-action.