Closed michabbb closed 1 year ago
btw...
// app/Providers/AppServiceProvider.php
public function boot(Request $request): void
{
\Laravel\Prompts\Prompt::fallbackWhen(true);
}
is not working for me. there is no output, so to use "schedule:test" I first have to do a "schedule:list" and remember the number I want to call.
Hey @michabbb,
I'm having trouble replicating this one. I have Fedora and Podman, but I wouldn't think that matters.
A few questions:
What is the actual terminal application that you are using? E.g. gnome-terminal
, kitty
, etc.
Did this work for you previously? I.e. prior to Laravel 10.25 and Prompts 1.19?
What is the result of running this command?
docker run --rm -it -v ${PWD}:/app -w /app --init michabbb/php:8.2.bullseye php -r "var_dump(stream_isatty(STDIN));"
Does it work outside of Docker? I.e. running php artisan schedule:test
not in a container?
thanks for your feedback.
1) I am running a regular Ubuntu 22.04.3 LTS
and my konsole is:
$ /usr/bin/konsole -v
konsole 21.12.3
Operating System: Kubuntu 22.04
KDE Plasma Version: 5.24.7
KDE Frameworks Version: 5.92.0
Qt Version: 5.15.3
Kernel Version: 5.15.0-84-generic (64-bit)
Graphics Platform: X11
2) this is my first time using prompts (I guess), because in other projects I am using an older version of laravel, for example 10.3.3 and there I am getting output but in the old way of just pressing the number (without choosing by the cursor).
3)
bool(true)
4) i only work with docker, so i don´t have anything installed on my host, and i prefer to leave it that way ;-) but if all that info does not help, let me know....
pardon.... how can I force laravel NOT using prompts ? as mentioned in my other posting, the "failover" is not working for me. am I doing something wrong ? thanks!!
Hi @michabbb,
Your code for disabling prompts looks good to me. I've tested that code locally with your image and can confirm it enables Symfony's prompts instead. Because there's no output, it's hard to know whether Symfony or Laravel Prompts is waiting for input.
You mentioned that you can run schedule:list
and remember the number. When you run schedule:test
and enter a number (other than 0) and press Enter
, does it run the correct schedule? If so, it would seem that you are getting Symfony prompts, because Laravel's select
prompt doesn't accept a typed number (only arrow keys).
Are you able to perform the following test:
docker run --rm -it -v ${PWD}:/app -w /app --init michabbb/php:8.2.bullseye php artisan make:command Test
handle
method on the generated command (app/Console/Commands/Test.php
) to test both prompts:
dump($this->choice('Test', ['a', 'b', 'c'], 'b'));
dump(\Laravel\Prompts\select('Test', ['a', 'b', 'c'], 'c'));
docker run --rm -it -v ${PWD}:/app -w /app --init michabbb/php:8.2.bullseye php artisan app:test
Enter
if nothing is output.It's a long shot, but could you also please try updating Prompts (to v0.1.10)?
Sorry for my late response, I am currently on vacation. I will try this weekend and let you know.
@jessarcher oh dear.... i have found the problem 😕 I am using my own package to monitor cron-jobs. because your example code is working perfectly fine, I removed everything else, my package included. now I have to find out what exactly in my package causes the issue 🤔 😖
@jessarcher okay, i think i know where the problem is:
app/Console/Kernel.php
protected function schedule(Schedule $schedule): void
{
$schedule->command..................
Artisan::call('about'); // <---------- this line prevents any output
}
it may look strange calling an artisan command at this point but I don´t know any other way to intercept into the scheduling process, that´s why I created my package as it is. to get a unique md5 hash of each of my schedule-commands I am calling
the command with my new parameter --mutex
. so inside my package, I am doing an Artisan::call
for each job that is scheduled.
so it looks like, calling "any" artisan command at this point breaks the prompt output. i don´t really know if that is a "bug", but it´s necessary for me and my package to intercept the scheduler and get control of things that should happen after something got called.
maybe some more explanation:
when a job gets scheduled by "schedule:run" my "monitor" method at the end of "Kernel::schedule" needs a unique md5 hash for each scheduled job. the way getting that custom "mutex" is to use a trait in each schedule-job so that a new parameter is available for the job: --mutex
. so when I have a job, let´s say php artisan testing:test
my trait injects the parameter and now I can call php artisan testing:test --mutex
to get only a md5 back, I will use to identify the job. that´s the reason why I am calling Artisan::call
multiple times inside the Kernel::schedule
. of course I have to find a way now to get my hash without calling an Artisan command, but to be honest, I don´t know if that is even possible, so I still hope there is a way to make this work.
the problem I am facing: the md5 is based on the parameters that are used to call the artisan command.
public function getCustomMutex(): string
{
$CommandOptions = $this->options();
unset($CommandOptions['mutex']);
$LaravelDefaultOptions = $this->getApplication()?->getDefinition()->getOptions();
$onlyMyOptions = array_diff_key($CommandOptions, $LaravelDefaultOptions);
$arguments = $this->arguments();
ksort($arguments);
ksort($onlyMyOptions);
return md5(
serialize([
'name' => $this->getName(),
'arguments' => $arguments,
'options' => $onlyMyOptions
]));
}
at the time where I made the package I didn´t see any other way to get a unique hash of the job without calling the job 😏
I hope that explains a bit why I am calling Artisan::call
inside the scheduler.
i hope there is a way to fix that....
for now, i will try to NOT use any Artisan:call
in my package. but I would guess, I am not the only one facing this issue.
it would be nice, if that would be possible again in the future.....
Hey @michabbb,
Glad you figured it out! This sounds like the same issue as #74.
If you're inside a command, you can use $this->call()
instead of Artisan::call()
, which will restore the output buffer after running another command. It sounds like this might not be an option for your use case if it's not part of a command. You could take a look at the code for that method though and see whether you can replicate the behaviour. Artisan::call()
is intended for calling commands from outside of the CLI so it brings its own null output buffer which is then passed to Prompts.
I wonder whether there is an event you could hook into instead? And if not, perhaps one could be added.
@jessarcher i am sorry, but $this->call(....)
is not the solution in my case. you can try yourself.
app/Console/Kernel.php
protected function schedule(Schedule $schedule): void
{
$schedule->command..................
$this->call('about'); // <---------- this line prevents any output
}
making a call at this point sadly doesn´t change anything 😕 as you said, in this case I don´t see a situation where hooks make any sense, because in this special case, you want full control about how laravel is running scheduled jobs, for that you have to inject your code directly in the schedule command.
is there any other thing that comes to your mind how I can reset the output after doing $this->call(...)
or Artisan::call()
??
could Process::run('.....');
maybe be an alternative ? 🤔
Hey @michabbb,
I'm not sure I understand why you need to call the command with the --mutex
option. Can you not just use md5($event->command)
to get a unique hash for each command? Or even use the existing $event->mutexName()
method?
Also, I'm not sure whether this would work for your use case, but instead of adding [log]
to the description and having your users add $this->monitor($schedule)
to their schedule, could you add a macro to the Event
class instead?
E.g.
Event::macro('monitor', function ($output = true, $force = false) {
dump($output, $force);
dump($this->command);
dump(md5($this->command));
dump($this->mutexName());
$this->before(function () {
dump('before');
});
$this->after(function () {
dump('after');
});
});
And then the schedule would look something like this:
protected function schedule(Schedule $schedule): void
{
$schedule->command('app:send-emails')
->everyMinute()
->monitor()
->description('Send emails every minute');
$schedule->command('app:send-emails --foo')
->everyMinute()
->monitor(output: false)
->description('Send emails every minute');
$schedule->command(SendEmails::class, ['--foo'])
->everyMinute()
->monitor(force: true)
->description('Send emails every minute');
}
If I understand your package correctly, this should prevent the need to add traits and method calls to the schedule and commands.
Going to close this for now but I'll have a think about the Artisan::call
issue as it would be good to be able to use that in a command context without losing the output buffer afterwards.
Thank so much for all that input. At the time I made that package I wasn't aware of the concept "macro" or at least never thought I could use it here. looks very interesting 😏 I already changed my package as u can see in the referring commit and I am using the "command" as my custom mutex. To be honest, the "--mutex" is a heck but that time, I didn't know it better 🤷♂️ 😏
I don't use Laravel's own mutex because it includes the cron-time, which makes sense for Laravel to handle "withoutOverlapping", but in my case I want something that is only unique to the job itself, without the cron. Because if a job runs at two different times, I still need to know it's the same job, so that forced me to create my own mutex in the first time 😏
I will check the macro idea, thanks a lot for pointing me to that direction 👍
And also thanks that you agree, that it would be nice to be able to make artisan calls inside cli calls in general 👍
Laravel Prompts Version
0.1.9
Laravel Version
10.25.1
PHP Version
8.2.8
Operating System & Version
linux
Terminal Application
xterm-256color (echo $TERM)
Description
i am running my php image
on a linux debian console like this:
and i don´t see any output. if I hit "enter" the first scheduled command will run. i looks like the cursor is working but there is no output at all.
Steps To Reproduce
the dockerfile is very basic: