passedValidation() mutations not reflected in validated() / safe() — undocumented behavior

[rgpgf]

Hi.
When using passedValidation() in a FormRequest to mutate request data via $this->merge(), the changes are not reflected in validated() or safe(), but are reflected in only(), input(), and all().

Example:

protected function passedValidation(): void
{
    $this->merge([
        'user_data' => do some stuff,
    ]);
}

After the above runs:

Method	Returns merged data?
$request->validated()	❌ No — returns pre-merge snapshot
$request->safe()	❌ No — returns pre-merge snapshot
$request->only()	✅ Yes — reads live ParameterBag
$request->input()	✅ Yes — reads live ParameterBag
$request->all()	✅ Yes — reads live ParameterBag

validated() and safe() read data directly from the internal $this->validator snapshot, which is captured before passedValidation() is called. $this->merge() only updates the ParameterBag, leaving the validator snapshot untouched.

---

Question:

Is this the intended behavior? If so, what is the recommended way to transform/mutate validated data within a FormRequest so that validated() and safe() return the transformed values?

---

Documentation gap:

The current Laravel documentation for FormRequest and the passedValidation() hook does not mention this inconsistency or any limitation around mutating data that is later accessed via validated() / safe(). Developers can reasonably expect that calling $this->merge() inside passedValidation() would be reflected in all data-access methods, including validated().

A documentation note or in-code docblock clarifying this behavior would prevent confusion.

---

Environment:

• Laravel version: 12
• PHP version: 8.5

[ntm-dev]

hi rgpgf,

Understanding the Behavior of passedValidation() + merge() vs validated() / safe()

TL;DR: This is intentional behavior rooted in how Laravel's Validator captures data.
$this->merge() updates the request's ParameterBag, but validated() and safe() read
from a separate internal array that was captured before passedValidation() ever runs.
The fix depends on your use case — see the options below.

---

Why This Happens: A Step-by-Step Breakdown

When a FormRequest is resolved, two things happen in sequence:

Step 1 — The validator runs and captures its data

Inside validateResolved(), Laravel creates a Validator instance, runs your rules, and upon
success stores the validated field values in an internal array inside the Validator object
itself — accessible via $this->validator->validated(). This is a plain PHP array that lives
completely independently from the request's ParameterBag.

Step 2 — passedValidation() is called

Only after that capture happens does Laravel call passedValidation(). At this point,
$this->merge([...]) updates the ParameterBag (Symfony's $request->request bag) — but
the Validator's internal array from Step 1 is never touched.

This means:

Method	Reads from	Sees merge()?
validated()	Internal array inside $this->validator — captured at Step 1	❌ No
safe()	Wraps $this->validator — captured at Step 1	❌ No
input()	Request ParameterBag — updated at Step 2	✅ Yes
only()	Request ParameterBag — updated at Step 2	✅ Yes
all()	Request ParameterBag — updated at Step 2	✅ Yes

---

Is This Intended?

Yes — but it is an undocumented footgun. The passedValidation() hook was designed for
side effects (e.g. firing events, setting state), not for mutating the validated dataset. Using
$this->merge() inside it and expecting validated() / safe() to reflect those changes is
effectively an anti-pattern given the current architecture.

---

Recommended Solutions

✅ Option 1 — Use prepareForValidation() (best when transform logic doesn't depend on other validated values)

protected function prepareForValidation(): void
{
    $this->merge([
        'user_data' => $this->transformUserData(),
    ]);
}

prepareForValidation() runs before the validator captures data, so the merged value is
present in both the ParameterBag and the validator's internal array — as long as user_data
appears in rules(). This makes validated(), safe(), input(), and all() consistent.

⚠️ Limitation: Not viable if your transform depends on reading another field's validated
result first.

---

✅ Option 2 — Override validated() directly in the FormRequest

public function validated($key = null, $default = null): array
{
    return array_merge(parent::validated(), [
        'user_data' => $this->transformUserData(),
    ]);
}

Clean and self-contained. Every call to validated() returns the transformed data.

⚠️ Note: safe() calls $this->validator->validated() internally, bypassing this
override entirely. If you rely on safe(), this option does not help for that method.

---

✅ Option 3 — Transform explicitly in the controller (most explicit, no surprises)

public function store(MyFormRequest $request): JsonResponse
{
    $data = array_merge($request->validated(), [
        'user_data' => $this->transformUserData($request),
    ]);
}

The clearest data-flow story. The FormRequest handles authorization and validation;
transformation is an explicit step in the controller. Easy to test, easy to reason about.

---

The Documentation Gap

The current Laravel docs for FormRequest and passedValidation() make no mention of this
inconsistency. Developers who reach for passedValidation() as a "post-validation transform
hook" will hit this silently — nothing throws, nothing warns, and input() / all() will
appear to work correctly until they switch to validated().

A note in the passedValidation() docblock — or a callout in the FormRequest documentation —
clarifying that $this->merge() does not propagate to validated() / safe() would prevent
a lot of confusion.