JsonApiResource always returning eager-loaded relationships on nested relations

[simon-tma]

Laravel Version

12.58.0 and 13.9.0

PHP Version

8.5.6

Database Driver & Version

No response

Description

JsonApiResource has the includePreviouslyLoadedRelationships() method to always include relationships that have been eager loaded, as well as those listed in include, with the default being to not to.

However, any nested relations that have been eager loaded are always being included if the intermediate relation is included.

Steps To Reproduce

class Post extends Model {
  public function comments(): HasMany { return $this->hasMany(Comment::class); }
}

class Comment extends Model {
  public function author(): BelongsTo { return $this->belongsTo(User::class); }
}

class CommentResource extends JsonApiResource {
  public $relationships = ['author'];
}

class PostResource extends JsonApiResource {
  public $relationships = ['comments'];
}

Router::get('/api/post/{post}', fn (Post $post) => new PostResource($post->load('comments.author));

curl localhost/api/post/1?include=comments

The return includes the author objects, even though not requested.

[prateekbhujel]

I updated #60123 to cover this too. The change keeps nested relationships scoped to the requested include path, so include=comments won't include comments.author just because it was eager loaded. If comments.author is requested, it still gets included.

[Bosun18]

The nested resources in included are resolved with includePreviouslyLoadedRelationships() forced on — that happens in resolveIncludedResourceObjects() in ResolvesJsonApiElements — and in that mode the relationship list comes from array_keys($resource->getRelations()). So whatever is loaded on the related models ends up in the response.

It normally looks right because the level above loads exactly the requested nested paths a few lines earlier, with $relatedModels->loadMissing($request->sparseIncluded($relationName)), so "loaded" and "requested" happen to be the same thing. Handing the resource a model you eager loaded yourself, like the $post->load('comments.author') in your example, breaks that assumption and the authors come along with the comments.

Dropping the forced flag doesn't work on its own: a nested resource has no way to ask the request about its own level, since sparseIncluded() is grouped by the first path segment only. CommentResource would go looking for a comments relationship on itself and find nothing, so nested includes would stop working entirely. What worked for me was carrying the remaining include path down the tree — each entry in loadedRelationshipsMap keeps the paths that still apply to it, and the nested resource is limited to those instead of to everything loaded. 63 lines added and 12 removed in that one file, and the existing tests stay green.

One of them had to move though. testItHandlesBidirectionalRelationshipsWithChaperoneWithoutInfiniteLoop asks for ?include=chaperonePosts and expects the author that chaperone() sets on each post to show up in included — that is the same leak, just from the inverse side. I pointed it at a route that opts into includePreviouslyLoadedRelationships(), where the traversal really is unbounded, and left every assertion as it was. Checked that it still exercises the cycle guard: with the WeakMap check commented out it hangs, 180 seconds without a single test finishing, against 0.34 s normally.

One thing I'm not sure about: with the request-driven path now bounded by the include paths, I don't think an unbounded cycle is reachable there at all any more, so the guard only matters in the opt-in mode. That may or may not be worth writing down somewhere.

Put it up as #61202 in case the direction is useful.