Problem/Motivation

Usually, Starshot is installed very quickly. For some reason, the installation now takes much longer, just short of three minutes. It looks like the installation of each modules takes about 7 seconds.

Perhaps there is a setting in Automatic Updates which can be added in Starshot to not check for status, assuming this is the problem?

Originally reported in Installation stalls for a minute, or more #157 in Starshot Github repo.

Steps to reproduce

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Issue fork automatic_updates-3465155

Command icon Show commands

Start within a Git clone of the project using the version control instructions.

Or, if you do not have SSH keys set up on git.drupalcode.org:

About issue forks

Comments

ressa created an issue. See original summary.

catch’s picture

catch
he/him
Primary language English
commented
Title: Starshot install takes several minutes, due to Automatic Updates check? » automatic_updates_modules_installed() significantly slows down module install
Category: Feature request » Bug report

automatic_updates_modules_installed() should at least check the $is_syncing parameter and not show when that's TRUE, although I can't remember off the top of my head whether that gets set during site install.

It's not clear to me exactly why these need to be run immediately and can't just be shown on the status report though, or whether they couldn't be moved to a submit handler on the module install form (or even whatever page that redirects to) rather than also being done during site install, drush etc.

phenaproxima’s picture

phenaproxima
he/him
Primary language English
Location Massachusetts
commented

@tedbow and I discussed it and although we're open to other options, the thing we should do in the short term to stop the bleeding in the Starshot prototype is not run the status checks if Drupal is in the middle of being installed.

phenaproxima opened merge request !1091

catch’s picture

catch
he/him
Primary language English
commented
Status: Active » Needs work

Double checked the installer and $is_syncing is explicitly set to false there, so wouldn't help by itself and we'd need the separate installer check anyway.

I think this should check both tbh - i.e. it shouldn't be doing this during a config import either, the admin has already seen the message when the module was installed on local, or at the very least won't see it during a site deployment.

phenaproxima’s picture

phenaproxima
he/him
Primary language English
Location Massachusetts
commented
Priority: Normal » Critical
Status: Needs work » Needs review

I concur. I added a check for config sync, and test coverage for both scenarios.

Also tagging this as critical since it causes a serious performance problem.

phenaproxima’s picture

phenaproxima
he/him
Primary language English
Location Massachusetts
commented
Issue tags: +Starshot blocker
tedbow’s picture

tedbow
he/him
Primary language English
Location Ithaca, NY, USA
commented
Status: Needs review » Reviewed & tested by the community

Looks good!

phenaproxima’s picture

phenaproxima
he/him
Primary language English
Location Massachusetts
commented
tedbow’s picture

tedbow
he/him
Primary language English
Location Ithaca, NY, USA
commented
Assigned: Unassigned » phenaproxima
Status: Reviewed & tested by the community » Needs work
phenaproxima’s picture

phenaproxima
he/him
Primary language English
Location Massachusetts
commented
Assigned: phenaproxima » Unassigned
Status: Needs work » Reviewed & tested by the community

Nice idea; done. I'm restoring RTBC here on the assumption that tests will pass.

phenaproxima’s picture

phenaproxima
he/him
Primary language English
Location Massachusetts
commented
Status: Reviewed & tested by the community » Fixed

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.