Stop the partnerships file gaining blank lines on every save

[JakeHuneau]

Storing the partnerships file adds a fresh layer of whitespace to it each time, without bound.

Cause

Two halves that each look fine alone.

loadPartnershipsFile keeps the newlines and indentation between elements as text nodes:

DocumentBuilder parser = factory.newDocumentBuilder();
Document document = parser.parse(inputStream);   // whitespace text nodes retained

storePartnership then asks the serializer to add indentation of its own:

transformer.setOutputProperty(OutputKeys.INDENT, "yes");
transformer.setOutputProperty("{http://xml.apache.org/xslt}indent-amount", "4");

The serializer cannot remove nodes that are already in the document, so it writes the original whitespace plus a new layer. The next load turns that into more text nodes, and it compounds.

Measured against the shipped partnerships.xml

Saves	Lines	Blank lines	Bytes
0	144	10	9,062
1	192	67	9,938
2	254	129	10,900
3	316	191	11,862
4	378	253	12,824

Roughly 60 blank lines and 960 bytes per save. Every change made through the console or the REST API stores the file, and each save is preceded by a numbered backup, so each bloated generation is also kept on disk.

Fix

Discard the layout whitespace when the file is parsed, leaving the serializer as the only thing deciding the layout. Done on load rather than on save so that every write path benefits.

After the fix the same run is stable at 115 lines and 7,928 bytes, byte identical across five saves. A file that has already accumulated blank lines is also tidied the next time it is stored, so an affected deployment repairs itself rather than needing the file cleaned up by hand.

Only text nodes that are entirely whitespace are removed, using //text()[normalize-space(.) = ''], so no value can be affected. Nothing in a partnerships file carries text content in any case as every value is held in an attribute.

Testing

177 tests pass, 4 new. Removing the fix fails two of them.

• repeatedSavesDoNotGrowTheFile requires five consecutive saves to produce a byte identical file
• aFileThatAlreadyAccumulatedBlankLinesIsTidiedOnTheNextSave takes a file damaged the way the bug damages it and requires the next save to clean it
• savingDoesNotChangeAnyElementOrAttribute flattens the document into every element with its sorted attributes and values and requires the lists to be identical across a save, so any change to the data would fail
• theStoredFileIsStillReadableAndIndented checks the output is still well formed and still indented

org.openas2.upgrades.MigratePollingModuleConfig writes its output the same way and has the same defect, but it is run once by hand and its partnerships output is tidied by the first load after this change, so it is left alone.

[uhurusurfa]

🚀