IceWhaleTech/CasaOS · error
%s: %v
Error message
%s: %v
What it means
A Dropbox content/API call returned an error body with a non-zero code that is not 401, and the driver formats the endpoint's summary message plus the detailed Errors slice into '%s: %v'. The 401 branch auto-refreshes the token and retries once; every other code surfaces here.
Source
Thrown at drivers/dropbox/util.go:85
}
if resp != nil {
req.SetResult(resp)
}
var e Error
req.SetError(&e)
res, err := req.Execute(method, url)
if err != nil {
return nil, err
}
if e.Error.Code != 0 {
if e.Error.Code == 401 {
err = d.refreshToken()
if err != nil {
return nil, err
}
return d.request(url, method, callback, resp)
}
return nil, fmt.Errorf("%s: %v", e.Error.Message, e.Error.Errors)
}
return res.Body(), nil
}
func (d *Dropbox) getFiles(path string) ([]File, error) {
res := make([]File, 0)
var resp Files
body := base.Json{
"limit": 2000,
"path": path,
}
_, err := d.request("https://api.dropboxapi.com/2/files/list_folder", http.MethodPost, func(req *resty.Request) {
req.SetBody(body)
}, &resp)
if err != nil {
return nil, err
}View on GitHub (pinned to 0d3b2f444e)
Solutions
- Read the Errors slice in the message — Dropbox includes a structured tag like 'path/conflict/file' that names the exact cause.
- For 409 conflicts: list the destination first and use Move/Rename to overwrite or pick a unique name.
- For permission errors: check the app's permission scopes in the Dropbox App Console and re-grant.
- For 429: retry with the Retry-After delay and reduce request concurrency.
Defensive patterns
Strategy: try-catch
Try / catch
_, err := d.request(url, method, cb, resp)
if err != nil {
msg := err.Error()
switch {
case strings.Contains(msg, "too_many_requests"): // 429: back off and retry
time.Sleep(retryAfter)
return d.request(url, method, cb, resp)
case strings.Contains(msg, "conflict"): // 409: resolve name/target first
return resolveConflictThenRetry()
}
return err // 4xx permanent: fix scope/path, do not loop
} Prevention
- Check destination paths exist (and names are unique) before writes to avoid 409s
- Confirm app scopes include files.content.read/write in the App Console
- Cap concurrent Dropbox calls below rate limits and honor Retry-After
When it happens
Trigger: Any Dropbox request after authentication succeeds but the API rejects the operation: 409 conflict (path/conflict/), 403 (no write permission / rate limited), 400 (malformed path or invalid cursor), 429 too_many_requests.
Common situations: Uploading to a path that already exists with conflict; operating on a file deleted by another client; app permissions missing 'files.content.write'; hitting Dropbox rate limits during bulk syncs.
Related errors
AI-assisted analysis of IceWhaleTech/CasaOS@0d3b2f444e (2026-08-15).
Data as JSON: /api/errors/1305a56d8f6253d7.
Report an issue: GitHub.