Cannot fetch job status after 24h

[13W]

No description provided.

[davepacheco]

Thanks for doing this. Can you give a little more information about the change? It looks like you moved some logic from the command-line tools into the library. Was it not working before from the command-line tools, or did you just want it in the library?

Is "path" actually a useful argument for library callers of job(), or is that only intended to be used in the recursive call? If it's actually useful, we should document it with the function. If it's only internal, I'd much prefer to see the function refactored so that users can't specify it themselves.

Thanks again. @mcavage, I remember talking about whether this should be in the SDK vs. only the command-line tool. Do you care about this?

[dan-luk]

Hi Dave,

Can you give a little more information about the change?

The portal is now actively using node-manta, so the change is mostly because of that. If you need more information, see my email.

Is "path" actually a useful argument for library callers of job(), or is that only intended to be used in the recursive call? If it's actually useful, we should document it with the function. If it's only internal, I'd much prefer to see the function refactored so that users can't specify it themselves.

Yes, it's for recursive call. Will be refactored as you advice.

[davepacheco]

It still looks to me like users can specify the "useArchive" flag. My suggestion is that that's either documented or else you modify the code so that they cannot do that (e.g., by having the external-facing function F1 sanitize inputs and then call an internal function F2, and having the recursive call invoke F2 directly). I'm okay with the approach of documenting the flag instead if Mark's on board.

@mcavage, did you want to look at this?

[dan-luk]

Hi Dave,

After thinking more on 'useArchive', Vladimir now wants to give the user ability to use it, so that they can do one call instead of two when using the following methods:

client.job
client.jobInput
client.jobOutput
client.jobFailures
client.jobErrors

So documenting looks more preferable. However, current documentation for these methods just list parameters where 'options' is described like this:

options | Object | (optional) optional overrides for this request

Can you recommend on how to properly document it?

Thanks!

[davepacheco]

A few of the functions support additional named options that are just documented in text above the function. For example client.put() supports "copies", "mkdirs", "size", "md5", and "type". addJobKey() also has an "end" option. jobShare() also documents several options directly under "opts", like "readme", "maxObjects", and so on. Either of these formats is fine. The main reason for the documentation is to better understand why a user would use this flag. I'd suggest adding a note to job(), and then you can just mention it in the other functions you've changed (e.g., "options: see job()").

[dwlf]

@13W & @dan-luk, did @davepacheco answer the question? Were you waiting on a response from @mcavage?

[dan-luk]

no, we have workaround for this in portal and didn't get time to follow Dave's recommendation here.