Is composer update atomic?

Question

Short story: Can I run composer update on a running site without having to worry about which dependencies are updated first?

Longer story: I'm trying to figure out if the actual update process with composer is atomical.

Are the dependencies updated/activated all at once, when everything is downloaded and checked OK, or is each dependency updated as soon as it's downloaded? What if one update fails in the middle?

Having trouble finding docs on that, so I'm hoping someone can help out! If this is documented, I'd be happy with a link there.

Answer 1

No, composer update and composer install are not atomic.

For each dependency composer update will:

• remove the outdated dependency (leaving your application in a non-working state)
• download the new dependency (while the application is still broken)
• install the new version

If the download fails for any reason (e.g. quota limits, failed connection, etc.), then the app will be left in a non-functioning state.

Better solution (easy to setup, not atomic, with a small downtime)

A solution would be to duplicate the vendor folder and composer files in a new directory, run composer update or composer install in this directory and then switch the old vendor directory with the new one.

Even if this solution is much faster, it is not atomic and can/will lead failed requests. Indeed: - switching two directories can't be atomic - as a PHP app is spread in multiple files, a request can begin with an old version of the files and then include the new ones, which would can undefined behaviours.

However, this can be acceptable for most web applications.

Solution 2 - start a second instance (not atomic, no-downtime)

The only solution would be to duplicate the full app, update it, then change your web server configuration to use the updated application. Web servers can reload their configuration in an atomic manner.

This solution is not exactly atomic as some user will complete their request using the old version while some other users will start a new request with the new version. During a short time lapse, both versions of the application will co-exist.

Solution 3 - stack connections (atomic, small delay)

A third solution would be to use the first solution and to tell your web server to stack the requests during the small downtime.

That would mean: - Tell your web server to stack connections - Wait for the existing requests to finish (< 200ms) - Switch the application directory (<10ms) - Realise the stacked connections

Requests during the downtime will be delayed by ~200ms, which is acceptable, most of the time.

You can find more information about stacking the requests here: https://serverfault.com/questions/654780/how-to-suspend-nginx-requests-during-backend-upgrades

Answer 2

I don't know if it is atomic, however, if something fails, composer normally knows what. So you can at least verify.

Also there is:

composer update --dry-run

But you can never run composer update on a running site. You need to stop the site, do the update, and start the site again.