Transaction sc results fix - #1638
Open
stefangutica wants to merge 4 commits into
Open
stefangutica wants to merge 4 commits into
stefangutica wants to merge 4 commits into
Conversation
|
k6 load testing comparison.
Legend: Avg - Average Response Time, Max - Maximum Response Time, 90 - 90th Percentile, 95 - 95th Percentile |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
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.
Reasoning
timestampMs, even though transactions already do, so consumers that need millisecond precision had nothing to read on the SCRs.timestampMsexisted do not carry the field at all, so it has to be derived fromtimestamp, the same way it is already handled for transactions.timestampand have notimestampMs, and in that case the only remaining sort key wasuuid, which does not reflect the execution order.Proposed Changes
timestampMsto theSmartContractResultentity, so it is exposed on the smart contract results of a transaction.timestampMs, it is derived astimestamp * 1000, mirroring the existing fallback for transactions.nonceas a sort key betweentimestampMsanduuidwhen querying SCRs byoriginalTxHash, so results sharing a timestamp keep their nonce order.How to test
GET /transactions/:txHashreturnstimestampMson every entry ofresults, matchingtimestamp * 1000for transactions indexed before the field existed, and the exact millisecond value for newer ones.timestampand confirm they come back ordered bynonceinstead of byuuid.timestampMsvalues across its SCRs keeps its previous ordering, sincenonceonly breaks ties.