Repository navigation
NFT: get_approved panics with NonExistentToken for nonexistent tokens - #935
Merged
Merged
Conversation
Contributor
Codecov Report✅ All modified and coverable lines are covered by tests. 📢 Thoughts on this report? Let us know! |
brozorec
approved these changes
Oct 9, 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 #934
get_approvednow panics withNonExistentTokenfor token IDs that don't exist (never minted or burned), as its trait docs say. Before this change it returnedNone, the same answer as a live token with no approval.The default
ContractOverrides::get_approvednow checks that the token exists throughSelf::owner_ofbefore reading the approval. It uses the contract type's ownowner_ofrather thanBase::owner_of, because Consecutive doesn't store a per-token owner entry for batch-minted tokens, andBase::owner_ofwould reject them. This is the same patternRoyaltySupportuses (#846). No contract type overridesget_approved, so the change covers Base, Enumerable, Consecutive, NonFungibleVotes and the combined types.The low-level
Base::get_approvedis unchanged, so the internal approval check intransfer_frombehaves as before.Tests added:
#200.#200.None, thenSomeonce approved (the existence check doesn't reject tokens whose owner comes from the batch).PR Checklist
Summary by CodeRabbit
#200.