{
  "id": 9519706,
  "title": "Designing a Batch Move That Handles Partial Failure",
  "url": "https://urgent.news/2026/09/24/designing-a-batch-move-that-handles-partial-failure",
  "topic": "tech",
  "section": "Tech",
  "published": "2026-09-24T08:07:06.000Z",
  "source": {
    "name": "Dev.to",
    "slug": "dev-to",
    "url": "https://dev.to/wo_ytao_734002744cb9586f0/designing-a-batch-move-that-handles-partial-failure-ff1"
  },
  "original_language": "en",
  "account": "When organizing a large-scale transfer, it is crucial to account for the possibility of incomplete operations. Users should be able to discern whether only some of the selected items were affected or if none were altered. Simply displaying a generic error message does not provide sufficient clarity. Designing the process to enable inspection of each individual item's status is a more informative approach. This involves physically relocating catalog records, not changing the physical position of the discs themselves. It is essential to differentiate between the recorded location and the physical location if both are supported by the product. Using stable edition identifiers rather than movie titles for selection ensures consistency. The user may possess multiple versions of the same film. Once the selection is submitted, lock in the chosen IDs and the destination location, creating an operation record to prevent any potential changes thereafter. For each item, maintain the anticipated source location and version, enabling the system to identify any modifications made after the user initiated the selection. The transaction boundary should be carefully chosen. If the product necessitates all selected records to move concurrently, and the storage system can accommodate this, a transaction is the most straightforward solution. However, it is preferable to allow independent item updates, particularly when the batch may be distributed across multiple requests. Clearly communicate the different outcomes by assigning a unique, durable identifier to each operation. This identifier lets the client retrieve the status of the operation at any time, even after a refresh or network disruption. Possible item states include pending, processing, succeeded, conflict, and failed. Instead of merely stating \"outcome not yet confirmed,\" a more informative summary such as \"32 moved, 3 need review, 5 awaiting confirmation\" would provide greater insight. The list of items should remain accessible so users can identify any unresolved editions. The original selection should not be reported as entirely moved because the first request may have been accepted prematurely. To ensure safe retries, each item action should carry an identity derived from the operation ID and the edition ID. The server should atomically persist the result, including the location change, or employ an equivalent consistency mechanism. Repeating a request with the same identity should return the previously established result, rather than generating another move event. Duplicate audit entries or notifications resulting from duplicate effects should be handled consistently. When conflicts arise, treat them as deliberate decisions. For instance, if another device moves an edition to a different location during the batch, compare the current version with the expected version before applying the change. If there is a mismatch, it should result in a conflict rather than silently overwriting the newer location. Inform the user of the expected source, current source, and requested destination, allowing them to choose whether to retain the current location or initiate a new move based on the latest state. Conflicts necessitate a decision; repeatedly retrying an unchanged request will not resolve the issue. To maintain a reliable audit trail, store the original location for each successfully moved item. An undo request can attempt to restore that location, but only after verifying that the record still reflects the reversed move. If the location has been edited again, surface a conflict instead of sending it back to an obsolete shelf. Present the results of the undo operation with the same per-item clarity as the original operation. Clearly differentiate between \"undo requested\" and \"all changes reversed.\" Consider various uncomfortable cases, such as a lost response after a successful write, a reload during processing, a repeated submit, a destination removal before execution, an edition deletion mid-batch, and an undo following a later edit. For each scenario, determine what information the server possesses, what the interface can accurately display, and what actions remain available to the user. While this design is based on a hypothetical collection app, the same principles apply to bulk labeling, document folder management, and asset assignment. Ultimately, a dependable batch action should leave a clear, readable record of what transpired, empowering users to recover without ambiguity.",
  "summary": "Imagine a collection app with a bulk action: select 40 movie editions and move their catalog location from “Living room shelf” to “Moving box 03.” The request times out. Did nothing happen, did everything happen, or did only some records change? A generic “Something went wrong” toast leaves the user unable to answer that question. A better design makes the outcome inspectable at the item level.…",
  "key_points": [
    "Design batch move to handle partial failure.",
    "Use stable edition IDs for selection consistency.",
    "Assign unique identifiers to each operation."
  ],
  "editors_take": null,
  "illustration": null,
  "coverage": {
    "outlets": 1,
    "also_reported_by": []
  },
  "ai_generated": true,
  "disclaimer": "Summaries, key points and the editor’s take are written by software from other outlets’ reporting and may contain errors — always check the linked original."
}