Proposed solution: switch to using a ReadWriteLock internally within WorkflowRun to ensure thread-safety of access , and find a way to avoid normal synchronization while obtaining the transient Lock object – perhaps initializing it at deserialization-time to ensure we don't need to rely on a synchronized lazily-initializing getter.
This should replace the "copyLogsGuard" synchronization object and general synchronization on the WorkflowRun (except for general synchronization during the save operation).
The catch: we need to verify there are no deadlocks between synchronization on the WorkflowRun and the guard object – we need to ensure synchronization has one consistent order (either run-first or readwriteLock-first).
Synchronization in the Run superclass:
- #delete() – partial
- #doSubmitDescription(StaplerRequest, StaplerResponse)