Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

SpecScanner - Fix installation error ("Class XyzSpecProvider does not exist") #24874

Merged
merged 2 commits into from
Nov 1, 2022

Conversation

totten
Copy link
Member

@totten totten commented Nov 1, 2022

Overview

(This is inspired by @eileenmcnaughton's #24807. It does not preclude #24807, but it should fix more symptoms.)

This addresses a regression affecting civiimport and search_kit (and probably civigeometry, but I haven't tested that one). The problem arises as follows:

  1. Take an extension that includes an APIv4 SpecProvider (such as civiimport or search_kit).
  2. Ensure the extension is not installed.
  3. In the web UI (civicrm/admin/extensions), install the extension.

Before (5.54.0)

It appears to work.

Internally, the installation flushes various caches in various ways. It does not flush/rebuild the container (in local/PHP memory). This can be confusing when doing automated tests, but (for production) it ultimately works out anyway. (It deletes the container-cache-file, so the future page-views will rebuild, and the final content will be correct.)

Before (5.54.1, 5.55.beta)

It appears to fail.

Internally, the installation flushes various caches in various ways. This includes flushing the container (in local/PHP memory as well as the file-based cache). This is better for automated tests, but (for production) one of the interim flushes occurs at a poor moment -- when LegacySpecScanner sees an inconsistent world and crashes with:

Class "Civi\Api4\Service\Spec\Provider\ImportSpecProvider" does not exist

After

It appears to work.

Internally, the installation flushes various caches, including the container (in local/PHP memory as well as the file-based cache). This is better for automated tests. For production, it basically works -- it ignores the inconsistent interim state (seen in 5.54.1), and it ultimately works because (as in 5.54.0) the final content of the container is correct.

…during installation

During the process of installing an extension, there are various flushes/rebuilds. Each of these flushes can lead to a (temporary) rebuild of the container.

In 5.54.0, a caching bug prevents these flushes from rebuilding the container promptly.

In 5.54.1 and 5.55.beta, the caching bug goes away -- and now it tries to rebuild the container (multiple times).
However, during the an early attempt, it fails: there is a mismatch between `getActiveModuleFiles()` (which is used by
`CRM_Api4_Services`/`LegacySpecScanner` to discover classes like `ImportSpecProvider`) and the active class-loader
(which is not available yet -- but it's supposed to load the source for `ImportSpecProvider`). This
means that `CRM_Api4_Services`/`LegacySpecScanner` may raise a class-not-found exception.

This patch basically makes `LegacySpecScanner` behave more like `ClassScanner` during the early parts
of bootstrap -- if a class is not loadable yet, then ignore it.

This should still work out in the end -- because there are multiple rebuilds, and the final disposition is based on the
final build.
The `SearchKitSubscriber` is now registered as an auto-service. This behaves better when dealing with
various enable/disable flows.
@civibot
Copy link

civibot bot commented Nov 1, 2022

(Standard links)

@civibot civibot bot added the 5.55 label Nov 1, 2022
@seamuslee001
Copy link
Contributor

This seems ok to me

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
2 participants