Description:
Suppose there is more than one clone-supporting storage engine and that the clone application failed in the other storage engine due with any error code that has file name and errno attached (e.g. ER_ERROR_ON_WRITE).
The following will happen:
1) the SE clone_apply handlerton method may call my_error, may store the error for later processing, etc, but that will not be enough, because
2) clone_apply will return the error code, say, ER_ERROR_ON_WRITE to the caller
3) The caller is Client::receive_response, and on error it will call Client::handle_error
4) Which will call hton_clone_apply_error
5) Which will will call innodb_clone_apply with e.g. in_err == ER_ERROR_ON_WRITE, but obviously without the rest of the error context such as file name and errno
6) innodb_clone_apply with in_err != 0 will call Clone_Task_Manager::set_error with the right error code but file_name == nullptr
7) Eventually Clone_Task_Manager::handle_error_other_task will be called, which will report that ER_ERROR_ON_WRITE together with file name (which was never set) and errno (which was never set neither, and also see bug 108860), resulting in diagnostics like
ERROR HY000: Error writing file 'Clone File' (errno: 60 - Operation timed out)
where file name is InnoDB placeholder string 'Clone File' and errno is whatever randomly happened to be in the reporting thread.
I know that >1 SE clone is not currently supported, hence S4 severity
How to repeat:
Code analysis
Suggested fix:
Given that clone is multithreaded and the threads need to pass the any errors between them, any SE needs to implement something along the lines of InnoDB Clone_Task_Manager::set_error and handle_error_other_task methods. Moreover, errors need to be synchronized across SEs too. These two points suggest that these methods should be pulled up to the clone plugin layer and be the API that the SE level-clone implementation may call.
