sql:sync uses wrong drush script when both sites are local.

[AdamPS]

Sorry this isn't a full bug report as I ran out of time and had to revert to drush 10 to get the sites back working (at which point it all worked again as normal). I would appreciate if someone else could report if it works for them.

1. sql:sync fails because the output of drush core-status --fields=db-name --format=json is mysteriously doubled when run from the databaseName() function. It was correct when I ran the command manually.

  [Exception]                                          
  Drush command sql:sync failed                        
                                                       
  In ProcessBase.php line 171:                         
                                                       
    Unable to decode output into JSON: Syntax error    
                                                       
    {                                                  
        "db-name": "XXX"       
    }                                                  
    {                                                  
        "db-name": "XXX"       
    }                                                  

2. sql:sync from the live site on drush 10 to the test site on drush 11 failed because of changes in league/container between the two versions. It might hard to fix, but is a bit inconvenient because that's exactly what you want to do during testing. Perhaps it could at least be documented somehow, or the error message improved??

[weitzman]

Thanks. Even a quick bug report is helpful.

1. Odd. Hopefully someone can look into this more. Maybe a change in upstream Process library. Whats your OS? on both sides of the sql:sync?
2. I dont immediately see how League version mismatch would matter.

[AdamPS]

Thanks for a quick response.

1. OS is Ubuntu 20.04. Both sides are actually the same VPS just a different root directory.
2. I found the Error Output in my console history. I noticed that the class and method names are different between the two drush versions (e.g. ClassDefinition.php vs Definition.php) so I thought it might be significant.

    ================                                                               
    PHP Fatal error:  Uncaught Error: Call to undefined method League\Container    
    \Definition\ClassDefinition::addArgument() in /data/www/testa1.albanyweb.co    
    .uk/vendor/drush/drush/src/Runtime/DependencyInjection.php:100                 
    Stack trace:                                                                   
    #0 /data/www/testa1.albanyweb.co.uk/vendor/drush/drush/src/Runtime/Dependen    
    cyInjection.php(66): Drush\Runtime\DependencyInjection->addDrushServices()     
    #1 /data/www/testa1.albanyweb.co.uk/vendor/drush/drush/src/Runtime/Runtime.    
    php(95): Drush\Runtime\DependencyInjection->initContainer()                    
    #2 /data/www/testa1.albanyweb.co.uk/vendor/drush/drush/src/Runtime/Runtime.    
    php(51): Drush\Runtime\Runtime->doRun()                                        
    #3 /data/www/testa1.albanyweb.co.uk/vendor/drush/drush/drush.php(72): Drush    
    \Runtime\Runtime->run()                                                        
    #4 /data/www/testa1.albanyweb.co.uk/vendor/drush/drush/drush(4): require('/    
    data/www/testa...')                                                            
    #5 {main}                                                                      
      thrown in /data/www/testa1.albanyweb.co.uk/vendor/drush/drush/src/Runtime    
    /DependencyInjection.php on line 100              

[weitzman]

Full verbose logs might be helpful in debugging these. No rush.

[greg-1-anderson]

The stack trace looks like a dependency hell problem. Have you installed a site-local Drush, or are you using a global install? It is expected that a global install of Drush 10 with Drupal 8 would break if you upgraded to a global install of Drush 11.

[greg-1-anderson]

Idea: Maybe we should have our error handler print out a warning message if Drush's vendor != Drupal's vendor. Might even be worth making new releases of Drush 9 and Drush 10 to get this diagnostic info (presuming that folks upgrade).

[AdamPS]

Thanks for the comments.

The stack trace looks like a dependency hell problem. Have you installed a site-local Drush, or are you using a global install?

Drush is site-local installed with composer.

[AdamPS]

OK I think I have figured it out. Both problems seem to have the same cause which is use of the wrong drush executable.

In \Drush\SiteAlias\ProcessManager::drushScript() it performs the following checks:

1. paths.drush-script - not set in my case
2. remote site - not true in my case
3. vendor/bin/drush in web root - not true because vendor dir is in parent dir, which is generally much more recommended
4. use drush from this site

So if the two sites are at different drush versions then we have classic dependency hell. If they are the same version it's more mysterious, but somehow running the wrong drush has doubled up the output.

It works if I set paths.drush-script or if I hack the code to look for vendor in the parent directory.

I propose the following fixes:

• In 3) add a check for vendor in the parent dir of the root
• In 4) using the version of drush running now seems like a really bad fallback unless it's definitely the same site. How about if we used the default drush instead?

[AdamPS]

Idea: Maybe we should have our error handler print out a warning message if Drush's vendor != Drupal's vendor. Might even be worth making new releases of Drush 9 and Drush 10 to get this diagnostic info (presuming that folks upgrade).

It's a really good idea, except that the problems I came across might mean we are running from the wrong vendor unexpectedly. So maybe we would need to port fixes to those problems back to older drush versions too?

[weitzman]

3. in your list looks like a bug. See https://github.com/drush-ops/drush/blob/11.x/src/SiteAlias/ProcessManager.php#L71. that should be ../vendor/bin/drush or should use DrupalFinder to find vendor dir. Does it work if you manually change that line?

[weitzman]

PR at #5093

[AdamPS]

Great thanks