Почему скрипт выполняется не до конца?

Question

[crack_user]

В базе около 9к юзеров, вот скрипт для рассылки в ТГ боте.

public function forwardSend()
    {
        ini_set ( 'max_execution_time', 0);
        global $data, $user;
        $this->app->sendMessage('Вы отправили рассылку');
        $user->updateUser(['peremen' => 0]);

        $users = $user->getAll();
        foreach($users as $us)
        {
            $this->app->chatId = $us['user_id'];
            $this->app->forwardMessage($data['message']['chat']['id'], $data['message']['message_id']);
            sleep(1);
        }
    }

При выводе echo ini_get('max_execution_time') - выводит 0, насколько мне известно "0" это бесконечно. Пробовал также указывать 15к секунд, но всё равно так и так рассылка приходит только 1000 пользователям. ТГ никаких ошибок не выдает. В чем может быть проблема?

Comments

[iljaGolubev]

https://core.telegram.org/bots/faq#my-bot-is-hitti...

If you're sending bulk notifications to multiple users, the API will not allow more than 30 messages per second or so.

[crack_user]

iljaGolubev, Ставил даже 1 сообщение раз в секунду - не помогло

Answer 1

[ThunderCat]

рассылка приходит только 1000 пользователям.

Если прям ровно 1000, очевидно это ограничение ТГ.

ТГ никаких ошибок не выдает.

Как это проверяется?
$res = $this->app->forwardMessage(...)очевидно что-то возвращает, подозреваю ответ в виде саксесс/фэйл, но вы его нигде не используете.

Посмотрел доку - он возвращает объект Message в случае успеха, и код ошибки в случае неудачного запроса. Проверяйте $response->getMessageId(); для определения удачного запроса.

Comments

[crack_user]

Некорректно выразился, около 1000. Вот последний раз запустил рассылку в 13:19:47, скрипт закончился в 13:36:10, образно берем 16 минут, это 960 секунд, т.е. 960+- юзеров получили рассылку, хотя должно было быть 8к.

Ошибки записываю в лог файл. В лог файлах также ошибки никакой нет.
Если бы была ошибка связанная с ограничениями ТГ - то она бы выглядела так
Too Many Requests: retry after 536 telegram
Я уже её пару раз ловил, когда не ставил sleep в 1 секунду.

public function forwardMessage($fromChatId, $messageId) {
        try {
            $data = [
                'chat_id' => $this->chatId,
                'from_chat_id' => $fromChatId,
                'message_id' => $messageId
            ];

            $url = $this->apiUrl . 'forwardMessage';

            $res = $this->sendRequest($url, $data);

            if ($res['ok'] == 1) {
                return $res;
            } else {
                throw new \Exception($res['description'] ?? 'Unknown error');
            }

        } catch (\Exception $e) {
            $this->logError($e->getMessage());
            return ['error' => $e->getMessage()];
        }
    }

[crack_user]

Метод отправки рассылки обновил под такой

public function forwardSend()
    {
        ini_set ( 'max_execution_time', 0);
        global $data, $user;
        $this->app->sendMessage('Вы отправили рассылку');
        $user->updateUser(['peremen' => 0]);

        $users = $user->getAll();
        foreach($users as $us)
        {
            $this->app->chatId = $us['user_id'];
            $this->app->forwardMessage($data['message']['chat']['id'], $data['message']['message_id']);
            sleep(1);
        }
    }

[2medic]

crack_user, вы сейчас ловите либо исключение, либо состояние, когда ответ от sendRequest не равен ok. Тем не менее, ответ может быть ok, но при этом api телеграма возможно что-то вам в этом ответе говорит и на что-то ругается. Попробуйте логировать все ответы.

[crack_user]

2medic, Я ранее все ответы также логировал. Просто в моменте обрывается скрипт и всё, от ТГ никаких ошибок.

[2medic]

crack_user, т.е. вы отсылаете запрос к апи, и каждый раз получаете валидный ответ? Просто в какой-то момент ваш скрипт перестаёт отсылать запросы?

[crack_user]

2medic, Верно

[2medic]

crack_user, в логах ОС нет проблем? Нет информации о том, что процесс, исполняющий ваш скрипт, убит системой? Запустите ваш скрипт, передав его PHP, посмотрите код ответа.

[FeST1VaL]

crack_user, а не смотрели ошибку в вебхуке (если конечно через него подключено)?

[FeST1VaL]

У меня еще был такой прикол с ТГ, что возвращался не валидный ответ, сам тг разрывал соединение с API и сообщение не отправлялось. Многие это решали через переотправку при определенном ответе TG.

Ну раз у вас нету ошибок, то возможно не этот вариант, я все же думаю как выше сказали, что проблема может быть какая то из вне

[crack_user]

FeST1VaL, всм ошибку в вебхуке?

[FeST1VaL]

crack_user,

https://api.telegram.org/bot{Ключ бота}/getWebhookInfo

там возможно будет ошибка, это все догадки

[ThunderCat]

crack_user, насколько я вижу, проблема не в коде, а во взаимодействии с апи, и смысла искать что там не работает я не вижу. ИМХО проще записывать в какое-то хранилище айди пользователя которому отправляется сообщение, затем просто выбрать всех у кого айди больше чем этот айди, запустить скрипт еще раз и разослать следующей пачке юзеров, повторять пока в выборке не останется пользователей для рассылки. Можно конечно отлавливать что происходит до посинения, но тут вопрос что важнее - шашечки или ехать.

Если есть желание отлавливать - для начала попробовать с другого хоста (вполне возможно что например таймлимит прибит гвоздями и поменять его программно нельзя или для сервера есть ограничение по времени соединения), потом проверить запуск скрипта вытаскивая из базы кусками по 500 штук и сделать вложенные циклы (внешний вытаскивает 500 пользователей, внутренний делает рассылку по этим 500), чтобы проверить не переполняется ли память... Короче вариантов масса.

Answer 2

[Mors Clamor]

У вас 0 обработок ошибок в коде, оберните все это хозяйство хотя бы в try catch и пишите в лог, скорее всего телега отбивает по частоте запросов

Comments

[crack_user]

Я ведь написал, что ТГ никаких ошибок не выдает, я так и так логирую все результаты запросов с апи тг с моих рассылок. Там просто в моменте обрывается и всё

[Mors Clamor]

crack_user, ну значит выводите на экран или в файл значение массива users, смотрите сколько там по факту элементов, делайте отладочные выводы в теле цикла, мол "отправляю сообщение пользователю $user_id" и тд

[Ипатьев]

а зачем оборачивать в в try catch и писать в лог?
РНР ведь и так прекрасно логирует ошибки?

[Mors Clamor]

Ипатьев, если его сконфигурировать правильно, да, но я предпочитаю писать свои обработчики

[Ипатьев]

Mors Clamor, пишите, кто не даёт
а в try catch-то зачем оборачивать? :)

Answer 3

[Vitsliputsli]

никаких ошибок не выдает... Там просто в моменте обрывается и всё

Запускаете дебаггер и смотрите, что происходит. Если нельзя воспользоваться дебаггером, значит логируйте шаги выполнения, увеличивайте детализацию логирования пока не локализуете проблему.

Без этой информации можно лишь гадать, варианты:
1) скрипт выполняется корректно (например, у вас не 8к записей, читаете не из той БД, не с теми параметрами и т.п.);
2) происходит ошибка, но мы ее не видим (смотрим не в тот лог, гдето присобачен обработчик, который перехватывает ошибки и подавляет их сообщения, и т.п.);
3) скрипт действительно аварийно прерывается без каких либо сообщений об ошибках (значит чтото дает команду на это, если самовредительством не занимались, то остается только oom killer, но вряд ли у вас безлимит на память php, и то что закончилась память вы бы заметили, так что очень маловероятно);
4) неведомая хрень (баги в php, в ОС и хз что еще, еще менее вероятно, чем п3).

Comments

[crack_user]

По первому пункту - нет, я сейчас решил создать отдельный php скрипт

for ($i = 1; $i <= 1500; $i++) {
    file_put_contents('testTIME2.txt', $i."\n", FILE_APPEND);
    sleep(1);
}

всё равно $i доходит от 1000 до 1100

Посмотрю еще логи

Также пробовал - выставлять set_time_limit(15000); в nginx по советам хоста также проставил proxy_read_timeout, не помогло

[Vitsliputsli]

crack_user, прям такой скрипт? и все, больше в нем ничего нет?
Это php-fpm или php-cli? Запустите и в том, и в другом, если есть другая версия php попробуйте и в ней тоже.
Что будет если убрать sleep? Если поменять его значение?
Добавьте вывод на экран инфо для каждого шага.

Проблему наблюдаете только на сервере где запускаете, локально ее нет? Если да, то с этим скриптом уже можно задать вопрос владельцам сервера, что за хрень творится. Вполне возможно, что какието вредители на сервере жестко убивают скрипты.

[tgarl]

всё равно $i доходит от 1000 до 1100

Это значит что у вас в настройках сервера где-то стоит ограничение
1000сек это чуть больше 15 минут

- проверьте max_execution_time
- если у вас что-то завязано на сессию, проверьте её время
- так же проверьте настройки выполнения скрипта с потерей пользователя типа ignore_user_abort(true)

[Vitsliputsli]

tgarl, вряд ли, даже если это fpm, здесь пишем в файл, а не в стандартный вывод, поэтому неважно когда nginx устанет ждать. ignore_user_abort(true) опять же ни на что не повлияет, т.к. ничего не отправляем в стандартный вывод.
max_execution_time или какаято иная причина преждевременного прерывания скрипта должна быть отражена в логе.
Нужно больше информации, и больше вариантов запуска вышеуказанного скрипта. Сомневаюсь, что в логах ничего нет. У нас аш 3 приложения: интерпретатор выполняющий скрипт, мастер процесс fpm, nginx. И у каждого свои логи, и каждый както должен реагировать.

[crack_user]

Пошуршал по логам - ничего не нашел толкового. Попробовал через консоль скрипт запустить - запустился, в итоге перенес в такой формат рассылку.

[tgarl]

Ну не знаю, какие там настройки на сервере могут быть. Просто то что привели как пример

всё равно $i доходит от 1000 до 1100

очень похоже на ограничение так как 1000 слипов это как я и сказал примерно +/- 15минут. Опять же я не знаю как этот скрипт запускается , но когда-то сталкивался с ограничениями именно такими как я сказал(разбор xml из 1С), и ничего в логи в этом случае не шло(грубо говоря из 1000 товаров только 500 обрабатывалось и никаких ошибок в логах), просто скрипт отваливался по истечении времени. В итоге помогло решение именно с ignore_user_abort и max_execution_time , правда к нему ещё пришлось и memory_limit потом увеличивать, потому что после уже нормально получил о не хватке памяти