Eager load constraints on latestOfMany/ofMany not applied to inner subquery

[SachinAgarwal1337]

Description

When eager loading a latestOfMany/ofMany relationship with constraints, the constraints are only applied to the outer query and not to the inner subquery that determines which record is the "latest." This causes silently incorrect results — no error is thrown, but the wrong record is returned.

Steps To Reproduce

Given a User model with a lastPayment relationship:

public function payments(): HasMany
{
    return $this->hasMany(Payment::class, 'payer_id');
}

public function lastPayment(): HasOne
{
    return $this->payments()->one()->latestOfMany();
}

When eager loading with a constraint:

User::with(['lastPayment' => fn ($query) => $query
    ->where('store_id', $storeId)
    ->where('type', 'store_payment')
])->get();

Expected behavior

The constraints should be applied inside the inner subquery so "latest" is determined within the scoped dataset:

SELECT payments.* FROM payments
INNER JOIN (
    SELECT MAX(payments.id) as id_aggregate, payments.payer_id
    FROM payments
    WHERE payments.payer_id IN (...)
      AND store_id = ?           -- ✅ applied here
      AND type = 'store_payment' -- ✅ applied here
    GROUP BY payments.payer_id
) AS latestOfMany ON ...
WHERE payments.deleted_at IS NULL;

Actual behavior

Constraints only on the outer query. The inner subquery picks the latest across all records, then the outer filter discards it:

SELECT payments.* FROM payments
INNER JOIN (
    SELECT MAX(payments.id) as id_aggregate, payments.payer_id
    FROM payments
    WHERE payments.payer_id IN (...)
      -- ❌ no constraints here
    GROUP BY payments.payer_id
) AS latestOfMany ON ...
WHERE store_id = ?               -- only here
  AND type = 'store_payment'     -- only here

This silently returns null for users whose latest payment overall was at a different store — even if they have payments at the target store.

Why This Matters

• Silent data loss: No error, the relationship just returns null or the wrong record
• Unintuitive: with(['relation' => fn($q) => $q->where(...)]) scopes the entire operation for every other relationship type
• Historical context: PR [8.x] Improve one-of-many performance #37451 (Laravel 8.x) specifically moved constraints into the subquery for correctness and performance (212x speedup). Current behavior appears to be a regression from that intent

Workaround

Use ofMany closure to bake constraints at definition time:

return $this->payments()->one()->ofMany(
    ['id' => 'max'],
    fn ($query) => $query->where('store_id', $storeId)->where('type', 'store_payment'),
);

Works but requires a separate relationship per constraint set — no dynamic constraints at eager load time.

Versions

• Laravel: 12.55.1
• PHP: 8.5

[sadique-cws]

Great catch and reproduction steps! This indeed leads to silent data loss since the subquery picks the wrong "latest" record by ignoring the closure constraints, which the outer query then discards.

I've submitted a PR to fix this. It snapshots the query's where constraints before and after the closure is applied during eagerLoadRelation, and propagates the newly added constraints to the inner one-of-many subquery. Now the inner subquery will determine "latest" within the user's filtered scope, as expected.

PR: 12.x...sadique-cws:framework:fix/eager-load-one-of-many-subquery-constraints

[SachinAgarwal1337]

@sadique-cws Thank you so much for the PR 👍

[marius-ciclistu]

Hi. Interesting case. I see this as a grey area. If the relation is HasOne, why filter it? By this logic the current behavior is ok. It hardcodes that latest condition.

On the other hand I see the need for this feature. I gues ofMany was introduced to avoid memory issues. But SQL functions like MAX are slower than a select.. order by .. desc limit 1, leading to timeout on big datasets anyway.

I would load this lastOfMany via another on request call GET /res/{id}/hasMany?condition=3&limit=1&sort[][by]=id

This does not allow a table view display from a single call but it does not generate query timeouts on big datasets. Also it suports composed pks and incrementing = false situations.

[sadique-cws]

Hi @marius-ciclistu, thanks for looking into this!

I disagree that the current behavior is okay, because it results in silent data failure that violates the core expectations of Eloquent eager loading.

To address your thoughts:

1. "If the relation is HasOne, why filter it?"
Because it's not a strict 1:1 database constraint; it's a dynamic HasOne representation of a HasMany dataset. Think about User::with('latestLogin'). If a developer wants to fetch the latest successful login alongside the user, they naturally do:

User::with(['latestLogin' => function ($query) {
    $query->where('status', 'successful');
}])->get();

If the user's absolute latest login happens to be failed, the inner query currently locks onto the failed record. The outer query then applies the status = 'successful' filter, realizes the row doesn't match, and silently returns null for the relationship—even if the user has thousands of prior successful logins.

This defeats the entire purpose of dynamic constraints in with() closures. If a developer provides a filter, the relationship inherently must evaluate the "latest" row that meets that filter, rather than filtering out the arbitrary absolute latest row.

2. "SQL functions like MAX are slower than a select.. order by .. desc limit 1"
The limit 1 approach you mentioned works perfectly when laziness loading a single user's relationship. However, you cannot use limit 1 while eager loading a collection of users (User::with(...)) because limit 1 would restrict the entire fetched dataset to a single row, rather than 1 row per user.

That exact limit 1 per group SQL limitation is the precise reason Taylor and the Laravel team introduced ofMany() and the MAX inner-join subquery in the first place—to solve N+1 eager loading for "latest" aggregations!

Suggesting developers should avoid it by making separate individual requests (GET /res/{id}/hasMany...) completely defeats the core objective of eager loading, which is to eliminate N+1 latency entirely within a single backend context.

Since Laravel explicitly supports providing closure constraints to eager-loaded instances, failing to forward those constraints to the aggregate subquery where the actual calculation takes place is a bug, not an intentional design choice. The fix merely ensures the subquery respects the exact constraints the developer manually requested.

[marius-ciclistu]

@sadique-cws You are right. But the reality kicks in on big datasets and ruins your second point. With first point I can agree.