Database backups to dropbox path/conflict/file

    Hi,


    On multiple projects the following issue has occured with enough time (about a year running perfectly fine or so).


    Suddenly I get an error like this:

    Code
    1. PHP Fatal error: Uncaught GuzzleHttp\Exception\ClientException: Client error: `POST https://content.dropboxapi.com/2/files/upload` resulted in a `409 path/conflict/file/` response:
    2. {"error_summary": "path/conflict/file/", "error": {".tag": "path", "reason": {".tag": "conflict", "conflict": {".tag": " (truncated...)
    3. in /xxxxx/perch/core/runway/apps/perch_dropbox/vendor/guzzlehttp/guzzle/src/Exception/RequestException.php:113
    4. Stack trace:
    5. #0 /xxxxx/perch/core/runway/apps/perch_dropbox/vendor/guzzlehttp/guzzle/src/Middleware.php(66): GuzzleHttp\Exception\RequestException::create(Object(GuzzleHttp\Psr7\Request), Object(GuzzleHttp\Psr7\Response))
    6. #1 /xxxxx/perch/core/runway/apps/perch_dropbox/vendor/guzzlehttp/promises/src/Promise.php(203): GuzzleHttp\Middleware::GuzzleHttp\{closure}(Object(GuzzleHttp\Psr7\Response))
    7. #2 /xxxxx/perch/core/runway/apps/perch_dropbox/vendor/guzzlehttp/promises/src/Promise.php(156): GuzzleHttp\Promise\Promise::callHandler(1, Object(GuzzleHttp in /xxxxx/perch/core/runway/apps/perch_dropbox/vendor/kunalvarma05/dropbox-php-sdk/src/Dropbox/Http/Clients/DropboxGuzzleHttpClient.php on line 59


    I have yet to find a common reason across the projects, but its been across different hosting environments, and different php versions, (but all newer than 7.0)


    Has anyone come across similar issues, or have any ideas on how to fix it?

    In the backup section logged in it just keeps saying "in progress"

  • drewm

    Approved the thread.

    Thanks for the response, Drew.


    I don't seem to find a way to find an un-truncated version of the error. Even my error logs truncate it.

    Any idea on how to get a hold of that?


    Edit:

    But I can confirm that I find two images with the same name under assets, and that image name corresponds with the last successfull backup. Will try to delete it from the assets, but need to make sure its not used anywhere.

    I believe I found the problem image, as in the last successfully backed up asset. It only took a couple of the sizes of it, but stopped half way through.


    I could not find these assets in the /assets logged in, but I deleted those assets from the server now. Still doesn't work.


    As another weird case here, possibly related, it suddenly managed to get one more image through a couple of days after the first fail, without showing it as a successfull backup in the logged in section. See screenshots.

    Hi again Drew,


    not sure what you mean, to try uploading a new image?

    I have tried that now, and it uploads just fine. But running a new backup still fails.


    I have also deleted the assets i thought to be the problem-images from the server, without luck.


    Would it be helpful to delete some rows in the database too? Not sure if perch believes assets exists that now no longer exist on the server?

    I found the assets that I deleted on the server, and deleted them in the database too. But still no luck running the backup. Might it be that it doesnt nescessarily follow the order i think, and not actually continue with all image-transformation-variants after each other, but rather tried to jump to an entirely other image that made the run fail? I sort of assumed that it would take all the image sizes after each other, but maybe thats a wrong assumption.

    Sort of. Not deleted only, but replaced a file on the server with a highly optimised (manually) resource with the same name. For a specific Google Pagespeed reason.


    Could that possibly cause a backup issue?


    Only deleted assets, and not replaced, has not happened. But I did find a record of an image in assets that I did not find on the server. I hit delete on that asset from perch admin. I do not understand why that existed under assets, but not on the server, and don't know if there are more of this case which could possibly halt the backup. Not fully sure how to detangle the issue. Just starting a new backup will surely work for a while until it halts at the same stop again.


    Any way to just force dropbox to overwrite any possible conflicts, since it seems to be the problem that a resource already exists in the same path?