fix: nft holdings endpoint doesn't return all NFTs #2140
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.
addresses #1843
The problem was v1/tokens/nft/holdings endpoint with include_unacnhored set is querying the nft_custody_unanchored table which only contains records which were once part of unanchored microblocks and not of normal anchored blocks. Since conceptually, when include_unacnhored is set, the result should not be exclusive even slightly. On the contrary, the response should be the superset of the response when include_unacnhored = false. It should show all records in addition to all the anchored records.
This could have been approached in many different ways. One solution is to simply query both nft_custody_unanchored and nft_custody tables when calling this endpoint and keeping one unique copy of each record in a set. Another way is to update the nft_custody_unanchored table both times to act as a superset of records. I went with the second one.
In my opinion, both of them are far from ideal. With first, will all have to access the database multiple times and perform some check for uniqueness. This will increase response time. With second one, this can be avoided but will introduce redundancy that too for temporary data that should not be persisted.
I was thinking about this before too as it was odd to me but after this issue a realization emerges that there should be some changes in the way non-final data is handled. Blockchain-api should not permanently persist temporary data like microblocks and mempool related data. As this data is bound to be changed or become non-existent due to its transient nature. This data creates unnecessary redundancy, storage and performance problems over long-time.
Maybe something like Temporary Tables/Temp Tables in postgres, which can be periodically merged into permanent ones as the data finalizes, is the answer.
Maybe some tables can be restructured like for eg. both the nft_custody tables can be combined into one with either corresponding anchored or unanchored columns set to null and as non-final data materializes or vice-versa the finality of those columns can be inverted.
@zone117x