***
If you're not sure this is actually a bug, instead post about it at https://discuss.kde.org

If you're reporting a crash, attach a backtrace with debug symbols; see https://community.kde.org/Guidelines_and_HOWTOs/Debugging/How_to_create_useful_crash_reports
***

SUMMARY
I usually upload thousands of images in Flickr platform and I often leave the PC uploading them during the night. The next morning, i wake up and the upload was not completed due to one of these errors (not always).
The failure reason is often "105: Service currently unavailable" or "106: Write operation failed". 
As It says here: https://www.flickr.com/services/api/upload.api.html , these are temporary issues that in my opinion can be handle using a retry mechanism.
Digikam Flickr plugin does not implement a retry mechanism for these scenarios. The retry mechanism should periodically retry the upload endpoint until the maximum retries is reached ( maybe a back off mechanism can be implemented)


STEPS TO REPRODUCE
1. try to implement a lot of images

OBSERVED RESULT
The upload stops with an error message "Service currently unavailable".

EXPECTED RESULT
The upload  does not stop and retries the endpoint call after a certain amount of time.

SOFTWARE/OS VERSIONS
Linux:  Manjaro/Xfce 4.18
(available in About System)
Digikam: 8.3.0-5

ADDITIONAL INFORMATION
I've read the code and this is how it works from my understanding:

- upload url post call using O1Requestor object: https://invent.kde.org/graphics/kipi-plugins/-/blob/master/flickr/flickrtalker.cpp?ref_type=heads#L563
- the o1requestor create a request using Qnetworkaccessmanager , adds oauth things and encapsulate the request inside a timer O1TimedReply: https://invent.kde.org/graphics/kipi-plugins/-/blob/master/common/libkipiplugins/o2/src/o1requestor.cpp?ref_type=heads#L27
- the timer O1TimedReply triggers an error signal after receiving a timeout signal from the timer. https://invent.kde.org/graphics/kipi-plugins/-/blob/master/common/libkipiplugins/o2/src/o1timedreply.cpp?ref_type=heads#L19
- This error signal is then handled by https://invent.kde.org/graphics/kipi-plugins/-/blob/master/flickr/flickrtalker.cpp?ref_type=heads#L595 . This method translates the error code into a string that is shown in a messagebox.

If  i understood it, there are two possible solutions:
- The flickrtalker addPhoto function will take the networkreply object from the post and assign the error signal to a local handler ( https://invent.kde.org/graphics/kipi-plugins/-/blob/master/flickr/flickrtalker.cpp?ref_type=heads#L564 ). This local handler will implement the retry mechanism for 105, 106 errors otherwise will call the function "slotError" (https://invent.kde.org/graphics/kipi-plugins/-/blob/master/flickr/flickrtalker.cpp?ref_type=heads#L595). To do this, the timer and the functions needs a flag to disable the default trigger of error signal. 
- The "slotError" handler will implement a retry solution if error code is 105 or 106. In this case, the slotError function and therefore the timer needs to embed the original QNetworkRequest request with the multipart content ( see https://invent.kde.org/graphics/kipi-plugins/-/blob/master/common/libkipiplugins/o2/src/o1requestor.cpp?ref_type=heads#L26 ). In this way, all functions that uses the O1Requestor object will be affected by this solution.

What do you think? 

Thank you for your attention