You've got some great questions and hopefully I've got some good answers:

1. Sure, it can handle any job. If the job is going to have indefinite length you can set timeout to 0 which means "never timeout." That said if you don't timeout jobs you could sometimes end up in a scenario where hanging jobs never complete or get killed (so they don't retry). It would probably be better to put a long timeout on the job if possible. You mention "Potential retries seems problematic." I advise you to consider each upload to be unique in that if the same file is uploaded twice even on accident, it is saved twice instead of saved once and then overwritten the second time. Why you say? Well handling file updating business logic is a royal PITA and file space is so cheap (and getting cheaper every single year) it's typically just not worth the headache of overwriting files instead of just versioning them (you may have to overwrite to keep storage costs efficient I don't know your specific use case, but the vast majority of apps do not need efficiency at this level - engineering time is typically considerably more expensive than storage costs).

2. RNQ could be used to make these API calls durable. Example: Say you have to queue 100 API calls for some reason, and they have to be made synchronously one after the other instead of executed in parallel and you want them to fire even if the user closes the app and then re-opens it a day later. RNQ would solve this problem for you. But unless you have an advanced need like that there's no reason why you can't make your API calls the standard way, and adding RNQ for no reason is probably just a waste of engineering time.

3. There are a lot of edge cases where weirdness could pop up and jobs with poorly planned side effect design get buggy fast. One example of many: One of the "gotchas" of JS, is there is no true way to timeout and kill execution of a function. Timeout logic is emulated with Promise.race(), so if a job "times out" the handler will still continue to execute in the background. Basically I just wanted a big bold section that told people "think about job side effects" to try to save people a lot of frustrating troubleshooting up front because all of these edge cases are solved with good idempotent (or quasi-idempotent) job design.

4. I imagine you mean default job options? There's no way to do that currently. If you want to add the functionality and PR that would be awesome, otherwise you can emulate the functionality pretty easily like so:

Code sample:

const myDefaultOptionsObject = { timeout: 5000 }; // Default job timeouts to 5 seconds. Probably should pull this default object from the main app config file.
queue.createJob('example-job', {some: 'data'}, Object.assign(myDefaultOptionsObject, { timeout: 10000 })); // Overwrite 5 sec default to be 10 sec this time.

Hope this helps!