Page MenuHomePhabricator

After a deployment, Phabricator errors out with `Unable to load the "Arcanist" library. Put "arcanist/" next to "phabricator/" on disk.`
Closed, ResolvedPublic3 Estimated Story Points

Description

This was originally reported by @Aklapper as:

  1. Go to https://phab.wmflabs.org/
  2. See Unable to load the "Arcanist" library. Put "arcanist/" next to "phabricator/" on disk.

I've since reproduced it twice after production deploys, and once in devtools. It seems to go away after a PHP restart.

After extensive debugging with @Dzahn and @thcipriani, my belief is that either

  • there's a race condition somewhere in the scap deploy setup for this project
  • and/or simply that not restarting php-fpm in the deployment scripts is leading to Some Kind of Cache Weirdness

Either way, I think the remedy is probably just to restart PHP, which I'm slightly mystified that we're not already doing.

Event Timeline

Just asking, is the library on the server, where its supposed to be and phabricator has some error causing it not to see it or is the library just fully not there?

I had this issue with attempting the last Phabricator update on my own install and the files were there.

Upgrading to Phorge did not cause it.

This error could also be caused if Phabricator was updated but not Arcanist, or vice versa. The error is output here https://github.com/phacility/phabricator/blob/9426765a2c6a149f5b0ed2d9132cd1e4e7ee152d/scripts/init/lib.php#L14

Error is gone. I guess someone has fixed it.

brennen renamed this task from phab.wmflabs.org down: Unable to load the "Arcanist" library to After a deployment, Phabricator errors out with `Unable to load the "Arcanist" library. Put "arcanist/" next to "phabricator/" on disk.`.Jun 27 2023, 8:13 PM
brennen reopened this task as Open.
brennen claimed this task.
brennen triaged this task as Medium priority.
brennen updated the task description. (Show Details)
brennen set the point value for this task to 3.
brennen added subscribers: thcipriani, Dzahn.

https://gerrit.wikimedia.org/r/plugins/gitiles/phabricator/antivandalism/+/6b59a3cd9e6170ff6797494187be98915e1985c7%5E!/ triggered this at end of June 2023. I naively wonder if https://gerrit.wikimedia.org/r/plugins/gitiles/phabricator/antivandalism/+/refs/heads/wmf/stable/src/.phutil_module_cache was involved as I added two new function calls... but really no clue, just a super vague idea. Could also be scap which I know nothing about ofc.

I had that thought, but things run correctly after a php restart, so I assumed it was a red herring.

I'm unclear if .phutil_module_cache gets generated on its own or requires an arc liberate call…

https://secure.phabricator.com/book/phabcontrib/article/adding_new_classes/

This will write three files:

  • src/.phutil_module_cache This is a cache which makes "arc liberate" faster when you run it to update the library. You can safely remove it at any time. If you check your library into version control, you can add this file to ignore rules (like .gitignore).
  • src/__phutil_library_init__.php This records the name of the library and tells libphutil that a library exists here.
  • src/__phutil_library_map__.php This is a map of all the symbols (functions and classes) in the library, which allows them to be autoloaded at runtime and dependencies to be statically managed by arc liberate.

The latter makes it sound like arc liberate would need to be run if functions change, but I suppose this might only be relevant if it's something that needs to be autoloaded externally to the class, which if I remember right your change probably doesn't?

Change 956486 had a related patch set uploaded (by Brennen Bearnes; author: Brennen Bearnes):

[operations/puppet@production] phabricator deployment: restart php when finalizing deploy

https://gerrit.wikimedia.org/r/956486

Change 956486 merged by Jelto:

[operations/puppet@production] phabricator deployment: restart php when finalizing deploy

https://gerrit.wikimedia.org/r/956486

I'm unclear if .phutil_module_cache gets generated on its own or requires an arc liberate call…

For the records, as I run into the same question in T342041, we removed that file at least in extensions in rPHEX04f637010f634301159838b6e06b3e457d8c1981