-
Notifications
You must be signed in to change notification settings - Fork 357
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
CLI seems to use only synchronous deploys even for sites that are over the "syncfileslimit" and this can lead to upload failures #745
Comments
This has affected at least one enterprise and two pro customers, plus some folks in community:
|
Thanks for reporting this @fool. It's in the backlog we'll take a look at this soon. |
@ingride Can you please elaborate on the |
Seems like partially blocked on https://github.com/netlify/bitballoon/issues/5624 |
@RaeesBhatti - is #5624 supposed to be publicly viewable? If so, it might be a broken link (or it is for me at a minimum :)). Thanks! |
@stephencweiss That is an internal issue with out API engine. Please hold on this problem is on our priority list. |
@RaeesBhatti No problem! As I noted in a related ticket -- I've got a workaround by setting a longer timeout... #484 (comment) |
Is there any update to this issue? It seems the switching the timeout doesn't always work as a workaround |
Hi @RaeesBhatti I've seen that you have a PR up to address this issue. This keeps being a massive pain for us since our builds have become super flaky, timing out 50% of the time. Do you have an ETA when that PR might be merged to resolve this issue? |
@tbgse The primary blocker in way of fixing this issue is that I haven't been able to reproduce it yet. I've tested the solution in the PR above with 20k unique files of 10kb each. And the deployment happened without any issue. |
It has recently come to light that the requests are actually failing with |
Hi @RaeesBhatti what is the solution or the follow up after the closing of this issue? |
@kalinchernev Please update to |
Ok, thanks, i have upgraded and will monitor behavior |
@RaeesBhatti do you know if the I ask because we're seeing this error too using actions-netlify which uses the |
Not sure @dwilt ! If you're still seeing the problem with js-client, could you file an issue over there (https://github.com/netlify/js-client/issues/new)? I would think it wasn't having the problem since I believe that's what we use internally and we haven't run into it, but I could be wrong, so if you are seeing it still let's get that issue filed so the team can debug. |
We're continuing to have issues with the
It's been EDIT: Looks like the async change was already implemented in |
Re-opening this issue as there are still reports of this issue surfacing also in #484 (comment) |
Closing as stale. Please re-open if needed |
- Do you want to request a feature or report a bug?
bug
- What is the current behavior?
currently, the CLI always attempts to deploy synchronously, which even for sites with only a few thousand files, can lead to 502 gateway errors during upload, and this causes deploys to fail.
- If the current behavior is a bug, please provide the steps to reproduce.
Try to deploy a site with 10k new files via CLI. It may occasionally work, but often will not. This has been reproduced with sites as small as 4500 files and as big as 60k files. This happens even with high
-p X
values to set a large timeout.The setting that was proposed to change that controls this:
https://github.com/netlify/js-client/blob/master/src/deploy/index.js#L25
does not seem to support being changed (or changes are ignored) as we've tried setting it to smaller numbers including 1 with the behavior not changing according to our internal logs AFAICT.
- What is the expected behavior?
Deployment works and is handled asynchronously on our servers to allow success no matter how large the site.
- Local Environment Information
Happens with v2.37.0 on linux
** Additional netlify-private context**
There was a long thread discussing this here in slack: https://netlify.slack.com/archives/C0QFKKY2U/p1582742724079200 . See especially comments from @rybit and @biilmann that we should consider having the CLI use "always async"
The text was updated successfully, but these errors were encountered: