Open jomorr-jkl opened 1 year ago
I'm echoing this issue.
I've placed "console.log('hitting startUpload', payload);
" 1 line before the startUpload
call, and "console.log('hitting inside event')
" in the first line of the event
function of FileTransferManager.init
.
The "hitting startUpload" log hits, and the payload looks 100% correct. The "hitting inside event" never fires. No console errors. No signs of anything being requested in the Network tab when viewing the app in dev tools.
Worth noting:
filePath
in the payload to anything other than "file:///source/ ..." format, the startUpload
function will break, and the event will fire an error message. startUpload
function--will (obviously) cause an error, which will trigger the event to fire an error message. (And yes, I did do a clean re-install of the plugin after attempting this.)So it appears that the issue is occurring due to using a...correct filePath format?
I'm echoing this issue.
I've placed "
console.log('hitting startUpload', payload);
" 1 line before thestartUpload
call, and "console.log('hitting inside event')
" in the first line of theevent
function ofFileTransferManager.init
.The "hitting startUpload" log hits, and the payload looks 100% correct. The "hitting inside event" never fires. No console errors. No signs of anything being requested in the Network tab when viewing the app in dev tools.
Worth noting:
- The plugin code/script is left untouched, so no changes to FileTransferManager.js
- If I set the value of
filePath
in the payload to anything other than "file:///source/ ..." format, thestartUpload
function will break, and the event will fire an error message.- Trying to tinker with FileTransferManager.js--more specifically, the inner-workings of the
startUpload
function--will (obviously) cause an error, which will trigger the event to fire an error message. (And yes, I did do a clean re-install of the plugin after attempting this.)So it appears that the issue is occurring due to using a...correct filePath format?
One note I forgot to include: my project is a Capacitor project (v.5.5.0). I'm wondering if there's a compatibility issue here.....
I ran an npm update
command for one of my other (working) cordova plugins, in order to see if an "unsupported engine" warning would pop up for the background-upload plugin, and sure enough....
npm WARN EBADENGINE Unsupported engine {
npm WARN EBADENGINE package: '@spoonconsulting/cordova-plugin-background-upload@4.0.10',
npm WARN EBADENGINE required: { cordova: '>=8.0.0', node: '14.x', npm: '6.x' },
npm WARN EBADENGINE current: { node: 'v18.16.1', npm: '9.5.1' }
I'm not super-duper positive that this is the cause of our issue, but right now it's the only lead I've got. Despite the startUpload
function reaching the exec
command (which is a Cordova core function built into Capacitor--makes sense), nothing is happening after that exec
function completes successfully.
Hello @TOMassey,
The warning you have provided in not the problem. This is a Node version update in package.json of the library.
As for the callback error you are encountering, we have not tested on Capacitor yet. We will not work on this soon but it is in our roadmap.
For now, a pull request is most welcome.
If there is an error during init, there is no event thrown so the error can't be caught in the callback.
There is an error accessing the file defined in the payload object, resulting in an error - but there is no way to catch the error so it can be handled.
Even worse is there is no way to purge the upload queue to remove this problem upload, so no new uploads work without uninstalling and reinstalling the app (opened a separate issue for that)