On D8.9-beta2 and PHP 7.4, scanning of modules results in errors like this:

Server error: `POST http://website.test/admin/reports/upgrade-status/analyze/module/admin_to...` resulted in a `500 500 Service unavailable (with message)`

In case it's related, Drush updatedb throws the following error:

TypeError: Argument 1 passed to Drupal\upgrade_status\ThemeFunctionDeprecationAnalyzer::__construct() must be an instance of Drupal\Core\DependencyInjection\Container, instance of Drupal\Core\DependencyInjection\ContainerBuilder given in Drupal\upgrade_status\ThemeFunctionDeprecationAnalyzer->__construct() (line 39 of /var/www/drupalvm/drupal/web/modules/contrib/upgrade_status/src/ThemeFunctionDeprecationAnalyzer.php) #0 [internal function]: Drupal\upgrade_status\ThemeFunctionDeprecationAnalyzer->__construct(Object(Drupal\Core\DependencyInjection\ContainerBuilder))

Comments

extect created an issue. See original summary.

gábor hojtsy’s picture

Status: Active » Needs review
StatusFileSize
new1.41 KB

So this is how we define the ThemeFunctionDeprecationAnalyzer in upgrade_status.services.yml

  upgrade_status.theme_function_deprecation_analyzer:
    class: Drupal\upgrade_status\ThemeFunctionDeprecationAnalyzer
    arguments: ['@service_container']

Don't know when would the service container be different base classes, but either way best practice would be to typehint on the interface we need. Let's try this. Can you test with this?

extect’s picture

Thank you!! This successfully fixes the issue with ThemeFunctionDeprecationAnalyzer.
The scanning exception with an error 500 on every test still exists though.

gábor hojtsy’s picture

Any other error in your logs? Can you isolate the error to scanning a specific module or happens with all modules?

extect’s picture

The error occurs no matter which module I try to scan.
Two entries in the log:

a) PHP-Error @ http://website.test/admin/reports/upgrade-status/analyze/module/admin_to...
Symfony\Component\Routing\Exception\MethodNotAllowedException: in Drupal\Core\Routing\MethodFilter->filter() (line 46 of /var/www/drupalvm/drupal/web/core/lib/Drupal/Core/Routing/MethodFilter.php).

b) Notice @ http://website.test/admin/reports/upgrade-status:
Processing projects without HTTP sandboxing because the built-in PHP webserver does not allow for that.

gábor hojtsy’s picture

Status: Needs review » Active

Thanks, I will commit the above fix in #3126770: Argument 1 passed to ThemeFunctionDeprecationAnalyzer::__construct() must be an instance of Container and credit you there, so we can continue resolving your actual 500 error. Moving this back to Active for that.

gábor hojtsy’s picture

Status: Active » Needs review
StatusFileSize
new2.84 KB

Now that I committed that, I went to see what happens to route processing in case PHP built-in webservers, because that should not happen. Noticed that in that case we are still trying to do the HTTP request anyway. While we catch any exception, we should not even try to do that as we already decided at that point that we should not do it. Not sure this will fix anything for you yet, but you should get a distinct log message now about which method is being used (as in which of the three cases do you fall into). Looks like the PHP webserver notice was printed for all cases, which is a problem. It does not help us debug issues if it is printed even for non PHP webserver case. Duh.

This is the kind of thing that cannot be automatically tested much at least in our test setup.


On top of testing feedback for this patch, I would be really interested in any other data about your Symfony filter error. Paths like http://website.test/admin/reports/upgrade-status/analyze/module/admin_toolbar only allow POST requests (see upgrade_status.routing.yml). Did you try to manually invoke that path? Normally it is accessed from UpgradeStatusForm::parseProject() via a POST HTTP request.

  • Gábor Hojtsy committed 3075636 on 8.x-2.x
    Issue #3126600 by Gábor Hojtsy: Interim patch to improve logging for...
gábor hojtsy’s picture

Status: Needs review » Postponed (maintainer needs more info)

Committed #7 even though that will not resolve your problem, but it eliminates one confusing bug on the way. Now awaiting answers to questions in #7 :)

extect’s picture

Thanks for you help!! I applied patch from #7. Not getting any different/additional error messages though. When I try to manually access http://website.test/admin/reports/upgrade-status/analyze/module/admin_toolbar, I at least get some more backtrace information:

Symfony\Component\Routing\Exception\MethodNotAllowedException: in Drupal\Core\Routing\MethodFilter->filter() (line 46 of core/lib/Drupal/Core/Routing/MethodFilter.php).
Drupal\Core\Routing\Router->applyRouteFilters(Object, Object) (Line: 127)
Drupal\Core\Routing\Router->matchRequest(Object) (Line: 92)
Drupal\Core\Routing\AccessAwareRouter->matchRequest(Object) (Line: 150)
Drupal\Core\Routing\AccessAwareRouter->match('/admin/reports/upgrade-status/analyze/module/admin_toolbar') (Line: 138)
Drupal\user\Plugin\LanguageNegotiation\LanguageNegotiationUserAdmin->isAdminPath(Object) (Line: 104)
Drupal\user\Plugin\LanguageNegotiation\LanguageNegotiationUserAdmin->getLangcode(Object) (Line: 186)
Drupal\language\LanguageNegotiator->negotiateLanguage('language_interface', 'language-user-admin') (Line: 131)
Drupal\language\LanguageNegotiator->initializeType('language_interface') (Line: 218)
Drupal\language\ConfigurableLanguageManager->getCurrentLanguage() (Line: 92)
Drupal\language\EventSubscriber\LanguageRequestSubscriber->setLanguageOverrides() (Line: 74)
Drupal\language\EventSubscriber\LanguageRequestSubscriber->onKernelRequestLanguage(Object, 'kernel.request', Object)
call_user_func(Array, Object, 'kernel.request', Object) (Line: 111)
Drupal\Component\EventDispatcher\ContainerAwareEventDispatcher->dispatch('kernel.request', Object) (Line: 127)
Symfony\Component\HttpKernel\HttpKernel->handleRaw(Object, 1) (Line: 68)
Symfony\Component\HttpKernel\HttpKernel->handle(Object, 1, 1) (Line: 57)
Drupal\Core\StackMiddleware\Session->handle(Object, 1, 1) (Line: 47)
Drupal\Core\StackMiddleware\KernelPreHandle->handle(Object, 1, 1) (Line: 106)
Drupal\page_cache\StackMiddleware\PageCache->pass(Object, 1, 1) (Line: 85)
Drupal\page_cache\StackMiddleware\PageCache->handle(Object, 1, 1) (Line: 50)
Drupal\ban\BanMiddleware->handle(Object, 1, 1) (Line: 47)
Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle(Object, 1, 1) (Line: 52)
Drupal\Core\StackMiddleware\NegotiationMiddleware->handle(Object, 1, 1) (Line: 23)
Stack\StackedHttpKernel->handle(Object, 1, 1) (Line: 708)
Drupal\Core\DrupalKernel->handle(Object) (Line: 19)

Hope that helps?

extect’s picture

Status: Postponed (maintainer needs more info) » Active
gábor hojtsy’s picture

Well it is not meant to be accessible with the GET method (see the routing.yml) so this error is expected when manually loading it. But upgrade status requests it as a POST request. And that method is allowed on it.

extect’s picture

Makes sense. However, it throws the very same error when I try to trigger a scan for any of my module via the admin interface without manually accessing the URL.

gábor hojtsy’s picture

Status: Active » Needs review
StatusFileSize
new6.22 KB

Slept on this and had a thought. We can use the same admin endpoint to test the HTTP request capability that will eventually be used, which way we also test the whole session pass-through, etc. If that works, there must be a high likeliness that the eventual HTTP sandboxing will work. If that does not work, then it makes most sense to fall back on not using that sandbox and going with the potential consequences of the inline parser.

Here is the patch for that. This may also be a suitable workaround at least for #3127210: Scanning contributed projects fails with a cURL error when scanning through the UI over HTTP and #3126997: 403 error because Upgrade Status does not send proper authentication to https URL.

extect’s picture

Excellent!! Thank you! That got it working for most of the modules (like admin_toolbar). There are a few exceptions though (like advagg or honeypot module), where scanning throws the error below:

An AJAX HTTP error occurred.
HTTP Result Code: 500
Debugging information follows.
Path: /batch?id=57&op=do_nojs&op=do
StatusText: 500 Service unavailable (with message)
ResponseText: The website encountered an unexpected error. Please try again later.UnexpectedValueException: Could not parse version constraint : Invalid version string "" in Composer\Semver\VersionParser->parseConstraint() (line 482 of /var/www/drupalvm/drupal/vendor/composer/semver/src/VersionParser.php). Composer\Semver\VersionParser->parseConstraints('') (Line: 40)
Composer\Semver\Semver::satisfies('9.0.0', NULL) (Line: 240)
Drupal\upgrade_status\DeprecationAnalyzer->analyze(Object) (Line: 732)
Drupal\upgrade_status\Form\UpgradeStatusForm::parseProject(Object, , Array) (Line: 295)
_batch_process() (Line: 137)
_batch_do() (Line: 93)
_batch_page(Object) (Line: 55)
Drupal\system\Controller\BatchController->batchPage(Object)
call_user_func_array(Array, Array) (Line: 123)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 573)
Drupal\Core\Render\Renderer->executeInRenderContext(Object, Object) (Line: 124)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->wrapControllerExecutionInRenderContext(Array, Array) (Line: 97)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 151)
Symfony\Component\HttpKernel\HttpKernel->handleRaw(Object, 1) (Line: 68)
Symfony\Component\HttpKernel\HttpKernel->handle(Object, 1, 1) (Line: 57)
Drupal\Core\StackMiddleware\Session->handle(Object, 1, 1) (Line: 47)
Drupal\Core\StackMiddleware\KernelPreHandle->handle(Object, 1, 1) (Line: 106)
Drupal\page_cache\StackMiddleware\PageCache->pass(Object, 1, 1) (Line: 85)
Drupal\page_cache\StackMiddleware\PageCache->handle(Object, 1, 1) (Line: 50)
Drupal\ban\BanMiddleware->handle(Object, 1, 1) (Line: 47)
Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle(Object, 1, 1) (Line: 52)
Drupal\Core\StackMiddleware\NegotiationMiddleware->handle(Object, 1, 1) (Line: 23)
Stack\StackedHttpKernel->handle(Object, 1, 1) (Line: 708)
Drupal\Core\DrupalKernel->handle(Object) (Line: 19)
gábor hojtsy’s picture

That new notice and UnexpectedValueException is because of #3126949-14: Missing requirement in composer.json should not generate a warning, attempting to fix it there now. Thanks for testing.

gábor hojtsy’s picture

Title: Upgrade status scans fail with error 500 » Upgrade status scans fail with error 500 due to HTTP request issues, make HTTP request testing more specific

  • Gábor Hojtsy committed adf9d90 on 8.x-2.x
    Issue #3126600 by Gábor Hojtsy, extect: Upgrade status scans fail with...
gábor hojtsy’s picture

Status: Needs review » Fixed

Ok based on your feedback I committed the above two issues. This should resolve your problems in my understanding by avoiding HTTP sandboxing at least when it would fail.

Status: Fixed » Closed (fixed)

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