Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Database queue connection jobs run in app root directory path instead of public #45679

Closed
KeithTurkowski opened this issue Jan 17, 2023 · 3 comments

Comments

@KeithTurkowski
Copy link

  • Laravel Version: 9.47
  • PHP Version: 8.0
  • Database Driver & Version: MySQL

Description:

When I run a job using QUEUE_CONNECTION=database it runs in a different directory path than when the job is run using QUEUE_CONNECTION=sync

Specifically, sync runs in ~/public/, and database runs in ~/

Steps To Reproduce:

Create a new Laravel app with support for database queue connections.

Create a Job that executes echo getcwd() in the handle method.

In the .env set: QUEUE_CONNECTION=sync

Dispatch the job via a route and observe that the directory path displayed is in 'public', e.g. /home/laravel_root/public

In the .env set: QUEUE_CONNECTION=database

Dispatch the job via a route, run php artisan queue:work and observe that the directory path displayed is in the root, e.g. /home/laravel_root

Notes:

I believe this behavior changed with Laravel 6

I don't find anything related to this in Laravel upgrade notes, queue / jobs documentation, or in the config/queue.php

@timacdonald
Copy link
Member

timacdonald commented Jan 17, 2023

I don't know that this is a bug.

When a HTTP request comes in, it is passed to /public/index.php. When a queue worker is run, it is run from / via php artisan queue:work.

They have different working directories as they are started from different working directories. Although at first it feels weird, I believe it makes sense and is the expected behaviour.

@KeithTurkowski
Copy link
Author

Well, it's a bit confusing behavior, so I'd think at least it should be noted in the documentation.

It's also a bit strange, with the database queue connection, if I change directory path in the current job, and then dispatch a new job, the new job will run in whatever directory path the dispatching job was in.

I encountered this issue because I was using devfactory/imagecache to cache images, and it wasn't working properly when I tried to use a Job to cache the images.

For now I'm solving the problem by adding this to all Jobs...

if(config('queue.default') == "database" && !str_ends_with(getcwd(), 'public')) { chdir('public'); }

Maybe the behavior isn't a bug, but I'd suggest to note in the documentation, and perhaps add a setting in config/queue.php to specify the default starting path for each driver connection.

@driesvints
Copy link
Member

We'd welcome PR's to the docs, thanks 👍

LukeTowers added a commit to wintercms/winter that referenced this issue Oct 30, 2024
When using a mirrored public folder (i.e. `artisan winter:mirror public`), the working directory for the request is set to base_path('public') instead of base_path(), so it is important to use absolute paths when calling File::exists() as it internally just calls file_exists(), which uses the current working directory to resolve relative paths.

Related:
- wintercms/storm@752c162#diff-58c1a5c5e22fc25e75bb02e4af9d2085cfe66b8cfe7c3cffc2f32a4fb60240aaR31
- laravel/framework#45679
- laravel/framework#13243
bennothommo pushed a commit to wintercms/wn-system-module that referenced this issue Oct 30, 2024
When using a mirrored public folder (i.e. `artisan winter:mirror public`), the working directory for the request is set to base_path('public') instead of base_path(), so it is important to use absolute paths when calling File::exists() as it internally just calls file_exists(), which uses the current working directory to resolve relative paths.

Related:
- wintercms/storm@752c162#diff-58c1a5c5e22fc25e75bb02e4af9d2085cfe66b8cfe7c3cffc2f32a4fb60240aaR31
- laravel/framework#45679
- laravel/framework#13243
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants