오래 열린 탭 때문에 버전 업그레이드가 막힐 때 자동 새로고침보다 안전한 전환은 무엇인가요?

안전한 전환은 versionchange를 받은 탭이 사용자의 상태를 보존하면서 연결을 협력적으로 닫는 것입니다. 먼저 저장소 계층을 closing으로 바꿔 새 요청을 받지 않고, 진행 중 트랜잭션이 complete 또는 abort로 끝나기를 기다립니다. 미저장 폼은 DB에 이미 커밋된 값과 별도로 보존·저장·취소 중 하나를 사용자가 선택하게 한 뒤 db.close()를 호출합니다. 업그레이드가 완료되면 낡은 객체가 아니라 새 연결을 열고 db.version과 앱이 기대하는 스키마를 확인합니다.

예를 들어 B가 v4를 요청했는데 A가 v3 편집 화면을 오래 유지하면, A를 즉시 reload하는 것은 입력과 낙관적 UI를 잃게 할 수 있습니다. BroadcastChannel은 A에게 알림을 전달하는 수단이지 IndexedDB가 자동으로 모든 DAO를 교체해 주는 기능이 아닙니다. 협력 종료가 timeout을 넘기면 문서를 안전한 읽기 전용 상태로 만들고, 저장되지 않은 내용을 별도 메모리에 남겼다는 사실을 알린 뒤 사용자가 탭을 닫거나 재시도하도록 합니다. 자동 reload는 문서가 유휴 상태이고 복구 데이터가 확인된 경우에만 선택합니다.

전환 중 복구 데이터의 형식도 스키마 버전과 함께 저장해야 합니다. v3 화면에서 임시로 보존한 {draft, schema:3}을 v4 연결 직후 그대로 put하지 말고, v4가 요구하는 필드와 keyPath를 검증한 뒤 변환합니다. 업그레이드가 abort되면 원래 연결을 즉시 재사용하지 말고 현재 DB 버전과 연결 상태를 다시 읽어야 합니다. 이 절차는 reload보다 느리지만, 사용자가 입력을 잃었을 때 원인을 재현하기 어려운 비용을 줄입니다.

연결을 닫은 뒤에도 화면이 계속 옛 DAO를 호출하지 않는지 확인하는 것이 핵심입니다. 저장소 facade가 연결 세대 번호를 들고 있다가 close 시 세대를 증가시키면, 이전 세대 요청은 즉시 실패시키고 새 연결이 열린 뒤에만 재시도할 수 있습니다. 그렇지 않으면 blocked를 풀었는데도 새 스키마에 없는 store를 참조하는 오류가 늦게 나타납니다. 이런 검증은 reload 여부보다 데이터 손실과 스키마 불일치를 직접 줄이는 선택입니다.