#7341·OpenRefine

Unable to deserialize changes for column renaming operation

Author: wetnebCreated Jun 14, 2025Updated Aug 13, 2026
LabelsType: Bugpersistenceundo/redo/historyDifficulty: Advanced

This is an analysis of the change loading bug reported on the forum by @robertgarrigos.

The problem is in the serialization of column rename changes, which implicitly assumes that neither the old nor the new column names contain newline characters. When they do, OpenRefine will not be able to reload the change after being restarted, because they look like this:

3.10-SNAPSHOT
com.google.refine.model.changes.ColumnRenameChange
oldColumnName=_ - a
b
newColumnName=new name
/ec/

The change format should be changed so that it can reliably store newline characters. Ideally the deserialization code could be changed not to fail in this example, but the current serialization format is ambiguous (for instance as the old column name could contain \nnewColumnName=…). Those changes should be done in a backwards-compatible way, meaning that changes made with older versions of OpenRefine should still load as well as possible in newer versions. The fact that the first line of the change contains the OpenRefine version could be used to switch deserialization codes accordingly.

To Reproduce

Steps to reproduce the behavior:

  1. First, create a project from the following JSON (to be pasted in the clipboard import tool, and then select JSON as a format):
[ {"a\nb":1, "c": 2} ]
  1. Then, rename the first column (for instance to "new name")
  2. Shut OpenRefine down (not just by closing the browser: also shut the server down)
  3. Restart OpenRefine
  4. Reload the project you just created
  5. Try to undo the renaming operation in the Undo / Redo tab

Current Results

You get a JS alert:

java.lang.RuntimeException: Failed to load change file /home/user/.local/share/openrefine/2342171871129.project/history/1749905084011.change.zip

Expected Behavior

The change should undo

Screenshots

Versions

  • Operating System: any
  • Browser Version: any
  • JRE or JDK Version: any
  • OpenRefine: likely any (the bug seems to have been there from the start)