-
Notifications
You must be signed in to change notification settings - Fork 2.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix: uniq by hash, instead of transaction #2062
Conversation
660b913
to
5edf4b4
Compare
Pull Request Test Coverage Report for Build aa3b38e8-c50b-40de-bc14-3244901e8888
💛 - Coveralls |
5edf4b4
to
c7be577
Compare
[address_bytes, block_number, page_size] | ||
) | ||
defp transaction_hashes_from_token_transfers_sql(address_bytes, %PagingOptions{page_size: page_size} = paging_options) do | ||
query = |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This doesn't need to be changed, but while debugging this issue I cleaned up this query. Might as well use the new more legible version. I will remove this change on request.
c7be577
to
77e8f45
Compare
I can reproduce this issue in stg. I will test this fix with the new wave of updates to stg. |
I hurried with this statement. I didn't find an example on stg. I will see this fix live on Sokol. |
#883
Bug Fixes
when deduplicating transactions, don't compare the entire object, because preloaded associations could have the list objects in a different order. Instead, deduplicate them using their hash.
CHANGELOG.md
with this PRI tried really hard to reproduce this in a test, but the problem is that it is an inconsistent behavior. Postgres chooses the order of the returned rows. I could sort them to ensure that they always come back in the same order, but that is not actually a requirement of the UI, so we would be slowing it down just to be able to test it. I don't mind adding the sort for the sake of the test, just let me know.
I'm pretty positive that this is the problem but I haven't been able to find a local occurrence of this myself so we should test it against the sokol instance that had the original issue reported.