cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Announcements
Want to learn some quick and useful tips to make your day easier? Check out how Calvin uses Replay to get feedback from other teams at Dropbox here.

Dropbox API Support & Feedback

Find help with the Dropbox API from other developers.

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

-uploadSessionFinishBatchCheck: - Getting path from errors

-uploadSessionFinishBatchCheck: - Getting path from errors

Keith B.7
Helpful | Level 7

Great, thank you again. I now have most of this working with one thing I still haven't managed:

- If DBFILESUploadSessionFinishBatchResultEntry results in -isFailure, how do I get the path the entry was trying to upload to? If there's a failure, I check the reasons and try re-uploading if possible. But in order to do that, I need the upload path so that I can retrieve information about the local file I was trying to upload and try again.

This isn't a problem with the non-batch methods, because the completion handlers have access to the path or information you passed into the calling methods. And in API 1's -restClient: uploadFromUploadIdFailedWithError: method, you could get the upload path from the "destPath" key of the NSError's userInfo dictionary.

I can't find a way of retrieving this information in API 2's batch checks, however. DBFILESUploadSessionFinishBatchResultEntry only provides failure (DBFILESUploadSessionFinishError) and success (meta-data) objects. The meta-data object isn't available in the case of a failure. And DBFILESUploadSessionFinishError provides no access to the path, nor do any of the properties on it.

Given that the upload path is vital information if a DBFILESUploadSessionFinishBatchResultEntry entry results in failure, I assume there must be some way of retrieving it, so could you please tell me what I'm missing?

i.e.:

 

 

DBRpcTask *checkTask = [self.dropboxClient.filesRoutes uploadSessionFinishBatchCheck:asyncJobId];
[self.dropboxClient.filesRoutes response:^(DBFILESUploadSessionFinishBatchJobStatus *status, DBASYNCPollError *pollError, DBError *dbError){
	if (status)
	{
		if (status.isComplete)
		{
			// Go through results.
			for (DBFILESUploadSessionFinishBatchResultEntry *result in status.complete.entries)
			{
                    		if (result.isSuccess)
                   		{
                        		DBFILESFileMetadata *metaData = result.success;
                        		// Do something (e.g. ensure local date and meta-data date are the same).
                        	}
                    	}
                    	else if (result.isFailure)
                    	{
                        	DBFILESUploadSessionFinishError *error = result.failure;

				// How do I find exactly which file failed to upload? What is the path
				// on Dropbox that did not get uploaded?
                    	}
		}
	}
	else // if (status.isInProgress)
	{
		// Call this method to poll again after a delay.
	}
}
else    // Error!
{
	// Handle errors.
}
}];

(Alternatively, the sessionID associated with the chunked upload would be fine if I could retrieve that from the error, because I could record that against the file I was uploading at the start of the upload and then use it to look up the file on failure. Basically, I just need some information from the failure error that I can use to look up what exactly has failed.)

Thanks!
Keith

 

P.S. I tried posting this twice as a reply to the other thread about uploading chunks, but each time I submitted, it failed to show up on the forum.

5 Replies 5

Greg-DB
Dropbox Staff

Sorry about the trouble with the forum! I think that got cleared up though, so I went and deleted the duplicates.

 

Anyway, these failure results don't return the session ID or path. (There's some complexity here unfortunately, but we'll consider it a feature request.) Instead, you should use the index of the result in the result list to correlate back to the list sent to FinishBatch.

Keith B.7
Helpful | Level 7

Thanks for retrieving my post!

 

Thanks for the reply, too. I realised that one way I could get a list of the failures was by checking a cached list of what was currently being uploaded against the meta-data for successful uploaded files - everything else being a failure.

 

Using the index is even better, though: so is it always safe to assume that the [(DBFILESUploadSessionFinishBatchJobStatus *)status complete].entries, array will be in the same order as the finish args passed into -uploadSessionFinishBatch:? (I'm used to results like this having no guaranteed order.)

 

Thanks,

Keith

Greg-DB
Dropbox Staff
Yes, the order for that response is guaranteed to match. (I'll make a note to get that clearly documented.)

Keith B.7
Helpful | Level 7

Great, thank you!

Keith B.7
Helpful | Level 7

Unfortunately, it turns out the order doesn't match after all, as explained here:

 

https://www.dropboxforum.com/t5/API-support/Meta-data-unreliable-in/m-p/192288/highlight/false#M8529

 

I've therefore returned to my previous method.

 

Thanks and all the best,
Keith

Need more support?
Who's talking

Top contributors to this post

  • User avatar
    Keith B.7 Helpful | Level 7
  • User avatar
    Greg-DB Dropbox Staff
What do Dropbox user levels mean?