И я ещё раз повторю - даже если ваша гипотеза про то, что "переменная теряется в памяти" верна (это не так, но допустим), приведённая ошибка просто не может возникнуть. В вашем коде всегда в SQL-запрос передаётся int, то есть 0. А до PDO это значение не доходит. Варианта тут только два: либо проблема вообще в другом коде и вы смотрите не туда, либо модель игнорирует вашу попытку записи атрибута, потому что вы в ней чего-то навертели (а классов у вас как минимум три: BaseCRM, AmoUser и AmoContact).
Я вам совершенно точно могу сказать, что проблема не в кэше и не в свопе, а в вашем коде и ваших данных. Вероятность того, что вы столкнулись с каким-то системным багом в PHP примерно равна нулю, даже не тратьте на эти мысли времени. И никакой usleep, конечно, вам тоже не поможет.
Лучше добавьте логирование данных в файл на каждом шаге, включая ядро фреймворка (проблема будет не в ядре тоже, а в вашей конфигурации модели, но без логирования в ядре вы этого не поймёте) - тогда вы сможете понять на каком именно шаге теряются данные и дальше уже размотаете клубок исполения.
Вам уже сказано - поможет только вдумчивый дебаг всего кода на реальных данных. Приведённый код просто не может выдавать такую ошибку - вы везде приводите значение к int и если бы там был null, он превратился бы в 0 и этот 0 фигурировал бы в запросе. Ваша проблема где-то в другом месте, но не видя всего кода проекта и данных, мы вам ничего больше сказать не можем.
Может, выявит, может, не выявит. Но точно добавит забот и дискомфорта и исполнителю и управленцу.
Пример вы привели некорректный — для того, чтобы такое выявить, вовсе не требуется, чтобы исполнитель где-то отмечал сколько он думал, сколько писал и сколько отдыхал. Собственно, для этого вообще не требуется мониторить время.
Мелкие паузы и отвлечения я не отслеживаю, крупные во время задачи не отмечаются для чистоты. У нас были разработчики, которые отмечали много времени, а по факту эффективность у них была на уровне плинтуса — это тоже легко выявляется без дополнительной детализации.
И вообще такие вопросы решаются дебагом. Версия минимум - вставить дампы прямо в код фреймворка и смотреть, в каком месте ломается. Версия медиум - поставить Telescope (если он заведётся) и смотреть, какие запросы исполняются и что дампится. Версия топ - поставить XDebug.
В 99.9999% случаев проблема в вашем коде, а не в "системном", который прекрасно работает у миллионов других людей.
Во-первых, о том, что у вас версия из прошлого десятилетия, нужно говорить сразу. Во-вторых, отличия от актуальной версии там, конечно, есть, но код всё равно элементарный и должен работать.
Сейчас ещё окажется, что у вас PHP древний тоже.
Да не может оно не учитывать, вы посмотрите код фреймворка - все эти методы литерали из трёх строк.
У вас либо опечатка где-то; либо в переменной, которую вы подставляете, содержится null; либо вы fillable раскомментировали, а какой-нибудь supervisor не перезапустили, если код в очереди исполняется, и там ещё старая версия. Ещё, может, вы сеттер этого атрибута переопределили и он кривой.
Adamos, ну вот в этом случае и надо же указывать string|RegExp, а не какой-то базовый тип, но при этом не object. То, что иногда указанные типы нужно использовать, сомнению не подвергается. А вот если задача типизировать именно это подмножество скопом через один какой-то тип - она странная.
$companyID, а в Eloquent вы передаёте несуществующую переменную$company.