# 忽略“可用升级”通知导致 422 错误
**URL:** https://meta.discourse.org/t/dismissing-upgrade-available-notifications-leads-to-422-errors/392248
**Category:** Bug
**Tags:** dashboard-reports
**Created:** [2025年十二月27日 19:37 UTC](https://meta.discourse.org/t/dismissing-upgrade-available-notifications-leads-to-422-errors/392248 "2025-12-27T19:37:47Z")
**Posts on this page:** 1
**Showing post:** 3
### Author:  [@zogstrip](https://meta.discourse.org/u/zogstrip)
#### Post date: [2025年十二月27日 23:00 UTC](https://meta.discourse.org/t/dismissing-upgrade-available-notifications-leads-to-422-errors/392248/3 "2025-12-27T23:00:39Z")
抱歉，@RBoy，我们需要对 [DEV: 移除销毁问题检查跟踪器时的管理员通知](https://github.com/discourse/discourse/pull/35976) 进行一些后续跟进
>
>
> When dismissing an admin notice, the service would look up the associated \`Probl…emCheckTracker\` by identifier only. This could find a tracker with a \`NULL\` target, which then fails validation on update since target is now required (as of 8ca5fb706a).
>
> The root issue is that \`problem\_check\_trackers.target\` was added with \`null: true\` and while we later added a default value of \`"\_\_NULL\_\_"\` and a Ruby validation, we never enforced \`NOT NULL\` at the database level. This allowed records with \`NULL\` targets to persist or be recreated through code paths that explicitly passed nil.
>
> This commit:
>
> \- Updates the dismiss service to look up trackers by both identifier AND target (extracted from the admin notice's details)
> \- Removes any remaining records with \`NULL\` targets
> \- Adds a \`NOT NULL\` constraint to prevent this from recurring
>
> Ref - https://meta.discourse.org/t/392248
---
_[View the full topic](https://meta.discourse.org/t/dismissing-upgrade-available-notifications-leads-to-422-errors/392248)._