What causes "init upload failed: %s" in AlistGo/alist?

Re-fetch the upload config/token immediately before init to rule out expiry

init upload failed: %s

Error message

init upload failed: %s

What it means

Returned by initMultipartUpload when the Doubao upload service answered the 'uploadmode=part&phase=init' POST but with a business code other than 2000. It means the upload session could not be created: the error text is the server's message from the UploadResp envelope.

Source

Thrown at drivers/doubao/util.go:677

}

// 初始化分片上传
func (d *Doubao) initMultipartUpload(config *UploadConfig, uploadUrl string, storeInfo StoreInfo) (uploadId string, err error) {
	uploadResp := UploadResp{}

	_, err = d.uploadRequest(uploadUrl, http.MethodPost, storeInfo, func(req *resty.Request) {
		req.SetQueryParams(map[string]string{
			"uploadmode": "part",
			"phase":      "init",
		})
	}, &uploadResp)

	if err != nil {
		return uploadId, err
	}

	if uploadResp.Code != 2000 {
		return uploadId, fmt.Errorf("init upload failed: %s", uploadResp.Message)
	}

	return uploadResp.Data.UploadId, nil
}

// 分片上传实现
func (d *Doubao) uploadPart(config *UploadConfig, uploadUrl, uploadID string, partNumber int64, data []byte, crc32Value string) (resp UploadPart, err error) {
	uploadResp := UploadResp{}
	storeInfo := config.InnerUploadAddress.UploadNodes[0].StoreInfos[0]

	_, err = d.uploadRequest(uploadUrl, http.MethodPost, storeInfo, func(req *resty.Request) {
		req.SetHeaders(map[string]string{
			"Content-Type":        "application/octet-stream",
			"Content-Crc32":       crc32Value,
			"Content-Length":      fmt.Sprintf("%d", len(data)),
			"Content-Disposition": fmt.Sprintf("attachment; filename=%s", url.QueryEscape(storeInfo.StoreURI)),
		})

View on GitHub (pinned to 843d9dc814)

Solutions

Re-fetch the upload config/token immediately before init to rule out expiry
Re-authenticate the Doubao driver to refresh UserId and authorization material
Read the server message string — it usually names the exact business reason (auth, space, mode)
Retry after a short backoff; transient 4xx-ish business codes occur under load
Check for driver updates if Doubao changed the init contract

Defensive patterns

Strategy: retry

Try / catch

if err := d.initMultipartUpload(...); err != nil {
    if strings.Contains(err.Error(), "init upload failed") {
        // re-fetch upload config for a fresh token, then re-init once
        cfg, _ := d.getUploadConfig(...)
        return d.initMultipartUpload(cfg, ...)
    }
    return err
}

Prevention

Fetch upload config immediately before init; don't cache it across long idle periods
Re-login the driver when auth-flavored init failures appear
Log the server Message string — it names the exact business reason

When it happens

Trigger: Initializing a multipart upload where the StoreInfos auth (storeInfo.Auth header) is invalid/expired, the upload proxy URL from InnerUploadAddress is wrong or expired, upload of this file mode is disallowed for the account, or the server rejects the init parameters (bad SpaceName, ApplyId mismatch).

Common situations: UploadToken fetched at upload_config stage went stale before init ran, account lacks permission for the target space, the file type isn't allowed in part-upload mode, or Doubao changed init response semantics so Code is no longer 2000 on success.

Related errors

AI-assisted analysis of AlistGo/alist@843d9dc814 (2026-08-15). Data as JSON: /api/errors/6b968b4f0d05320b. Report an issue: GitHub.