setup advancedqueue_runner

[ariperez]

closes #8849

[github-actions]

GitHub Workflows (.github/workflows/*.yml)

Have you...

• pinned all affected GitHub Actions at a specific commit by SHA?
• reviewed the source code of the action at the commit you are pinning?
• confirmed that no GitHub security measures are being bypassed?
• checked for any injection of user content into protected contexts?
• reviewed Security hardening for GitHub Actions?
• reviewed GitHub Workflows?

[ariperez]

@ndouglas , I'm confirming these are the correct directories....

the process kept failing silently until I kept the above directories, and modified the following line in the local package:
https://git.drupalcode.org/project/advancedqueue_runner/-/blob/2.x/src/Scripts/jobs.php?ref_type=heads#L17

becomes

$autoloader = require $_SERVER['PWD'] . '/vendor/autoload.php';

[ariperez]

@ndouglas , also, do you have a quick way to test this with a job that's prebuilt? having a bit of trouble trying to kick a test one off that increments the queue

[ndouglas]

@ariperez Yeah, we currently have vendor located within docroot. That's not best practices, and almost no one does it that way, but the decision was made before I was here and I honestly don't want to fight with it at this point.

We can use composer-patches to patch the local version of that file. See e.g. here for an example.

also, do you have a quick way to test this with a job that's prebuilt? having a bit of trouble trying to kick a test one off that increments the queue

Hmm, nope. What issue are you encountering?

I'll poke around with this a bit, if you don't mind.

Note: You're referencing #8108 but I think you want #8849.

[ariperez]

@ndouglas

• I updated the referenced closes issue.
• Thats what I assumed about the non-conventional setup, I will be honest that it took me forever to figure this out because the module would start perfectly and fail silently without logs, I figured it out eventually by modifying...
  https://git.drupalcode.org/project/advancedqueue_runner/-/blob/2.x/src/Class/Runner.php?ref_type=heads#L38
  to
  $command = 'nohup ' . $this->command . ' > /var/www/html/output.log 2>&1 & echo $!';

I'll go ahead and add the composer-patch to this pr

• Re kicking off the jobs, I see a bunch of them throughout the project, to include your phpunit tests, but I can't kick one off, that affects the advancedquery queue count. Figured i'd ask because this seems like a basic routine thing

[ndouglas]

@ariperez

So:

• I logged into Tugboat (tugboat shell 65118dcc2d3036648d50921c)
• I disabled the existing runner script by commenting out lines (nano /etc/service/drupal_events/run)
• I manually patched the module to reflect your findings
• I enabled the module (drush pm-enable advancedqueue_runner)
• I visited the setup page and created a configuration
• I viewed the config differences (drush config:export --diff)
  • created config/sync/advancedqueue_runner.settings.yml
  • modified config/sync/core.extension.yml
  • (these should be included in any PR enabling this functionality)
• Visiting the setup page shows that we have a live, functioning (supposedly) configuration:
• 
• I kicked off a new content release
• I... waited... for something to happen.
• I can see that there's a PHP process running that corresponds to the PID mentioned in the setup page:
• 
• Unfortunately, looking at the content release page, it looks like the queue isn't being run:
• 
• Confirmed not much is happening:
• 
• logged into the Tugboat server (ssm-session utility tugboat) and sued to root
• checked the PHP/Apache logs for the Docker container: docker logs 65118dcd2d3036648d5092e0 | grep -v 'Mozilla'
  • last few messages are from me editing the /etc/service/drupal_events/run script 😞

(to be continued)

[ndouglas]

(converted to draft since we're still evaluating)

I'm... eh... not crazy about this module so far. It seems really hard to inspect and debug -- the silent failure you mentioned and the fact that it's apparently set up correctly but isn't logging any errors to either the Drupal watchdog log or PHP logs. I can't find any output anywhere 🤔

I'm not enthusiastic about risking a working-but-suboptimal system for this module -- I kinda dread something going wrong and us having to debug it live on prod. And a few months from now, the suboptimal system will be gone anyway.

But that's fine, because the ticket as revised was for discovery anyway 🙂

I would like to close this PR and consider this a possibility that we checked out but did not find anything worth pursuing, unless you disagree.

[ariperez]

@ndouglas , I won't lie that this module did stress me out lol.

I concur that the right decision is probably not to implement atm. It's not battle hardened pro code yet.

At least I learned alot about the project, excited for the next ticket!