When users use a normal Dropbox URL for a dump file of pg:backups restore command, it fails with very ambiguous message:
$ heroku pg:backups restore 'https://www.dropbox.com/s/some-random-slug/rose.dump' HEROKU_POSTGRESQL_YELLOW_URL -a sushi
...
r014 ---restore---> HEROKU_POSTGRESQL_YELLOW
An error occurred and your backup did not finish.
Please run `heroku pg:backups info r014` for details.
$ heroku pg:backups info r013 -a sushi
...
=== Backup Logs
2016-05-01 18:42:53 +0000: pg_restore: [archiver] did not find magic string in file header
...
This is because that Dropbox URL actually gives you an HTML file, instead of the actual dump file. You can get the dump file by specifying dl=1 at the end of URL, this PR is checking it and actually append it.
Alternatively, we could just raise the warning instead (that was my initial intention as you can see from the brunch name -- pg:backups command doesn't give you meaningful error messages in general), or we could do something at transferatu or htcat level.
jdx
commented
8 years ago
When users use a normal Dropbox URL for a dump file of
pg:backups restorecommand, it fails with very ambiguous message:This is because that Dropbox URL actually gives you an HTML file, instead of the actual dump file. You can get the dump file by specifying
dl=1at the end of URL, this PR is checking it and actually append it. Alternatively, we could just raise the warning instead (that was my initial intention as you can see from the brunch name -- pg:backups command doesn't give you meaningful error messages in general), or we could do something at transferatu or htcat level.