Errors during init doesn't throw and event for the callback

[jomorr-jkl]

Errors during init doesn't throw and event for the callback

[TOMassey]

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:

• 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, the startUpload 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?

[TOMassey]

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:

• 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, the startUpload 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.....

[TOMassey]

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/[email protected]',
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.

[zfir]

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.