[2.x] fix(core): notifications index 400 on invalid default include + n+1#4828
Merged
Conversation
… n+1 Gate the `subject.discussion` default include on whether a subject type actually exposes a `discussion` relationship, instead of on the number of subject types. The old count-based check added an invalid include when the extra types had no such relationship (e.g. a User-subject notification with no Post-subject type present), which the include validator rejected with a 400 for every request, breaking the notifications dropdown and page. Also eager-load the polymorphic subject's `state` / `discussion.state` so the index no longer issues a query per notification for them. Combines #4816 and #4817.
This was referenced Jul 23, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #4815
Combines #4816 and #4817 into a single change, with tests for both.
Fixes
400 on the notifications endpoint.
NotificationResourceaddedsubject.discussionto the default include whenever more than one subject type was registered. That include is only valid when a subject type actually exposes adiscussionrelationship. With subject types like{discussions, users}(neither has adiscussionrelationship) the include validator rejects the endpoint's own default include with:Since the frontend sends no explicit include and relies on the default, this returns a 400 for every request and breaks the notifications dropdown and page. Any forum with a
User- orGroup-subject notification type and noPost-subject type present hits it.The include is now gated on whether a subject type genuinely exposes an includable
discussionrelationship, rather than on the subject-type count.N+1 on the index. The subject's
state/discussion.statewas lazy-loaded once per notification. It's now eager-loaded viamorphWith, so it's a single batched query regardless of how many notifications are in the payload.Notes
subjectTypes()can containnullfor a subject model with no registered API resource; that case is now skipped rather than passed togetResource().Tests
discussionrelationship.subject.discussionis still included when a subject type does have one.Supersedes #4816 (@karl-bullock) and #4817 (@DavideIadeluca); both are closed in favour of this.