Despite recent improvements in error handling for
GPII-44 etc., it is still highly possible for the end-user installation of the GPII to move the system to an unfamiliar and possibly unusable configuration and leave it there. There is no recourse but for the user to manually discover in the OS UI all of the undesirable settings and reset them, which is entirely unacceptable. I encountered this problem, for example, when trying to review pull requests for GPII-87 - due to not merging in work for a particular case for one SettingsHandler, its operation crashed the request partway through login, leaving the system in a configuration that I couldn't revert even through trying to invent "fictitious preferences sets" designed to cancel the original set. I had to spent half an hour hunting through unfamiliar OS settings in its UI until I could discover where all these were set and revert them.
This problem occurs because we have no robust system for tracking the actions of settings handlers - an error that occurs during request processing for one settings handler will abort the entire request, and usually cause the system to fail to make records of how to undo the effect of the settings handlers activated so far on user logout.
I propose that this issue is handled by maintaining a "settings journal file". This will probably be a file held in the local filesystem which contains a set of JSON records separated by a separator string invalid to appear in JSON (e.g. "'"'"). This file will be opened in "appendable" mode and will be synchronously appended, immediately after the action of any settings handler and before the system proceeds to ANY other activity, a JSON record (plus separator) holding an "undo record" which can be interpreted to cancel the effect of the settings handler.
The journal will be interpreted in two ways - firstly, when reaching user logout, the journal, rather than the current in-memory record, will be considered authoritative in terms of what settings activities are to be undone. Should the logout proceed successfully, the file will be removed.
Secondly, if the system crashes, when the system on its next startup discovers a remaining journal file, it will work through it trying to undo its effects immediately, before any other activity (including starting the GPII server). Again, should this proceed successfully, the file should be removed.
It seems that this file should simply be held in the filesystem in a "suitable location", perhaps in the "temp" space of the system. Whilst the system is running, the file should be kept open in order to prevent the file from being deleted. The system on startup should attempt to determine whether this file is indeed writeable, and refuse to proceed any further if it is not.