How to prevent silently discarding attributes in Laravel? - php

Question

I'm very new to both PHP and to the barely-documented legacy codebase I'm debugging. One of the attributes on one of my models is being set to NULL on DB save, and I'm not clear why. This Q is mainly about my attempts to seal off one of the possibilities.
(It might be a type-conversion error - the model treats the field as an integer but the DB thinks it is a string, or that some code sets the field and other code doesn't, or that there are large sections of unreachable code and probably a few other possibilities too. Am tracing code, but it's a few dozen files of undocumented proprietary code, so please bear with me. It's tough to make a minimal reproducible example under the circumstances.)
I came across this article on configuring Eloquent strictness, and "silently discarding" this attribute sounded a lot like "set it to null without logging an exception", so I figured I'd try it. (The field of concern is listed in its particular model's protected $fillable attribute, so I might also be barking up the wrong tree...) As per the article, my (pre-existing, presumably working) app/Providers/AppServiceProvider.php now contains this import:
use Illuminate\Database\Eloquent\Model;
and it also contains the following function definition:
/**
* Bootstrap any application services.
*
* #return void
*/
public function boot()
{
$this->trackDatabaseEvents();
Schema::defaultStringLength(191);
Model::preventSilentlyDiscardingAttributes(! $this->app->isProduction());
}
where I've only added the third line, and it's copied directly from the above how-to, and also appears in a couple other contexts... but when I try to compile the app, I get
#23 10.45 Generating optimized autoload files
#23 12.89 > Illuminate\Foundation\ComposerScripts::postAutoloadDump
#23 12.91 > #php artisan package:discover --ansi
#23 13.08 [2023-01-24 14:27:57] production.ERROR: SQLSTATE[08006] [7] could not translate host name "postgres" to address: Name or service not known (SQL: select * from "applications" limit 1)
#23 13.11 [2023-01-24 14:27:57] production.ERROR: [0] "Cannot instantiate abstract class Illuminate\Database\Eloquent\Model" on line 59 of file /app/app/Providers/AppServiceProvider.php
#23 13.11
#23 13.11 Error
#23 13.11
#23 13.11 Cannot instantiate abstract class Illuminate\Database\Eloquent\Model
#23 13.11
#23 13.11 at vendor/laravel/framework/src/Illuminate/Database/Eloquent/Model.php:2144
#23 13.12 2140▕ * #return mixed
#23 13.12 2141▕ */
#23 13.12 2142▕ public static function __callStatic($method, $parameters)
#23 13.12 2143▕ {
#23 13.12 ➜ 2144▕ return (new static)->$method(...$parameters);
#23 13.12 2145▕ }
#23 13.12 2146▕
#23 13.12 2147▕ /**
#23 13.12 2148▕ * Convert the model to its string representation.
#23 13.12
#23 13.12 1 app/Providers/AppServiceProvider.php:59
#23 13.12 Illuminate\Database\Eloquent\Model::__callStatic()
#23 13.12
#23 13.12 +7 vendor frames
#23 13.12 9 [internal]:0
#23 13.12 Illuminate\Foundation\Application::Illuminate\Foundation\{closure}()
#23 13.14 Script #php artisan package:discover --ansi handling the post-autoload-dump event returned with error code 1
I am using Postgres, and I can successfully compile the app if I copy out that one additional command in boot: Model::preventSilentlyDiscardingAttributes(! $this->app->isProduction());. Compilation in both cases is via Docker, and the crashing is at RUN composer install. Here's a trimmed version of the Dockerfile so folks can check version numbers, etc:
FROM ubuntu:focal as build
ENV DEBIAN_FRONTEND=noninteractive
RUN apt-get update \
&& apt-get install -y software-properties-common \
&& add-apt-repository -y ppa:ondrej/php \
&& apt-get install -y php8.1-fpm php8.1-cli php8.1-curl \
php8.1-mbstring php8.1-xml php8.1-pgsql php8.1-intl php8.1-zip php8.1-gd \
php8.1-gmagick php8.1-dev php-pear \
libpq-dev libevent-dev libssl-dev netcat unzip \
&& curl -sS https://getcomposer.org/installer | php -- --install-dir=/usr/local/bin --filename=composer \
&& printf "\n" | pecl install event
WORKDIR /app
< a bunch of COPY commands; trimmed for space >
RUN composer install
# --ignore-platform-reqs \
# --no-interaction \
# --no-plugins \
# --no-scripts \
# --prefer-dist
I don't know why those options are commented out, but might be able to find out. I included them here in case everyone assumes that I had one of them or some other option present. The options are the same - and commented out - both with and without the crash. The only change is the presence / absence of the Model::preventSilentlyDiscardingAttributes line in AppServiceProvider.php
Also, one of the comments asked about the docker-compose.yml. There is such a file, but I need to build the image before I can "compose" multiple images together. The other images referenced in the docker-compose are not running either when I have this line enabled or disabled.
Another of the comments got me looking into Composer Scripts and after skimming that page, I looked in my composer.json. That contains a scripts section:
"scripts": {
"post-autoload-dump": [
"Illuminate\\Foundation\\ComposerScripts::postAutoloadDump",
"#php artisan package:discover --ansi"
],
"post-root-package-install": [
"#php -r \"file_exists('.env') || copy('.env.example', '.env');\""
],
"post-create-project-cmd": [
"#php artisan key:generate --ansi"
]
},
I don't know if that's causing the problem, but "#php artisan package:discover --ansi" does appear at the end of the previously-quoted traceback.
To provide a bit more detail about the field "data_source" whose odd behavior started me down this path: The comment block just before the model class definition includes the line * #property mixed $data_source. Values assigned to the field in code always use constants defined on the class, and those constants are always integers. It is intended to act as a short enum type, there are three values (other than null): 1, 2, and 3. There is also a class-constant array which maps two of those three integers to strings, but use of that array during read & save is inconsistent, and grep for the map's name doesn't reveal anything that looks to me like automatic type-casting. If I view records from the DB in pgAdmin, it shows the column data type as "character varying (10)". All records in the DB have NULL values in that column. Some of the code that saves/updates records specifically set the column; some does not. So I'm adding log messages to try to figure out which pieces of code are actually involved.
Thank you for your attention and your help.