Skip to content

[2.x] fix(core): notifications index 400 on invalid default include + n+1#4828

Merged
imorland merged 1 commit into
2.xfrom
im/notifications-index-fix-and-perf
Jul 23, 2026
Merged

[2.x] fix(core): notifications index 400 on invalid default include + n+1#4828
imorland merged 1 commit into
2.xfrom
im/notifications-index-fix-and-perf

Conversation

@imorland

@imorland imorland commented Jul 23, 2026

Copy link
Copy Markdown
Member

Fixes #4815

Combines #4816 and #4817 into a single change, with tests for both.

Fixes

400 on the notifications endpoint. NotificationResource added subject.discussion to the default include whenever more than one subject type was registered. That include is only valid when a subject type actually exposes a discussion relationship. With subject types like {discussions, users} (neither has a discussion relationship) the include validator rejects the endpoint's own default include with:

Invalid include [subject.discussion]

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- or Group-subject notification type and no Post-subject type present hits it.

The include is now gated on whether a subject type genuinely exposes an includable discussion relationship, rather than on the subject-type count.

N+1 on the index. The subject's state / discussion.state was lazy-loaded once per notification. It's now eager-loaded via morphWith, so it's a single batched query regardless of how many notifications are in the payload.

Notes

  • subjectTypes() can contain null for a subject model with no registered API resource; that case is now skipped rather than passed to getResource().

Tests

  • The endpoint no longer 400s when a subject type has no discussion relationship.
  • subject.discussion is still included when a subject type does have one.
  • The subject discussion state is batch-loaded with no per-row query.

Supersedes #4816 (@karl-bullock) and #4817 (@DavideIadeluca); both are closed in favour of this.

… 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.
@imorland
imorland requested a review from a team as a code owner July 23, 2026 18:29
@imorland imorland added this to the 2.0.0-rc.6 milestone Jul 23, 2026
@imorland
imorland merged commit d514596 into 2.x Jul 23, 2026
25 checks passed
@imorland
imorland deleted the im/notifications-index-fix-and-perf branch July 23, 2026 18:42
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[2.x] Notifications endpoint 400s on an invalid subject.discussion default include when a notification subject type has no discussion relationship

1 participant