route model binding (Variable name cannot be longer than 32 characters in route pattern) about laravel

[ben221199]

Maybe you could do something with debug mode? Performance is less important when debugging locally why something doesn't work.

[ben221199]

Can you show the php artisan route:list?

[matthijs]

Sure, here it is (only the routes related to this problem):

GET|HEAD        api/v1/external-service-provider-activities ....................................................... api.v1.external-service-provider-activities.index › LaravelJsonApi\Laravel › JsonApiController@index
GET|HEAD        api/v1/external-service-provider-activities/{esp_activity} .......................................... api.v1.external-service-provider-activities.show › LaravelJsonApi\Laravel › JsonApiController@show

The index is action is working correctly.

[ben221199]

I think the '\\' . is not neccessary.

Do you also have the schema?

[matthijs]

Ok, nevermind. I found the problem.

In our schema we had a double ID::make() definition like:

    /**
     * Get the resource fields.
     */
    public function fields(): array
    {
        return [
            ID::make()->uuid(),

            Str::make('name')->sortable(),
            Str::make('description')->sortable(),

            ID::make('chain')->sortable(); // causing the trouble...

            DateTime::make('created_at')->sortable()->readOnly(),
            DateTime::make('updated_at')->sortable()->readOnly(),
        ];
    }

The fact that ID::make('chain')->sortable() had no ->uuid() did change the regex for the route pattern to an integer regex. And that caused the 404 not found exception.

Thanks for trying to help out and sorry for the trouble.

Maybe check if there are multiple ID::make() definitions returned and throw an exception in that case? That could help catching this kind of bug earlier...

[ben221199]

Yeah, that makes sense. I had the feeling it had something to do with the ID anyway.

[ben221199]

@lindyhopchris Is this an option in some way?

Maybe check if there are multiple ID::make() definitions returned and throw an exception in that case? That could help catching this kind of bug earlier...

[lindyhopchris]

@lindyhopchris Is this an option in some way?

Maybe check if there are multiple ID::make() definitions returned and throw an exception in that case? That could help catching this kind of bug earlier...

So "checking something" has cost, that you incur every single time the schema is created in a request. Just to catch a mistake a developer has made...

I'll take a look but will only do something if it doesn't add in any extra processing.

[matthijs]

So "checking something" has cost, that you incur every single time the schema is created in a request. Just to catch a mistake a developer has made...

I'll take a look but will only do something if it doesn't add in any extra processing.

I completely agree! For debugging purposes it would be handy if this could be catched but if that has a performance hit in production then please leave it out. Maybe add an extra note to the documentation about this.