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

Обработка ошибок соединения #33

Open
DarthLegiON opened this issue Sep 7, 2017 · 6 comments
Open

Обработка ошибок соединения #33

DarthLegiON opened this issue Sep 7, 2017 · 6 comments

Comments

@DarthLegiON
Copy link

Периодически возникает исключение с текстом: couldn't connect to host
Иногда настолько часто, что это ломает логику работы. Я обрабатываю такие исключения, но лучше, чтобы само расширение производило попытку отправить запрос заново, если сервер amocrm оказывается недоступен.

@dotzero
Copy link
Owner

dotzero commented Sep 23, 2017

Понимаю эту боль, но это не проблема библиотеки, а проблема серверов с AmoCrm, не думаю что проблемы серверов должна решать библиотека. Если вы готовы написать какой-то враппер над библиотекой для повторной отправки техе запросов в общем виде, то я всего раз PullRequest'ам. Но у меня самого врятли руки до этого дойдут в ближайшее время.

@unnamedfeeling
Copy link

@DarthLegiON Если не секрет, как Вы обрабатываете неудачные отправки данных!
Автору - огромная благодарность за такой крутой код!

@DarthLegiON
Copy link
Author

@unnamedfeeling через try ... catch, а потом генерирую и высылаю себе на почту такие случаи, чтобы знать, какие лиды потеряны.

К тому же в последнее время разрывы как-то подозрительно прекратились, и я перестал заниматьс поиском решения.

Проблема в том, что для повторной отправки запроса лучше перезапускать именно метод, отвечающий за curl, а не всю отправку - это повлечет за собой лишние действия. А curl закопан глубоко внутрь класса Request. Можно было бы его унаследовать, но от него зависят десятки других. Поэтому тут поможет либо инициатива разработчика плагина, либо чей-нибудь PR

@dotzero
Copy link
Owner

dotzero commented Nov 6, 2017

Как самое простое решение, я могу добавить какой-то метод retry(), и можно дергать его, что-то вроде:

do {
    $id = null;
    try {
        $amo = new \AmoCRM\Client();
        $contact = $amo->contact;
        $contact['name'] = 'ФИО';
        $id = $contact->apiAdd();
    } catch (\AmoCRM\Exception $e) {
        $contact->retry();
    }
} while($id === null);

Но если все это прекратилось, то может и нет смысла городить такие костыли?

@DarthLegiON
Copy link
Author

@dotzero у меня прекратилось (вроде бы), а у кого-то нет, судя по ответам тут. И надо как-то ограничивать количество этих "ретраев", в общем не все так просто.

@unnamedfeeling
Copy link

unnamedfeeling commented Nov 7, 2017

@dotzero , @DarthLegiON
Я еще не попал на эту проблему. На данном этапе - для себя сделал логгирование в файлах. Кроме того - я пока-что работаю с wordpress, а в нем есть очень крутая штука "псевдо-крон" (wp-cron) - вот его задействую чуть позже (пока еще не реализовал).
Меня лично данный вопрос заинтересовал до того как оно случилось и данные потеряны ;)
Как по мне - смысл в retry() есть - "лучше перебдеть, чем недобдеть".

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants