Need to see if your shared folder is taking up space on your dropbox 👨💻? Find out how to check here.
Forum Discussion
409 - Internal Error
I am having an intermittent issue with checking the status of async share jobs. Below is the flow I'm building and below that an real error being returned by the API. This is for an internal Dropbox ...
Thanks for responding Greg. This is interesting. From my logs it isn't the share_folder call that is erroring but `add_folder_member`. So it appears that checking the status of async jobs sometimes fails.
Does your recommendation change with this clarification? Or would you still isolate "shares" to 10 seconds apart?
Greg-DB
Dropbox Community Moderator
Dropbox Community ModeratorApologies, I'm not sure I follow. In your original message, the error output you shared appears to be from the response to a call to /2/sharing/check_share_job_status (for checking the job started by calling /2/sharing/share_folder). In your latest message though, you just said you're getting an error from /2/sharing/add_folder_member.
Was that a typo, or are you also getting errors from /2/sharing/add_folder_member? If it's the latter please share a sample of that. Thanks!
Yes, apologies on that copy/paste fail :( The main API call that fails is `check_share_job_status`. It will succeed a few times returned back that it is "in_progress" and then on the 3rd or 4th or 5th call it will return "internal_error".
What I was curious about was when to do the "waiting". If I am reading your feedback correctly, the following is being suggested:
1) Share folder
2) Check share status (waiting 5 seconds per loop)
3) On success, add member
4) Wait 10 seconds before calling the `share` endpoint for the next folder.
Is this what you meant? Or were you suggesting that I increase the 5 second wait time when polling `check_share_job_status` to 10 seconds?- Greg-DB
No problem, thanks for confirming.
Anyway, yes, I meant adding a new 10 second delay before the next /2/sharing/share_folder call.
Thanks Greg. I implemented and tested this change. So far it appears to have reduced the number of times we get the `internal_error`, but it has not eliminated it. Is there anything else you can think of to help make this api flow more reliable?
About Dropbox API Support & Feedback
Find help with the Dropbox API from other developers.
