I don't know why updating into an empty work area would cause a problem reading metadata (which is what the message says).

Perhaps the Clear the contents of the workspace option may not be clearing the workspace properly (an "All Jenkins Logs" file may have information on why that is) which might be because some process is locking some files from being deleted. This could then be leaving behind some corrupt metadata? The "locked file" theory is strengthened by the fact that a restart of the instance (assuming that this is a single host master-based build rather than a slave-based configuration) resets the issue.

One workaround may be to try the Use slave based checkout option in the Advanced settings for Dimensions Plugin. This will do the update using dmcli, rather than the Java API, which run in a new process that ends, so even if it holds open any files, they should be released when dmcli exits. This will need dmcli to be installed and runnable on the machine(s) where the Jenkins workspace is located (Jenkins server if single host installation of Jenkins).

Version 0.8.13 includes additional logging that may help resolve problems with locating 'dmcli' when Use slave based checkout, and diagnose why the original problem occurred. This additional logging appears in the Jenkins System Log.

Using dmcli works around the issue, but never received diagnostics that helped to understand what was happening in the reporter's environment. Please re-open if new diagnostics (from 0.8.13 or later) can be provided.