Codecov Report

Attention: Patch coverage is 75.00000% with 4 lines in your changes missing coverage. Please review.

Project coverage is 68.79%. Comparing base (7749424) to head (cb386f1).

@@             Coverage Diff             @@
##           develop    #1550      +/-   ##
===========================================
+ Coverage    68.74%   68.79%   +0.05%     
===========================================
  Files          239      239              
  Lines         9672     9676       +4     
  Branches      5369     5371       +2     
===========================================
+ Hits          6649     6657       +8     
+ Misses        1629     1622       -7     
- Partials      1394     1397       +3     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

1 mint and burn happen in the same ledger , wrong data write to nf_tokens and uri tables.

IMO it should not matter. A NFT that was minted and burned in the ledger could be regarded as "non-existent".

2 accept nft offer and burn happen in the same ledger, the isburn maybe incorrect.

How would it be incorrect? the data from the burn will have the correct owner and isBurn.

(I haven't looked at the code yet)

How would it be incorrect? the data from the burn will have the correct owner and isBurn.

As the test code shows, https://godbolt.org/z/jP384P7rb, the sorted result is not what we expected.
The 1:1 is sorted after 1:2 sometimes. So the burn tx actually can get erased, so only the nftDatas from accept offer tx gets stored in DB.

IMO it should not matter. A NFT that was minted and burned in the ledger could be regarded as "non-existent".

Again, the sorted result is not expected. So the nftDatas from burn tx might get removed.

std::sort requires a comparison with strict weak ordering and A<B, B<C, C<A violates that.

This violation incurs undefined behavior, and in practice, results in some of the worst kinds of undefined behavior.

I agreed the token minted and burned in the same ledger should be considered as "non-existent", however, current implementation will save the data into the DB , right? Maybe this is another bug we shall fix.