Tencent/WeKnora · error
failed to delete file from OSS: %w
Error message
failed to delete file from OSS: %w
What it means
This error wraps the underlying error returned by the Alibaba Cloud OSS SDK's DeleteObject call inside ossFileService.DeleteFile. It means the delete request failed at the OSS level (network, permissions, missing object, or invalid request). The original SDK error is preserved via %w so callers can errors.As/Is on it.
Source
Thrown at internal/application/service/file/oss.go:332
return err
}
if err := utils.SafeObjectKey(objectName); err != nil {
return fmt.Errorf("invalid file path: %w", err)
}
var client *oss.Client
if bucketName == s.tempBucketName && s.tempClient != nil {
client = s.tempClient
} else {
client = s.client
}
_, err = client.DeleteObject(ctx, &oss.DeleteObjectRequest{
Bucket: oss.Ptr(bucketName),
Key: oss.Ptr(objectName),
})
if err != nil {
return fmt.Errorf("failed to delete file from OSS: %w", err)
}
return nil
}
// GetFileURL returns a presigned download URL for the file.
func (s *ossFileService) GetFileURL(ctx context.Context, filePath string) (string, error) {
bucketName, objectName, err := parseOssFilePath(filePath)
if err != nil {
return "", err
}
if err := utils.SafeObjectKey(objectName); err != nil {
return "", fmt.Errorf("invalid file path: %w", err)
}
// Determine which client to use
var client *oss.Client
if bucketName == s.tempBucketName && s.tempClient != nil {View on GitHub (pinned to 988cbb0330)
Solutions
- Log the wrapped error with errors.Unwrap to see the OSS error code (NoSuchKey, AccessDenied, etc.) and fix the root cause
- Verify the OSS credentials/policy grant DeleteObject on the target bucket
- Check bucketName/objectName resolution (parseOssFilePath) and that the correct client (temp vs main) is used
- Treat deletion of a missing object as idempotent success in the caller if that is acceptable
Example fix
// before
_, err = client.DeleteObject(ctx, &oss.DeleteObjectRequest{Bucket: oss.Ptr(bucketName), Key: oss.Ptr(objectName)})
if err != nil { return fmt.Errorf("failed to delete file from OSS: %w", err) }
// after
_, err = client.DeleteObject(ctx, &oss.DeleteObjectRequest{Bucket: oss.Ptr(bucketName), Key: oss.Ptr(objectName)})
if err != nil {
var apiErr smithy.APIError
if errors.As(err, &apiErr) && apiErr.ErrorCode() == "NoSuchKey" { return nil }
return fmt.Errorf("failed to delete file from OSS: %w", err)
} Defensive patterns
Strategy: try-catch
Validate before calling
var exists bool _, err := svc.GetFileURL(ctx, path) exists = err == nil // optionally pre-check object exists before delete
Type guard
func isNoSuchKey(err error) bool {
var apiErr interface{ ErrorCode() string }
return errors.As(err, &apiErr) && apiErr.ErrorCode() == "NoSuchKey"
} Try / catch
err := svc.DeleteFile(ctx, path)
if err != nil {
var wrapped *fmt.WrapError
if isNoSuchKey(err) { /* treat as deleted */ } else { return fmt.Errorf("delete failed: %w", err) }
} Prevention
- Grant DeleteObject permission to the configured credentials
- Treat NoSuchKey as idempotent success in deletion flows
- Use stable file references produced by Save*, not user-typed paths
- Monitor OSS error codes in logs for permission drift
When it happens
Trigger: Calling DeleteFile with a bucket/object the credentials lack oss:DeleteObject permission for, an objectName that does not exist (or wrong bucket), or network/region/endpoint misconfiguration reaching client.DeleteObject.
Common situations: Rotated or insufficient RAM/STS credentials, temp-bucket vs main-bucket client mixups, objects already deleted by lifecycle rules or concurrent deletes, private-link/VPC endpoint misconfiguration.
Related errors
- failed to write file: %w
- failed to delete file from OBS: %w
- unsafe OSS endpoint: %w
- invalid OSS file path: %s
- bucket %q does not exist
AI-assisted analysis of Tencent/WeKnora@988cbb0330 (2026-09-02).
Data as JSON: /api/errors/d33101d3785049e1.
Report an issue: GitHub.