AlistGo/alist · error
up.Msg
Error message
up.Msg
What it means
CloudreveV4 local upload chunk got HTTP 200 but the JSON envelope carries a non-zero code; the server's message up.Msg is returned. This is the application-level rejection of an otherwise HTTP-successful chunk PUT on V4.
Source
Thrown at drivers/cloudreve_v4/util.go:305
res, err := base.HttpClient.Do(req)
if err != nil {
return err
}
defer res.Body.Close()
if res.StatusCode != 200 {
return errors.New(res.Status)
}
body, err := io.ReadAll(res.Body)
if err != nil {
return err
}
var up Resp
err = json.Unmarshal(body, &up)
if err != nil {
return err
}
if up.Code != 0 {
return errors.New(up.Msg)
}
return nil
}()
if err == nil {
retryCount = 0
finish += byteSize
up(float64(finish) * 100 / float64(file.GetSize()))
chunk++
} else {
retryCount++
if retryCount > maxRetries {
return fmt.Errorf("upload failed after %d retries due to server errors, error: %s", maxRetries, err)
}
backoff := time.Duration(1<<retryCount) * time.Second
utils.Log.Warnf("[Cloudreve-Remote] server errors while uploading, retrying after %v...", backoff)
time.Sleep(backoff)
}
}View on GitHub (pinned to 843d9dc814)
Solutions
- Start a new upload instead of resuming — server-side session state is the usual culprit.
- Raise the V4 storage policy size/chunk limits if failures cluster at a size boundary.
- Avoid concurrent uploads of the identical file through this driver.
- Correlate with V4 server logs for the precise code/message.
Defensive patterns
Strategy: retry
Try / catch
if err := d.upLocal(...); err != nil {
if strings.Contains(err.Error(), "session") { // up.Msg mentioning session state
return d.upLocal(...) // one clean restart with a new session
}
return err
} Prevention
- Never resume a session you suspect is completed server-side
- Cap parallel uploads of the same file to one
- Correlate up.Code/up.Msg with V4 server logs
When it happens
Trigger: Chunk body unmarshals fine, up.Code != 0. Occurs when the upload session is completed/invalid, chunk index already committed, credential scope mismatch, or policy limits (size/count) exceeded.
Common situations: Retrying after a partial failure where earlier chunks already landed; resuming a finished session; per-policy file size cap hit mid-upload; duplicate uploads racing on the same session.
Related errors
AI-assisted analysis of AlistGo/alist@843d9dc814 (2026-08-15).
Data as JSON: /api/errors/e7dc1fab8403b526.
Report an issue: GitHub.