building failed sometimes with Can't find stylesheet to import #27167
Comments
|
This appears to be a package manager related issue. The Angular CLI does not control the layout or content of installed packages. Does the issue occur if another package manager is used? |
We never tried I want to add we upgrade from yarn 1.x to 4.0.2, and the issue still exists |
|
@clydin Could you elaborate on how this is a package manager issue? |
|
hi @clydin this is my build script, it fails now then on retry 1 or 2 times it passes |
|
Unfortunately without a reproduction it's hard to debug and understand what is the problem here. |
|
how can I reproduce it if it happens 5% of the times? |
|
The same problem sometimes occurs in my GitLab pipeline, approximately 1% of the time. |
|
We have the same problem. Same as #25018 and #26389. We are also getting this issue here:
We've tried both to point This never happens in local, only in CI. It seems that the problem might be related to the typography partials? I saw some suggesting to make a local copy of whatever typography function you need in your styles, but I feel it's highly impractical, both for the daisy-chain effect of functions you would have to copy, and also in terms of maintainability. |
|
We have the same problem.
each time it fails on different stylesheet. Angular version is 18.0.2 |
|
I encountered same error while building my Angular application. Any fix for that? |
|
Same here. I was hoping the issue would be fixed with Angular 17 but it's still there. Not on every single build, though. It's quite flaky as some have already said. I'm quite disappointed that this issue does not seem to get any attention at all ... |
|
Unfortunately, there's not much we can investigate without a reproducible example, making it difficult to determine the cause of the issue. It's also worth noting that in our end-to-end tests, which cover various scenarios and utilize both NPM and Yarn as package managers, we have not encountered this error. Does this also happen when not using NX but using the @angular/cli directly? |
My team has been seeing this same issue, using just the angular/cli directly. Like everyone else has mentioned, it only happens in CI, never locally. One observation is could this be based on the CI platform? Someone called out Gitlab and the screenshot in the original issue looks like it is from Azure DevOps. |
|
@tanner-wisniewski we're seeing it on GitHub Actions. So seems to happen across the board. |
|
I use the @angular/cli directly, too. |
|
I think it's related to the technical parameters of the builder, in azure it's 2 core + 7 GB ram and 14 GB disk |
@alan-agius4 |
|
Just in case this helps anyone else, we have been encountering the same issue in the same manner: only in our CI builds in AWS and never when building locally (mostly macOS ARM dev envs outside of containers). Yesterday, we had a bit of a breakthrough, and we were finally able to reproduce the failure in a local Docker container, albeit only intermittently. We just completed a batch run of local builds to compare 4 different Docker Node images: node:18.20.3-alpine3.19, node:20.14.0-alpine3.19, node:18.20.3-slim, node:20.14.0-slim. With 20 runs of each of the 4 images, the results were 5 total failures: 4 in Node 20 Alpine, 1 in Node 18 Alpine, and 0 in either Slim image. Our codebase, which contains ~500 components, and a roughly similar # of scss files, was constant across all builds. Only difference between the builds was the base docker image version. We have changed our CI builds from using alpine to slim, and so far, the results are looking much better. We don't have any hypothesis yet as to why an alpine image would lead to this issue, or why it would only do so intermittently, but at this point, we have enough data to want to avoid them in our environment. |
|
Hi @bmarcotte can you share this setup? |
@robertIsaac I would only be able to share the docker files & and small bash script that invokes them. Everything else is proprietary code that couldn't be shared as is. Which I think really gets at the impasse we're at with investigating this. If this problem is more likely to occur in large codebases, but most of our codebases are proprietary, then most of the people reporting the issue are not going to be able to submit a reproducible example, like the Angular team keeps asking for. So, if anyone happens to know of a large, open source application written in Angular, maybe we could use that as a reference platform for testing issues like this? |
that's what I meant
what about Angular material? |
We use github actions and tried to run build as
|
|
While poking around the Material repo yesterday, I ran across a ticket, angular/components#26603, from over a year ago, describing very similar errors. There's a comment from a user named @Carniatto, who posted a link to a repo he created to reproduce this issue. I made a fork of that repo, and added on some of the script and Docker pieces that I mentioned here previously. I ran 100 batches of 2 builds each (two different Node versions), and saw 11 failures total. Although that's not as high of a failure rate as we've seen we our larger proprietary code builds, at least we now have a publicly accessible repo that can reproduce the issue: https://github.com/bmarcotte/sass-import-issue-repro Is this enough for the Angular team to start investigating the issue, @alan-agius4? |
Thanks for the mention For us, the resolution was taking so long that we actually worked around this issue. We decided to make all our theming hardcores CSS variables. This is not ideal since you cannot grab colors from the theme defined on Angular Material, but we needed to move on. |
We tried this and switched to 22-slim - and so far it really looks much better - many thanks for sharing @bmarcotte! |
|
Thanks for the reproduction, @bmarcotte and @Carniatto. I ran the test four times with 20, 50, 100, and 200 builds, respectively. Out of a total of 370 builds, there were no failed builds. While I can't completely rule out a bug in the Angular CLI, it's highly unlikely. Additionally, this issue seems to occur only with Docker, which the CLI doesn't have any special logic for. Module resolution relies on the location and availability of files in the system. If the file structure, availability, and access on disk remain consistent, so should the resolution across different builds. The intermittent nature of the problem suggests it's not an Angular CLI bug, as the same code path is used for all builds. Builds are hermetic, and the same input should consistently produce the same output. |
|
@alan-agius4 Do you happen to know how many CPUs your Docker environment is configured to use? Most of my previous testing was done with a limit of 4 cpus. In some further testing today, I noticed that if I set that lower, to 1 or 2 cpus, the error rate increased significantly (sometimes over 50%), and if I set it higher to 8, the failures basically disappeared. Note that I only saw that difference when changing it via Resource Allocation > CPU limit in the Settings tab of Docker Desktop (for Mac), which I think sets a limit for the entire Docker engine. Setting a cpu resource limit per container, via docker-compose.yaml (i.e. deploy.resources.limits.cpus=xxx) did not seem to have an effect (other than run time of the build). If that observation is also seen by others, perhaps sass-loader, or something else in the sass toolchain, is hitting a timeout threshold under high CPU usage that it doesn't encounter when spread out over more cores? |
|
my observation over the past week is that now it never fail on build |
|
I wonder if this issue is caused by Vite dependency optimization and caching, which are disabled by default in CI environments. Can you confirm whether your CI environment is setting a |
|
I set the variable incorrectly in the yml file for the test |
|
Hello @alan-agius4 I don't know if it's the same issue, but I'm getting the same problem with nx. I've made a ticket on nx with a reproduction, maybe this could help for the investigation. |
|
we have set the environment variable |
|
I've been experiencing this issue for a while now. Recently with the Angular 18 update it seems to be occurring more often.
Here's some info about my project:
I tried the following without success:
Reading this thread and trying your suggestions,
This seems to have improved the reliability (no failure since I added that). |
|
We're using Azure and have an NX Angular 17 monorepo with 11 apps, but we are building only one single app at a time. We also have around 25 libs built together with that app. We used to have intermittent failures like this, but using @alan-agius4 thanks for your investigation and solutions! 🤗 Also, there's something unclear to me: setting |
yes |
|
Great that the issue seems to be fixed in the latest build. Here it says that "the changes were merged into the following branches: main, 18.0.x, 18.1.x". What about Angular 17? Is the fix included right there or not? Do I have to update to Angular 18 in order to get the fix? |
|
@MelanieW97, no version 17 is in LTS as such it only receives security fixes. See https://angular.dev/reference/releases#lts-fixes for more information. In earlier versions setting the above mentioned environment variable is required. |
|
Is #27969 really a fix for the root cause? It sounds more like a way to decrease the likelihood of the problem without special configuration. This is still good, but what do we know about the root cause so far? |
That's exactly what I thought before @alan-agius4 clarified it's a fix. Thanks for asking. :) |
|
It is an improvement to detect the maximum number of workers that can be used within containers instead of using This failure commonly occurred when the container lacked sufficient resources to manage the builds, particularly when using parallel builds. |
If the root cause is insufficient resources, is there a way to detect this and improve the error message? 🤔 |
I guess because nobody reported that they managed to reproduce it on a local computer (usually with decent resources) it's good enough to consider it a lack of resources issue. Everybody reported that it only happens on CIs. |
Still does not answer @ptandler`s point if it is possible to detect if there is insufficient resources and give a proper warning/error. |
@sergiubologa no idea if it's the same issue, but I can reproduce such problem on local:
|
|
@alan-agius4 |
|
@robertIsaac, glad to hear that. No, there shouldn’t be need. |
|
I upgraded an application to 18.1 because of this, and it's happening much less frequently, but I've just encountered a failed pipeline. package.json: "dependencies": {
"@angular/animations": "18.1.1",
"@angular/cdk": "18.1.1",
"@angular/common": "18.1.1",
"@angular/compiler": "18.1.1",
"@angular/core": "18.1.1",
"@angular/forms": "18.1.1",
"@angular/material": "18.1.1",
"@angular/material-luxon-adapter": "18.1.1",
"@angular/platform-browser": "18.1.1",
"@angular/platform-browser-dynamic": "18.1.1",
"@angular/router": "18.1.1",
"@azure/msal-angular": "3.0.22",
"@azure/msal-browser": "3.19.1",
"@ngx-translate/core": "15.0.0",
"rxjs": "7.8.1",
"tslib": "2.6.3",
"zone.js": "0.14.8"
<... REMOVED A FEW THAT IS NOT RELEVANT TO THIS...>
},
"devDependencies": {
"@angular-eslint/builder": "18.1.0",
"@angular-eslint/eslint-plugin": "18.1.0",
"@angular-eslint/eslint-plugin-template": "18.1.0",
"@angular-eslint/schematics": "18.1.0",
"@angular-eslint/template-parser": "18.1.0",
"@angular/build": "18.1.1",
"@angular/cli": "18.1.1",
"@angular/compiler-cli": "18.1.1",
"@typescript-eslint/parser": "7.16.1",
"eslint": "9.7.0",
"typescript": "5.5.3"
<... REMOVED A FEW THAT IS NOT RELEVANT TO THIS...>
}I'm buliding it in a docker container after restoring with pnpm: FROM node:20-alpine AS web-app-restore
COPY ./[REDACTED] ./app
WORKDIR /app
ENV PNPM_HOME="/pnpm"
ENV PATH="$PNPM_HOME:$PATH"
RUN corepack enable
RUN --mount=type=cache,id=pnpm,target=/pnpm/store pnpm install --prod --frozen-lockfile
RUN --mount=type=cache,id=pnpm,target=/pnpm/store pnpm install --frozen-lockfile
RUN node node_modules/@angular/cli/bin/ng build |
|
Starting with version 18.1.2, |
|
This issue has been automatically locked due to inactivity. Read more about our automatic conversation locking policy. This action has been performed automatically by a bot. |
On slow systems, a race condition can lead to the sass worker thread being notified to wake up before a message is posted. This causes the build to be aborted because the searched file is not found. Waiting twice for a non-zero number in the signal handles this race correctly, and the second wait should be a noop in the usual case. Fixes angular#27167
On slow systems, a race condition can lead to the sass worker thread being notified to wake up before a message is posted. This causes the build to be aborted because the searched file is not found. Waiting twice for a non-zero number in the signal handles this race correctly, and the second wait should be a noop in the usual case. Fixes angular#27167
On slow systems, a race condition can lead to the sass worker thread being notified to wake up before a message is posted. This causes the build to be aborted because the searched file is not found. Waiting twice for a non-zero number in the signal handles this race correctly, and the second wait should be a noop in the usual case. Fixes #27167
On slow systems, a race condition can lead to the sass worker thread being notified to wake up before a message is posted. This causes the build to be aborted because the searched file is not found. Waiting twice for a non-zero number in the signal handles this race correctly, and the second wait should be a noop in the usual case. Fixes #27167 (cherry picked from commit 5f473af)
and others
Command
build
Is this a regression?
The previous version in which this bug was not present was
No response
Description
about 5% of our pipeline fail with this error
it happened only one with
ng serveand it was very difficult to resolve, my colleague had to uninstall node and install it againpreviously he tried to delete the project and clone it again, remove yarn cache but neither work
Minimal Reproduction
it's impossible to reproduce, since even rerunning the same one succeed
it's not code error
this happens even when we were using webpack (we are using the application builder which uses esbuild), I noticed it in versions 15 and 17 of Angular
Exception or Error
Your Environment
Anything else relevant?
No response
The text was updated successfully, but these errors were encountered: