Persist a PATCH to the partnerships file for the XML store

[JakeHuneau]

A PATCH against the XML partnership store reports success but never writes the file, so the change is lost.

Cause

ApiResource.processRequest stores the partnerships XML after a successful change, but the trigger only lists two of the three actions:

if (CommandResult.TYPE_OK.equals(output.getType()) && resource.startsWith("partner")
        && ("add".equals(action) || "delete".equals(action))) {

The PATCH endpoint added in 4.12.0 runs the update command, which is not in that list. For the XML store an update therefore only changes the in-memory document. The caller is told the update succeeded, then the change is lost on restart and silently reverted by the next partnerships refresh.

The database store is unaffected: it persists each change in its own transaction.

Fix

Add update to the trigger. This is correct for both stores, because StorePartnershipsCommand already recognises the database store and returns "The database partnership store persists changes immediately so there is nothing to do", so only the XML store changes behaviour. A failed update still does not store, since the trigger requires an OK result.

Testing

176 tests pass, 3 new in PatchApiTest, which exercises the XML store over real HTTP. Reverting the one line fails the first two.

• patchIsPersistedToThePartnershipsFileNotJustMemory patches a partner then reads partnerships.xml back off disk and requires the new value to be there
• patchReportsThatItStoredThePartnerships requires the response to report the store, as it does for add and delete
• aFailedPatchDoesNotRewriteThePartnershipsFile requires a rejected update to leave the file byte identical

One consequence worth noting: storePartnership writes a numbered backup before each save, so a script that patches many partners in sequence now leaves one backup per call. That was already true for add and delete.

[uhurusurfa]

👍