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