Only report missing-def store errors after a manifest refresh#11805
Merged
Conversation
Contributor
|
Hmm that's new behavior, right? Before they would be in the manifest but be classified? |
Contributor
Author
|
nope you are right i see what they did tho, let me fix this up with more context |
766b5b5 to
13c8bb0
Compare
13c8bb0 to
45b902b
Compare
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
45b902b to
b5677eb
Compare
bhollis
approved these changes
Jun 18, 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.
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