What if a bulk operation fails midway? Separate completed, unconfirmed, and retryable items

When a page suddenly times out during bulk article publishing, product status updates, or data imports, checking the results is the priority. A timeout means the browser did not receive a complete response; it does not prove that the server did nothing. Resubmitting the whole batch may repeat completed work, while simply abandoning it may leave tasks unfinished.

Handling bulk operation failures starts with three situations: a success result has been received, a request was submitted but its outcome is unconfirmed, or execution has not started. Each needs a different recovery method. Operators need to know how to continue, and implementation teams must provide enough evidence in the interface for that decision.

No result on the page does not mean everything failed

A bulk operation involves request submission, server processing, and a returned result. The request may never reach the server, or data may already have been written before the connection breaks during the response. Both situations can appear as an ended wait or an error on the page, despite different actual data.

Suppose an operator publishes drafts in batches. The first batch shows success, while the second reports a network exception after waiting. The confirmed facts are the first batch's result and the absence of a reliable response for the second. Later batches not submitted are pending. Mark the second batch unconfirmed; do not put it in the same list as articles with explicit validation failures.

The interface can say: "Confirmed completions have been retained. The current batch's outcome is unconfirmed, and subsequent batches are paused. Refresh to check." This is more helpful than "Publishing failed. Please retry," because it states known facts and explains why checking is the next step.

If the operation creates records, sends notifications, or causes irreversible changes, also establish the consequences of repeating it. Setting the same status again differs from creating another record. A button's name alone cannot establish whether retrying is safe.

Keep a fixed record of the operation scope before execution

During recovery, temporarily assigning one person to checking and further submissions is advisable. Other editors should avoid changing the same records' status. If editing must continue, record the change so the checker can distinguish the original task's effects from later edits.

Which objects can be checked after an exception depends on whether scope was recorded before execution. If all you know is "process the current filter results," searching again during recovery may produce another set of articles: someone may have added drafts or changed categories or publication status.

Fix the list at confirmation and retain at least identifiable record numbers, operation type, language scope, and selected count. Titles aid manual searching; identifiers distinguish identical titles. If cross-page selection is supported, show how many objects belong to the task rather than retaining only the visible rows.

For tasks processed in batches, link every batch to the same operation. Operators need not understand the implementation, but should be able to see included records, the current batch, and confirmed batches. Specify whether this information remains available after closing the browser, rather than assuming every CMS has a task center.

A pre-operation list does not guarantee indefinite eligibility. If someone changes content after confirmation, the implementation must still check eligibility during actual processing. Keep objects traceable and recheck eligibility under the agreed rules; these are different requirements.

Success means that after an interruption the team can retrieve the task's scope and locate specific entries without using screenshots to guess the original selection.

Distinguish execution progress from confirmed results

A progress percentage may count submitted requests or processed objects, or simply estimate the current stage. Ask precisely what it measures during acceptance testing. Treating request submission as completed publication makes operators misjudge remaining work when network errors occur.

A clearer display provides the total scope and counts of confirmed successes, confirmed incomplete items, and unconfirmed outcomes together. Explicit skips and failures also need reasons: already published, incomplete information, or changed status require different actions. Another click does not resolve all of them.

Suppose a local test uses three batches: the first returns normally, while the second is interrupted during the response. The interface should retain the first batch's success, mark the second unconfirmed, and show that the third has not started. These counts are test settings, not business project performance data. Their purpose is to verify faithful reporting of execution.

After an exception, sequential tasks should usually stop submitting subsequent batches and retain displayed results and scope. If the system executes several batches in parallel, explain which remain running. Clicking pause must not be described as terminating all server processing.

Begin refreshed checks with the actual status of specific records

Recovery can follow a sequence: record scope and messages at the exception, return to the list or task record, locate unconfirmed batches, and open key entries to inspect saved results. Use actual states and versions, rather than just the progress position still shown on the page.

For article publishing, check whether Chinese and English statuses match the task, whether text is still the intended publication version, and whether lists and details agree. Exclude already published articles in the second batch from retries. For articles still in draft, check completeness before confirming and continuing.

For operations adding information, determine whether the submission already created corresponding records. Prefer task numbers or request identifiers when available. Searching only by title may mistake an earlier identically named record for this submission's success. Without reliable association information, ask the implementation team to help verify rather than guess and accumulate duplicate data.

After checking, divide the scope into completed items, items needing repair, items safe to continue, and items still unconfirmed. Keep unresolved items out of new bulk operations. This makes the recovery list actionable and explains to the next person why some content cannot yet be processed.

Keep retries limited and agree recovery rules in advance

Retrying requires knowing what this execution will change. If it only sets published items to published again, the system may skip objects already in that state under the rules. If it also sends messages or adds relationships, additional effects may occur even when the status is unchanged.

The implementation team should explain how duplicate submissions are identified, whether existing results are reused, and which changes still occur. The business requirement can say: "Repeated clicks for the same task must not reprocess confirmed items; query unconfirmed items' status before deciding whether to continue." Developers should assess the implementation against the existing system.

Recovery and rollback also differ. Recovery completes remaining work; rollback reverses changes already made. If published content has been accessed, notifications sent, or information used by another process, "Cancel task" cannot promise to restore everything. Button text should clarify whether it cancels future work or genuinely reverses a supported change.

For large tasks or results handed between people, provide a downloadable exception list. Include records, reasons, checking status, and handling outcomes, rather than only a total failure count. Operators should repair issues before deriving the next operation's scope from this list.

Use interruption tests to verify that recovery actually works

Demonstrating one successful batch does not prove exception recovery. In an isolated test environment, test normal responses, explicit validation failure, interruption before submission, and interruption before the response returns. Record the relationship between page feedback and saved outcomes in each scenario. See How to Design Data Import: Templates, Validation, Progress, and Failure Recovery for related checks.

Observe four points: whether existing success information remains, whether unconfirmed outcomes are accurately named, whether subsequent tasks stop as agreed, and whether recovery repeats processing. Also close and return to the page to check continued access to information as required. Tests involving actual publication or email should use clearly identified test content to avoid inclusion in business statistics.

Acceptance records can include scope, batch, interruption point, message, actual status, and handler. Success means every exception has a corresponding next step, rather than just a screenshot of a red error. If the CMS does not retain task records, document that limitation in the handover and specify a checking method.

The final step in handling bulk operation failure is an actionable continuation list. Confirm changes already made before processing the remainder, so operators need not choose intuitively between repeating everything and stopping completely. See Is it necessary to pop up a second confirmation before deleting? The design of hazardous operations should be determined based on whether they can be revoked or not for related checks.

Frequently asked questions

Can I refresh immediately when the page reports failure?

First retain the current message, selected scope, and confirmed results. Refreshing helps inspect actual status but may clear progress information held only on the page. Whether to export a list first depends on the CMS's record capabilities.

Will an unconfirmed outcome automatically become a failure if I wait longer?

Not necessarily. Waiting time cannot prove whether the server wrote data. Query record status or task records. If the outcome remains unclear, ask the implementation team to investigate rather than substitute elapsed time for evidence.

Should I select every original object again when retrying?

Prioritize objects verified as incomplete and still eligible. A system with reliable duplicate-execution protection may recover under its rules. Without verified protection, do not assume resubmitting the entire batch is safe.

Will one incomplete record undo the entire batch?

That depends on the agreed policy. Some tasks require every item to pass; others permit partial completion. Requirements and result messages must follow the same rules and must not describe partial success as no changes to the batch.

Do operators need to inspect program logs?

Routine recovery should preferably use record states and task records. Logs support further investigation by the implementation team. Provide operation time, scope, and exception messages; operators should not have to interpret internal error codes themselves.