취소 요청을 처리 이력 삭제로 구현하지 않기: 중단과 보상 확인을 나누는 작은 설계

A customer emailed to cancel a request. If it is still in the queue, the execution can be halted; however, if the request has already completed external transmission, the same processing cannot be done again. However, combining all cases into a single "cancelled" value makes it difficult to explain what was halted and what remained.

This article presents a design concept for small workflow tools. The official email description does not claim to have implemented these functions. Cancellation intentions and execution results are two separate aspects. A customer's intention can be marked as withdrawn, but the execution history's completion should not disappear automatically.

Rather than adding another column to the status, it is easier to keep a separate record of the following fact. Request status: valid / withdrawn; execution status: pending / progressing / halted / execution complete. Follow-up verification: unnecessary / being verified / action verification. For instance, if the customer cancelled a sending task, but the file had already been delivered to a partner, the request status would be withdrawn, but the follow-up verification would still be ongoing.

The fact of sending the email alone does not mean the file retrieval is complete. First, test the competitive section. When a cancel message and the start of the job arrive almost simultaneously, how can success be determined? Right before job commencement, reconfirm whether execution is possible. If the job is already in progress, verify the point where interruption is possible.

If the job is already finished, maintain its success history and review separate follow-up actions. If there is no response from an external system, keep it as "being verified." How to handle locks or transactions depends on the actual storage and queue structure. The key is to ensure the user understands what "cancellation completed" means and that the system matches the facts it has verified.

Compensation work is not about undoing time. Some tasks, such as file transfer, external notifications, and cost-impacted processing, cannot simply be undone. To prevent the same measure from being executed twice when retrying the original job, maintain an identifier. When retrying, also ensure the same measure is not executed twice.

At least four tests are necessary: canceling while pending, canceling while executing, canceling after completion, and canceling due to delayed external verification. When multiple cancellation notifications arrive at once, ensure the status does not flip or duplicate follow-up actions are not generated. The response should also indicate the verified scope instead of "cancellation completed."

This is a fictional correspondence example and does not guarantee contract cancellation or refund results. Adjust it according to the agreed conditions and actual processing authority.