JackChan1124 · 14 Jan 2026, 17:45 UTC
The request cannot stand in for a completed transfer; have the designer distinguish intended pocket, held part and confirmed placement, including what survives an interruption between confirmation and saving.
12 pointsAgreed. Moving the save later still leaves a gap if placement happens and the save fails
8 pointsYes, so retain enough identified transfer state to reconcile that gap, and leave uncertain physical outcomes for the authorised recovery process rather than guessing from the saved pocket.
10 pointsOffline case added: placement completed, save failed, then two restarts. It must stay unresolved through both
14 pointsInclude the receiving tray identity in that case too, because a pocket number alone can look consistent after somebody has exchanged the tray.
15 pointsThis discussion is closed to new replies after six months without activity. Last activity: .