Rules with numeric keys do not validate properly

[Tofandel]

Laravel Version

10.48.10

PHP Version

8.3

Database Driver & Version

No response

Description

Numeric rules (Eg: [4 => 'required', 8 => 'required']) when added to a validator are not saved properly, they are transformed into[0 => 'required', 1 => 'required'] in the constructor

I tracked it down to this line

framework/src/Illuminate/Validation/Validator.php

Lines 1208 to 1210 in bf7046f

	$this->rules = array_merge_recursive(
	$this->rules, $response->rules
	);

It seems the array merge recursive treats any numeric key differently and just appends it to the array instead of preserving the keys, this is explained in the php doc, but undesirable behavior in this case https://www.php.net/manual/en/function.array-merge-recursive.php

array_merge_recursive([], ['foo' => 'required', 4 => 'required', 8 => 'required']);
= [
    "foo" => "required",
    0 => "required",
    1 => "required",
  ]

Steps To Reproduce

Running the following in a tinker session is enough to reproduce

Validator::validate(['foo' => 'baz', 4 => 'foo', 8 => 'baz'], ['foo' => 'required', 4 => 'required', 8 => 'required']);

Results in

   Illuminate\Validation\ValidationException  The 0 field is required. (and 1 more error).

A possible solution is a different implementation of the array_merge_recursive as seen here https://www.php.net/manual/en/function.array-merge-recursive.php#106985

Prior attempt at a fix #39368

[crynobone]

Since this behavior has been present ever since the beginning I don't think we can change this. Should you want to propose this change I suggest you to attempt a PR to the master branch. Thanks

[Jacobs63]

What is the actual, valid, use-case for this?

This seems very unlikely to be anyhow useful in a real use-case.

[Tofandel]

If I'm reporting it it's because I encountered this bug while coding for one. I'm sending ids as keys in the validator, the ids are basically ids of fields in the db and each field has its own set of rule. The form is dynamic in this way, I don't use the error message, I'm making my own based on the failing rule/field

[Tofandel]

@crynobone thank you for this very insightful copy-paste

But this "behaviour" is an unintended bug of a native php function and it existing forever is not a valid reason to not want to improve the tool/framework we are working on for future use

A validator works on key and there is no reason the key you pass in should ever change

[github-actions]

Thank you for reporting this issue!

As Laravel is an open source project, we rely on the community to help us diagnose and fix issues as it is not possible to research and fix every issue reported to us via GitHub.

If possible, please make a pull request fixing the issue you have described, along with corresponding tests. All pull requests are promptly reviewed by the Laravel team.

Thank you!

[crynobone]

@Tofandel feel free to send a PR to master branch as suggested earlier.

[rodrigopedra]

As a workaround, you can wrap your fields' IDs into the same name key.

Code will explain better:

// routes/web.php
<?php

use Illuminate\Http\Request;
use Illuminate\Support\Facades\Route;

// from DB
$fields = [
    4 => ['label' => 'name', 'rule' => 'required'],
    8 => ['label' => 'surname', 'rule' => 'required'],
];

Route::get('/', fn () => view('form', ['fields' => $fields]));

Route::post('/', function (Request $request) use ($fields) {
    $rules = collect($fields)->mapWithKeys(fn ($field, $id) => [
        'field.' . $id => $field['rule'],
    ]);

    $attributes = collect($fields)->mapWithKeys(fn ($field, $id) => [
        'field.' . $id => $field['label'],
    ]);

    $request->validate($rules->all(), attributes: $attributes->all());

    return back();
});

{{-- resources/views/form.blade.php --}}
<div style="white-space: pre-wrap;">@json($errors->all(), JSON_PRETTY_PRINT)</div>

<form action="/" method="POST">
    @csrf

    @foreach($fields as $id => $field)
        <label for="field-{{ $id }}">{{ $field['label'] }}</label>
        <input type="text" id="field-{{ $id }}" name="field[{{ $id }}]">
        <br>
    @endforeach

    <button type="submit">send</button>
</form>

[Tofandel]

@rodrigopedra Thanks, that's what I did but then the problem is that the path of the field in the error bag doesn't match with the name of the field in Inertia which is yet another workaround needed, very bad DX for a valid use case

[driesvints]

Thanks. This has come up before quite a few times. We decided we won't be changing this behaviour because this could have quite an impact on existing apps, sorry for that. We could maybe make the docs more clear about this so feel free to attempt a PR to the docs.

[Tofandel]

@driesvints

quite an impact on existing app

I would like to see what exactly that could be, because I don't see it at all, and not a single test is failing on #51516. A validator works only on keyed arrays so this would have zero impact on existing apps, it's only fixing a bug that made this use case not possible in the first place (a use case being having those keys simply be numbers as well)

Start of rent

I'm seeing this stance taken increasingly often here and I don't like it. What are major versions anyway if not to have minor changes that will maybe affect one poorly coded app in 1 million? Has laravel just become this unsteerable ship that you can't fix/contribute anything into unless you are a core member of the team (I don't believe it, because there is still a lot of new features and improvements added, but let's not just completely freeze at the idea of fixing a bug in a very used core feature okay)? It has become increasibly difficult to have a positive attitude towards laravel, when we as contributors are always told, sure try a PR to barely have it reviewed and closed straight away after spending a few hours on it, with very little explanations, it's like experimenting with brushing a bear with your eyes closed and legs attached, maybe there is a possibility the bear will like it, but it's much more likely the bear will eat you, when instead there could be a real two-way discussion that would save time for all of us counterintuitievly (because yes there would be less of these repetive PRs/issues coming back up every few months/years), of course I understand Tailor is busy and I don't blame him seeing the amount of PR flowing in and all the ecosystem but I'd prefer a better power dynamic with better triage of PR's than this, it's impossible to get proper feedback

For example labels on PR issues with the likelihood of acceptance, it could even be AI powered because there is already a big dataset of PR issue available.
You are adding yet something to the Arr helper? likelihood zero, bot says: create a package with a macro, and there you have one less PR to review. (Yes this is the most common type of PR here and it's understandably never accepted)
You are fixing a bug in a recent feature? High likelihood: please make sure to add tests now.
You are fixing a bug in legacy code that's now deemed "a feature", very low likelihood: consider a different approach like the same feature with a different name

In any case we need a better tracker for the history of this bugs now deemed unfixable, so people that want to attempt to fix it, now straight away the reason why it cannot be fixed direclty and if they can find an approach that's suitable

But right now with those small bugs that pile up in the legacy code, I need to maintain my own package and boilerplate that entirely rewrites and bind core facades for all of my projects just because of small bugs like this that are consistently and actively refused to be fixed for years that make laravel hazardous to use without a white cane to probe at things. Even though it takes a 3 lines change and a few test cases and it could easily be included in a major if the worry is that it will break something

End of rent

Thanks for reading and here is to hoping for a better future for this framework that I and so many have grown to love ❤️