You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Improve other_operation_in_progress error users, fix handling of its delays (#6588)
`other_operation_in_progress` is reported inconsistently, with some
users only specifying `[class; class_ref]`, and others also `op_type`.
Make it consistent, changing all users to report `[class; class_ref;
op_type; op_ref]`. This makes it much easier to navigate the logs, since
the operation blocking progress is clearly referenced.
Compare before, where it's unclear which operation is precluding
progress:
```
Caught exception while marking SR for VDI.clone in message forwarder:
OTHER_OPERATION_IN_PROGRESS:
[ SR; OpaqueRef:d019f26a-b2e8-529b-bb66-fd4f008d4f82; VDI.clone ]
```
And after, with the ID of the operation present:
```
Caught exception while marking SR for VDI.clone in message forwarder:
OTHER_OPERATION_IN_PROGRESS:
[ SR; OpaqueRef:b0f54a40-485f-f48f-fdc7-6db28a64d3fd;
scan; OpaqueRef:832fb22d-2ce5-0d26-8a00-a4165e78b34d ]
```
In addition, fix incorrect operation reporting, so that when progress is
blocked only when particular types of operations are present in
`current_operations`, these specific operations are reported, and not
just any current operation.
Also fix handling of `other_operation_in_progress` delays - some of the
users would miss the `match` arm and use the non-interruptible
`Thread.sleep` instead of the interruptible `Delay.sleep` that provides
a mechanism for the blocking task to wake us up on its way out.
0 commit comments