Child Item

Issue while deleting account

Hi Team,

We are facing an issue while deleting the account having special characters.

Ex: User having with below details

Email=Newone@sail.com
given_name=automation123456##$
surname=$automation123456##$
external_id=“$automation123456##$

When I am trying to delete this user via API, its taking more time than normal user.

Because of which I am receiving {“error”: “Internal Server Error”} Exception. But the user is deleted in the dropbox. And this response is kind of misleading. Also for normal user delete it takes more time than usual for API to respond. This happens only in case of delete operation.

It’s been happening last 2 months intermittently (But more frequently). Could you please check.

Regards,

Nita

Find more posts tagged with

API

Abuse

Accepted answers

Greg-DB

This should be fixed now. Please try again and let me know if you're still seeing the issue. Thanks!

All comments

Greg-DB

I'll be happy to help with any issues you're having with the Dropbox API, but I'll need some more information. Please reply with:

the name and version number of the platform and SDK/library you are using, if any
the steps to reproduce the issue, including relevant code snippet(s)
the full text of any error or unexpected output, including response headers, if possible

Traye1

We are using dropbox REST API v2 version. We hit below endpoint to remove a member.

https://api.dropboxapi.com/2/team/members/remove

Error received - Error Code: 504 Internal Server Error

Also some times it takes ages to get the response back after hitting above endpoint.

This happenes only when we remove the member from the team.

Also on the dropbox system if we remove the member, it takes lot of time to execute the request.

Greg-DB

Thanks for the information. It sounds like something during the processing of removing the member is taking a long time on the Dropbox server, and eventually timing out server-side. Would you be able to share the response headers though? In particular, a few sample 'X-Dropbox-Request-Id' values would be helpful in tracking this down on our side.

Traye1

Hi Greg,

Not sure if i can provide you the response header, reason is we execute the endpoint from our automation application and how to get response header needs to be checked. If it helps here's the accesstoken with which we execute the request - <REDACTED>

I will check into response header, meanwhile please let us know if any other information is required

Greg-DB

@Traye1 I've redacted it from your post, but for future reference, please do not post or share your access token, for your security.

Anyway, the specific request IDs would be ideal, but I'll try to look this up without them. I'll let you know when I have an update on this.

Traye1

Hi,

Here is the error code we receive when we get the internal server error.

Please check below http logs from the application. It contains all the response information from dropbox. Hilighted few important things.

2020-05-25T17:54:10,956 DEBUG QuartzScheduler_Worker-2 org.apache.http.wire:86 - http-outgoing-88 >> "{"user":{".tag":"team_member_id","team_member_id":"dbmid:AADMmv12iyHKb_Ou3xqgNiT8BNII-ks90-Q"}}"
2020-05-25T17:55:41,133 DEBUG QuartzScheduler_Worker-2 org.apache.http.wire:72 - http-outgoing-88 << "HTTP/1.1 504 Gateway Time-out[\r][\n]"
2020-05-25T17:55:41,134 DEBUG QuartzScheduler_Worker-2 org.apache.http.wire:72 - http-outgoing-88 << "Server: nginx[\r][\n]"
2020-05-25T17:55:41,134 DEBUG QuartzScheduler_Worker-2 org.apache.http.wire:72 - http-outgoing-88 << "Date: Mon, 25 May 2020 12:25:41 GMT[\r][\n]"
2020-05-25T17:55:41,135 DEBUG QuartzScheduler_Worker-2 org.apache.http.wire:72 - http-outgoing-88 << "Content-Type: text/html[\r][\n]"
2020-05-25T17:55:41,135 DEBUG QuartzScheduler_Worker-2 org.apache.http.wire:72 - http-outgoing-88 << "Content-Length: 35[\r][\n]"
2020-05-25T17:55:41,135 DEBUG QuartzScheduler_Worker-2 org.apache.http.wire:72 - http-outgoing-88 << "Connection: keep-alive[\r][\n]"
2020-05-25T17:55:41,135 DEBUG QuartzScheduler_Worker-2 org.apache.http.wire:72 - http-outgoing-88 << "ETag: "5ec45a27-23"[\r][\n]"
2020-05-25T17:55:41,135 DEBUG QuartzScheduler_Worker-2 org.apache.http.wire:72 - http-outgoing-88 << "X-Dropbox-Request-Id: 99e1ac96d0cb13647e99d96cd27f6cb5[\r][\n]"
2020-05-25T17:55:41,136 DEBUG QuartzScheduler_Worker-2 org.apache.http.wire:72 - http-outgoing-88 << "X-Frame-Options: DENY[\r][\n]"
2020-05-25T17:55:41,136 DEBUG QuartzScheduler_Worker-2 org.apache.http.wire:72 - http-outgoing-88 << "Content-Security-Policy: sandbox; frame-ancestors 'none'[\r][\n]"
2020-05-25T17:55:41,136 DEBUG QuartzScheduler_Worker-2 org.apache.http.wire:72 - http-outgoing-88 << "X-Content-Type-Options: nosniff[\r][\n]"
2020-05-25T17:55:41,136 DEBUG QuartzScheduler_Worker-2 org.apache.http.wire:72 - http-outgoing-88 << "Content-Disposition: attachment; filename='error'[\r][\n]"
2020-05-25T17:55:41,136 DEBUG QuartzScheduler_Worker-2 org.apache.http.wire:72 - http-outgoing-88 << "[\r][\n]"
2020-05-25T17:55:41,136 DEBUG QuartzScheduler_Worker-2 org.apache.http.wire:72 - http-outgoing-88 << "{"error": "Internal Server Error"}[\n]"

Greg-DB

Thanks! We're looking into it. I'll follow up here once I have an update on this.

Traye1

Hi Greg,

Do we have any update on this? We are still facing this issue consistently.

Greg-DB

@Traye1 This is still open with engineering, but I don't have an update on it yet. I'll follow up here once I do.

Traye1

Hi Greg,

Is there any way we can increase the priority of this issue? We are facing this for more than a month now and would like it to be resolved.

Greg-DB

@Traye1 I'll check in with engineering and request they increase the priority.

Greg-DB

This should be fixed now. Please try again and let me know if you're still seeing the issue. Thanks!