Long-running alters will generate sys_update_xml in the Default update set by the 'guest' user if the session expires before completion. This is a problem because these table-altering changes will not be captured in the correct update set, which will likely go unnoticed by the user. The form and list layout updates will be generated immediately in the user's update set, but the sys_dictionary and sys_documentation records will end up in the Default update set some time later.

Any long-running alter initiated from the UI is susceptible to this issue. It occurs most commonly on the CMDB and Task hierarchies.

When creating a column from the Form/Layout Editor, the alter will be processed on a background thread instead of as a UI transaction, and thus is not susceptible to this issue. Alternatively, if you notice that you are required to log in again after waiting for a column creation/deletion/update to finish, simply check your update set and make sure the change was captured properly. If it was captured in the Default update set by 'guest' instead, make a non-schema-altering change to the record in order to re-capture it in your update set. An example of a non-schema-altering change would be flipping the read-only flag.