Deterministic xml: Save builds with a stable element order - #10338
Open
rasmuskl wants to merge 1 commit into
Open
Deterministic xml: Save builds with a stable element order#10338rasmuskl wants to merge 1 commit into
rasmuskl wants to merge 1 commit into
Conversation
The XML save path walked several maps with pairs(): calcs/config inputs and placeholders, item slots, saver sections, and the node-id-keyed allocNodes, masterySelections, jewels and hashOverrides in PassiveSpec. Their emission order was hash order, so the same build could save differently between runs. Sort each walk (names ascending, node ids ascending, slots in creation order) so a build always serialises the same way. EncodeURL also walks allocNodes ascending, so the nodeCount < 255 cap drops the same nodes every time. Loaders read all of these back as maps, so this is a pure reordering.
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
1 participant
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.
Description of the problem being solved:
The XML save path walked several maps with pairs(): calcs/config inputs and placeholders, item slots, saver sections, and the node-id-keyed allocNodes, masterySelections, jewels and hashOverrides in PassiveSpec. Their emission order was hash order, so the same build could save differently between runs. Sort each walk (names ascending, node ids ascending, slots in creation order) so a build always serialises the same way.
Steps taken to verify a working solution:
Has been running headless in poe.ninja for about a month.