Retry Batch Qiniu File Upload

Tool Name: airdroid_business_qiniu_file_batch_upload_retry

Risk Level: 🟡 Write

Execution Mode: ⏳ Asynchronous (returns new log IDs)

Category: File Management

Quick Start (Copy & Use)

Summary: Re-dispatch Qiniu upload retry for devices/files that failed under a prior Batch Upload Qiniu Files operation.

Prerequisites: Original OperationLogId, same Bucket as the first upload, Qiniu credentials, failed rows visible in Search File Batch Upload Results.

Success Criteria: StatusCode == 200, empty ErrorMessage, non-empty RetryOperationLogId. A non-empty Hint can still accompany success when some failed devices were skipped because their result rows had no key_prefix.

What to Do Next: Poll Search File Batch Upload Results using RetryOperationLogId (not only the original log).

Minimal Request Example:

{
  "OperationLogId": 1770854462319857000,
  "Bucket": "media-prod"
}

Minimal Response Example:

{
  "RetryOperationLogId": "1770854462319857001",
  "RetriedDeviceCount": 2,
  "SourceOperationLogId": "1770854462319857000",
  "Hint": "",
  "Retryable": false,
  "OriginalStatusCode": 200,
  "StatusCode": 200,
  "ErrorMessage": ""
}

Recipes (Common Recipes)

Recipe 1: Retry After Filtering Failures

When to use: Search showed status: failed for some devices.

1. Search File Batch Upload Results with Filter.status = failed.
2. Retry Batch Qiniu File Upload with original OperationLogId and same Bucket.
3. Search File Batch Upload Results with OperationLogId = RetryOperationLogId.

{
  "OperationLogId": 1770854462319857000,
  "Bucket": "media-prod"
}

Recipe 2: Use the Original Bucket

When to use: The source upload used a known Qiniu bucket.

Supply the same Bucket as the initial Batch Upload Qiniu Files call. The action preflights the supplied Qiniu credentials and bucket before fetching failed upload records.

{
  "OperationLogId": 1770854462319857000,
  "Bucket": "media-prod"
}

Recipe 3: No Failures Left

When to use: Search shows all success.

Check for failed rows with Search File Batch Upload Results:

{
  "OperationLogId": "1770854462319857000",
  "PageIndex": 1,
  "PageSize": 100,
  "Filter": {
    "status": {
      "eq": "failed"
    }
  }
}

If the search returns no failed rows and the batch is terminal, do not call retry; close the workflow. Retry is only for failed/partial batches.

1. Overview

1.1 Description

Loads failed upload records from the source operation log (up to 100 devices per retry submission), mints fresh upload tokens using stored key_prefix context, and pushes retry tasks to devices.

1.2 When to Use

• Recover from device-level or file-level failures after an upload batch
• Second attempt without re-specifying DeviceInfos / local paths

1.3 Execution Mode and Response

Asynchronous on devices. Response includes RetryOperationLogId for polling and RetriedDeviceCount for how many devices were submitted.

1.4 Prerequisites

1.5 Prerequisite Tools

1.6 Similar Tools

2. Inputs

2.1 Parameter List

Credentials: AirDroid Business OAuth2 + Qiniu AccessKey/SecretKey on the node.

2.2 Parameter Details

`OperationLogId`

• Positive number returned by Batch Upload Qiniu Files (OperationLogId field).

`Bucket`

• Must be identical to the bucket used when the source batch was created.

2.3 Parameter Combination Logic

• Both fields required together; retry scope is derived from failed records on the source log (max 100 devices per call per tool logic).

3. Outputs

3.1 Response Examples

Successful retry submission:

{
  "RetryOperationLogId": "1770854462319857001",
  "RetriedDeviceCount": 2,
  "SourceOperationLogId": "1770854462319857000",
  "Hint": "",
  "Retryable": false,
  "OriginalStatusCode": 200,
  "StatusCode": 200,
  "ErrorMessage": ""
}

Successful partial scheduling (one device skipped because key_prefix is missing):

{
  "RetryOperationLogId": "1770854462319857001",
  "RetriedDeviceCount": 1,
  "SourceOperationLogId": "1770854462319857000",
  "Hint": "Retry triggered for 1 device(s). Skipped 1 device(s) missing key_prefix: a286bea023eb4bfc8ef04770ee7dbb5e. Poll progress with 'Search File Batch Upload Results' using RetryOperationLogId.",
  "Retryable": false,
  "OriginalStatusCode": 200,
  "StatusCode": 200,
  "ErrorMessage": ""
}

Validation failure:

{
  "RetryOperationLogId": "",
  "RetriedDeviceCount": 0,
  "SourceOperationLogId": "",
  "Hint": "Provide the OperationLogId returned by 'Batch Upload Qiniu Files'.",
  "Retryable": false,
  "OriginalStatusCode": 0,
  "StatusCode": -1,
  "ErrorMessage": "OperationLogId is required."
}

3.2 Field Descriptions

4. Examples

4.1 Successful Retry Handoff

Request: Quick Start minimal request.

Response: Quick Start minimal response; poll with RetryOperationLogId.

5. Error Handling

5.1 StatusCode Semantics

Important: Plan and Workbench permission failures stay at StatusCode 200 with non-empty ErrorMessage and Hint; they are not 500 responses.

5.2 Common Errors

5.3 Agent Self-Healing

• When StatusCode == 200, ErrorMessage is empty, and RetryOperationLogId is non-empty, switch polling to RetryOperationLogId. A non-empty Hint in this branch reports skipped devices and does not turn the scheduled retry into a failure.
• When StatusCode == 200 and ErrorMessage is non-empty, treat the response as a business or HTTP failure and follow Hint / Retryable; do not poll an empty retry ID.
• If retry search still shows failures, investigate error_info / error_level before looping retry again.

6. Best Practices

6.1 Performance

• Retry only failed devices/files; avoid chaining retries without checking search results.

6.2 Security

• 🟡 Re-triggers device uploads to your bucket—same data-handling rules as initial batch.

7. Related Tools

8. Tool Chains

8.1 Full Recovery Path

Batch Upload Qiniu Files
  → Search File Batch Upload Results (failures)
  → Retry Batch Qiniu File Upload
  → Search File Batch Upload Results (RetryOperationLogId)

Appendix Reference:

• Field Reference
• Error Codes