Hi there,
we start using the MUAO custom environments intensively for our APP development. Multiple Feature branches are installed via CI/CD to separate environments to perform tests. Beforehand we “locked” our development site for each pipeline run, making the other ones to wait till the site gets unlocked. (We handle locks in a dedicated database.)
With the custom environment we hoped to be able to get rid of the locking. But whenever concurrently a second forge --install command is triggered for the same app and at the same site (not the same environment!), the install is not performed with the following error:
Error: Installation error: Task any-task-id conflicts with another pending or in progress task. (requestId: any-request-id)
That multiple install commands run exactly at the same time is quite usual for us, because we perform our e2e test agains multiple browsers. They are triggered at the same time and have the same start-up times, so they start running forge-install within the install times of one another.
So unfortunately, finally we couldn’t get rid of the site locking yet.
Is this a bug? Is it planned to implement the concurrent installation of an app to multiple environments?
1 Like
Hey hi @JasonMarx ,
Welcome to the community!
This is not a bug. I will discuss with the relevant team and update you.
1 Like
Hi @ChandanaMeka ,
I would love to understand the reasoning here why two forge install commands to the same site block each other? Is this a limitation of the Cloud site itself?
Best
Johannes
Hey hi @JohannesKstle ,
In the implementation the lock is applied on a combination of site and appId . It doesn’t include the environment as of today and hence this issue. Ideally we should include lock on the combination of all 3 parameters to enable parallel install and uninstall. I have raised a public facing JAC ticket for this issue https://jira.atlassian.com/browse/ECO-211. Please do watch and vote this issue which will help raise the priority.
1 Like
Hi @ChandanaMeka,
thank you for your reply and for opening the ticket!
As a workaround we implemented a locking for the un-/install and deployment.
When our renovate-piplines start running to update the dependencies for all our apps, we get some errors which sound like rate limits, namely Error: You are trying to access 'appInstallationTask' too often on the forge --install step and Error: You are trying to access 'createAppDeploymentUrl' too often on the forge --deploy step.
I only found rate limits for the app usage. Can you provide me some details about those rate limits we encounter?
We would like to adapt our procedures to lower your and our costs.
Hi @ChandanaMeka,
I checked the verbose output and saw that the appInstallationTask is tried to be accessed several times by one run of forge install. So maybe this rate limit is not directly related to our MUAO-Setup, but is a general rate limit for every forge install run. Can you please clearify for us on what the success of an access attempt to the appInstallationTask relies (site, user, environment, app, nothing of those)?
Hey hi @JasonMarx ,
I have asked the team and they mentioned that
Regardless of dimensions, user can call appInstallationTask 20 times every 10 seconds
For createAppDeploymentUrl rate limit is 1 call per 1 second per app id
Hi @ChandanaMeka,
thank you for your reply, these pieces of information are very helpful for us!
We do not track the rate limit for appInstallationTask on our side but rather handle the error properly and try to avoid it by design of our infrastructure.
Recently we run into a curious situation quite often: We triggered an (un-)install of an app and received the appInstallationTask-Error. Despite the error, the action seems to be executed and our retry fails. We are planning to handle this case properly, too.
Would you nevertheless be so kind to report this behaviour to the developers? For us it feels like there is a bug.