The dreaded afform scanner not found

added git:civicrm-core sig:bug triaged labels

Hi,

Thank you for raising an issue to help improve CiviCRM. As you may know, this issue has not had any activity for quite some time, so we have closed it.

We would like you to help us to determine if this issue should be re-opened:

If this issue was reporting a bug, can you attempt to reproduce it on a latest version of CiviCRM?
If this issue was proposing a new feature, can you verify if the feature proposal is still relevant? Did it get the concept-approved label? Have other people also shown interest? Could it be implemented as an extension?

If the answer to either question is yes, please feel free to comment or re-open the issue. Please also consider:

Is it something that you could help implement, either by sending a patch or hiring someone who can?
Would you be willing to fund the work, either through a CiviCRM partner, or the Core Team?

Thank you for your help and contributions to CiviCRM.

P.S. This is an automated message, see infra/gitlab issue 20. We understand that automatic responses are annoying, but given the number of open issues as the project evolves, we need a bit of help to triage and prioritise the most relevant issues.

closed

I've run into this, in an admittedly odd type of build scenario, and I need to take a break from it for a bit, but putting some notes because I have a theory based on some debugging.

Looking at this block: https://github.com/civicrm/civicrm-core/blob/cdacfe7d990da419617a4cc337ab63b249cf4c32/Civi/Core/Container.php#L71-L89

    $envId = md5(implode(',', array_merge(
      [\CRM_Core_Config_Runtime::getId()],
      array_column(\CRM_Extension_System::singleton()->getMapper()->getActiveModuleFiles(), 'prefix')
    )));
    $file = \Civi::paths()->getPath("[civicrm.compile]/CachedCiviContainer.{$envId}.php");
    $containerCacheClass = "CachedCiviContainer_{$envId}";
    $containerConfigCache = new ConfigCache($file, $cacheMode === 'auto');
    if (!$containerConfigCache->isFresh()) {
      $containerBuilder = $this->createContainer();
      $containerBuilder->compile();
      $dumper = new PhpDumper($containerBuilder);
      $containerConfigCache->write(
        $dumper->dump(['class' => $containerCacheClass]),
        $containerBuilder->getResources()
      );
    }

    require_once $file;
    $c = new $containerCacheClass();

An early run creates a file with a specific envId. At this point the afform_scanner does not appear to be in the cached container. Note that even if this gets rebuilt and does now contain afform_scanner, if the envId does not change, the require_once won't load the new file, since it has the same name and is already loaded. Therefore you just get the old version of the class.

Two possible holes in this theory:

I'm not sure that's how require_once actually works, but it fits my debugging output as to the differences between the cached file and the methodMap in the actually loaded class.
The envId seems to include afform even in earlier builds, but I can see that in the earlier build its hook_civicrm_container is not being called, although it is in the later build. At the moment this doesn't make sense to me, but is something further to investigate.

The main thing seems to be that \CRM_Extension_System::singleton()->getMapper()->getActiveModuleFiles(), 'prefix') is not enough to include in the envId, but it isn't about whether afform is in that list or not, because even when afform is in that list, it may not be in this list, DrupalBase::$allModules, which is what actually determines whether its hook_civicrm_container gets called.

It is also related to the fact mentioned above that even when the envId doesn't change, the isFresh() can still come back false, and then even though the cached file is rebuilt to include afform's hook, you still end up with the old version of the class being the one in use, not the new one. I didn't try following the magical mystery tour that isFresh() wants to take you on, just I can clearly see that sometimes it is (rightly) rebuilding the file even when envId hasn't changed.

This diff fixes it for my situation. Obviously it's only for the drupals, but could be extended.

--- a/sites/all/modules/civicrm/CRM/Utils/Hook/DrupalBase.php
+++ b/sites/all/modules/civicrm/CRM/Utils/Hook/DrupalBase.php
@@ -75,6 +75,11 @@ class CRM_Utils_Hook_DrupalBase extends CRM_Utils_Hook {
     );
   }

+  public function getAllModules() {
+    $this->buildModuleList();
+    return $this->allModules;
+  }
+
   /**
    * Build the list of modules to be processed for hooks.
    */
--- a/sites/all/modules/civicrm/Civi/Core/Container.php
+++ b/sites/all/modules/civicrm/Civi/Core/Container.php
@@ -70,12 +70,14 @@ class Container {

     $envId = md5(implode(',', array_merge(
       [\CRM_Core_Config_Runtime::getId()],
-      array_column(\CRM_Extension_System::singleton()->getMapper()->getActiveModuleFiles(), 'prefix')
+      array_column(\CRM_Extension_System::singleton()->getMapper()->getActiveModuleFiles(), 'prefix'),
+      \CRM_Utils_Hook::singleton()->getAllModules()
     )));
     $file = \Civi::paths()->getPath("[civicrm.compile]/CachedCiviContainer.{$envId}.php");
     $containerCacheClass = "CachedCiviContainer_{$envId}";

mentioned in commit 815d89b5

mentioned in commit 3a411d2b

I can confirm just now that this fixed my issue of this appearing on a 5.73 upgrade @totten

Oh I spoke too soon. I applied this but upon doing an upgrade I'm stuck on

WARNING: Class CRM_Afform_AfformScanner was expected to have a service definition, but it did not. Perhaps it needs service name.```

Perhaps I'm missing some other element that was added earlier that linked here?

It explodes on DOA.php line 1882 with

2024-09-05 01:27:00+0000  [warning] params array (
  1 => 
  array (
    0 => NULL,
    1 => 'String',
  ),
  2 => 
  array (
    0 => 'civicrm_search_display',
    1 => 'String',
  ),
)

cc @totten

changed milestone to %5.78.0

Ok you can ignore the noise from above all good.

Trying to update CiviCRM 5.76.2 to 5.77.0, and the message is still comes up (and I got it at the last 5-6 monthly updates...). Some refreshes "fixed" the problem.

Noting that the link to the PR is missing here: https://github.com/civicrm/civicrm-core/pull/31045. It approached the problem by moving the scanner registration out of hook_civicrm_container. But it's only in 5.78+ so you won't see any difference on 5.77.

This error disappeared for a couple bugfix versions and then reappeared again in 5.78.3.

Executing upgrade...
......Error executing task "Finish core DB updates 5.78.3"
In ContainerBuilder.php line 996:
  You have requested a non-existent service "afform_scanner".

It's killing out automated build for testing. I might try to have it ignore errors coming from cv upd and first test the update locally.

reopened

Upgrade from CiviCRM 5.79.1 to 5.80.0 on Drupal7, and the error is still there.

Just noting that I still get this on a Wordpress 5.81rc site (which has always had it on upgrade) and have seen it start to happen on a Drupal7 site (version 5.79). On the drupal site the timing is possibly around when we adopted the version with https://github.com/civicrm/civicrm-core/pull/31045

Both sites have civitoken installed - could that relate - this is the container hook.

/**
 * Add token services to the container.
 *
 * @param \Symfony\Component\DependencyInjection\ContainerBuilder $container
 */
function civitoken_civicrm_container(ContainerBuilder $container) {
  $container->addResource(new FileResource(__FILE__));
  $container->setDefinition('crm_civitoken', new Definition(
    \Civi\Token\CiviTokens::class,
    []
  ))->addTag('kernel.event_subscriber')->setPublic(TRUE);
}

I have the "Fuzion tokens" extension enabled on both (dev and prod) sites, but only the dev environment shows the error. In the prod environment, the update does not show this error. So I guess I'm not sure if this would be decisive -- although, it's possible.

The dreaded afform scanner not found

Child items ...

Activity