Skip to content

Only report missing-def store errors after a manifest refresh#11805

Merged
delphiactual merged 1 commit into
masterfrom
fix-d2-item-factory-haderrors
Jun 18, 2026
Merged

Only report missing-def store errors after a manifest refresh#11805
delphiactual merged 1 commit into
masterfrom
fix-d2-item-factory-haderrors

Conversation

@delphiactual

@delphiactual delphiactual commented Jun 17, 2026

Copy link
Copy Markdown
Contributor

When an item has no manifest definition, makeItem can't build it and processItems reported "setting store hadErrors" to Sentry. But a missing def almost always just means the user's cached manifest is stale, and flagging hadErrors already kicks off a re-download (in d2-stores) that fixes it on retry - so reporting on the first pass was noise. A player with a stale manifest produced a flood of expected exceptions, each also logging a redundant second hashLookupFailure from the re-lookup.

Thread a reportMissingDefs flag from the store load through buildStores into processItems, set only on the second attempt (attempt === 1) - which is reached only after the manifest has actually been refreshed. So a no-def item is reported only if it's still missing after a fresh manifest, which shouldn't happen since any item a player owns is in Bungie's current manifest. Items that have a definition but still fail to build are reported as before (a real DIM bug), and hadErrors is still set unconditionally so the manifest refresh and tag/note protection are unaffected. Use getOptional to avoid the redundant hashLookupFailure.

Fixes DIM-1YK6

@bhollis

bhollis commented Jun 17, 2026

Copy link
Copy Markdown
Contributor

Hmm that's new behavior, right? Before they would be in the manifest but be classified?

@delphiactual

delphiactual commented Jun 17, 2026

Copy link
Copy Markdown
Contributor Author

nope you are right i see what they did tho, let me fix this up with more context
re: stale manifest

When an item has no manifest definition, makeItem can't build it and processItems reported "setting store hadErrors" to Sentry. But a missing def almost always just means the user's cached manifest is stale, and flagging hadErrors already kicks off a re-download (in d2-stores) that fixes it on retry - so reporting on the first pass was noise. A player with a stale manifest produced a flood of expected exceptions, each also logging a redundant second hashLookupFailure from the re-lookup.

Thread a reportMissingDefs flag from the store load through buildStores into processItems, set only on the second attempt (attempt === 1) - which is reached only after the manifest has actually been refreshed. So a no-def item is reported only if it's still missing after a fresh manifest, which shouldn't happen since any item a player owns is in Bungie's current manifest. Items that have a definition but still fail to build are reported as before (a real DIM bug), and hadErrors is still set unconditionally so the manifest refresh and tag/note protection are unaffected. Use getOptional to avoid the redundant hashLookupFailure.

Fixes DIM-1YK6
@delphiactual delphiactual force-pushed the fix-d2-item-factory-haderrors branch from 45b902b to b5677eb Compare June 17, 2026 16:06
@delphiactual delphiactual changed the title Don't report hadErrors to Sentry for classified items Only report missing-def store errors after a manifest refresh Jun 17, 2026
@delphiactual delphiactual merged commit ca2225e into master Jun 18, 2026
6 of 7 checks passed
@delphiactual delphiactual deleted the fix-d2-item-factory-haderrors branch June 18, 2026 18:02
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants