인터페이스에서 오류가 보고되면 다시 시도하시겠습니까? 문서화 작업에서는 먼저 어떤 오류를 복구할 수 있는지 구별해야 합니다.

오류가 보고된 후 재시도하는 것이 일반적인 관행이지만, 무분별하게 무한정 재시도하면 결함이 확대될 수 있습니다. 권한 오류, 계정 연체, 손상된 파일, 일시적인 서비스 사용 등은 다르게 처리되어야 합니다.

이 기사는 문서 번역 및 변환과 같은 비동기 작업을 수행하는 개발자 및 제품 학생에게 적합합니다. 이 내용을 읽은 후에는 먼저 실패를 분류한 다음 대기 시간, 최대 시도 횟수, 사용자 개입이 필요한 시기를 결정할 수 있습니다.

아래 코드와 흐름은 격리된 환경에서 테스트된 합성 샘플을 기반으로 합니다. 모든 정품 문서나 제품 효과에 대한 보증을 의미하지는 않습니다. 중요한 서류를 처리하기 전 반드시 원본을 보관하시고, 본문의 경계 및 수용사항에 따라 검토하시기 바랍니다.

문서 작업에서 오류가 보고된 후 어떻게 다시 시도하나요? 한 문장 결론

다시 시도할지 여부를 결정하기 전에 먼저 실패를 분류하십시오. 일시적인 실패는 제한되어 철회되고, 권한 및 계정 문제는 중지되어 사용자에게 넘겨지며, 입력 오류는 사용자에게 수정하도록 남겨집니다.

먼저 재시도가 중복 작업을 생성할지 여부를 결정합니다.

POST 타임아웃은 특히 골칫거리입니다. 클라이언트가 응답을 받지 못한다고 해서 서버가 작업을 생성하지 않았다는 의미는 아닙니다. 인터페이스에 멪등 키와 작업 쿼리 메커니즘이 없으면 무작정 재전송하면 여러 개의 변환 작업이 발생할 수 있습니다.

따라서 재시도 전략은 HTTP 상태 코드를 보는 것보다 인터페이스 계약을 따르는 것을 우선시해야 합니다.

순수 함수로 횟수와 대기 예산을 기록하세요

from enum import Enum

class Failure(Enum):
    TRANSIENT = "transient"
    AUTH = "auth"
    BILLING = "billing"
    INVALID_INPUT = "invalid_input"

def delay_for(kind, attempt, replay_safe):
    if type(attempt) is not int or attempt < 0:
        raise ValueError("invalid attempt")
    if not replay_safe or kind is not Failure.TRANSIENT:
        return None
    schedule = (1, 2, 4)
    return schedule[attempt] if attempt < len(schedule) else None

assert delay_for(Failure.TRANSIENT, 0, True) == 1
assert delay_for(Failure.TRANSIENT, 2, True) == 4
assert delay_for(Failure.TRANSIENT, 3, True) is None
assert delay_for(Failure.TRANSIENT, 0, False) is None
assert delay_for(Failure.BILLING, 0, True) is None
assert delay_for(Failure.INVALID_INPUT, 0, True) is None

이 코드는 재시도 계획만 계산하며, 실제로 대기하거나 요청을 보내지 않습니다. 고정된 1초, 2초, 4초는 합성 시연용이며 일반적인 서비스 권장 사항이 아닙니다.

운영 환경은 다음과 같은 점들도 고려해야 합니다:

• 서버가 반환한 Retry-After
• 랜덤 지터는 여러 작업을 동시에 복구하는 것을 방지합니다
• 전체 마감일
• 동시 제한량

서버의 요청 대기 시간이 지역 예산을 초과하면 재시도를 일찍 요청하는 대신 중단해야 합니다.

오류 유형은 서로 다른 행동에 대응합니다

논리적 작업 저장 및 시도 로그

각 사용자 연산은 논리 작업에 대응하며, 이 논리 하에서 여러 번 시도할 수 있습니다. 각 시도는 시작 시간, 실패 카테고리, 원격 작업 ID를 기록합니다. 결국 승인을 통과한 결과는 단 하나만 선택됩니다.

이 접근법의 장점은 재시도 문제를 해결할 때 완전한 기록이 유지되며, 시도 횟수가 사용자 요청 횟수와 잘못 계산되지 않는다는 점입니다.

📊 핵심 비교

번역 경험의 안정성은 명확한 설명에서 나옵니다

OmniDoc에 연결할 때, 프론트엔드는 사용자가 대기 중인지, 재인증 중인지, 계정 점검 중인지 등 현재 상태를 명확히 알려야 합니다. 모든 상황을 '생성 중'으로 표시하지 마세요.

사용자는 명시된 종료 직전 작업을 기다릴 의향이 있지만, 피드백이 없는 버튼을 반복해서 클릭하는 것은 꺼립니다.

참고: Python enum.

🎯 어떤 방법이 당신에게 맞나요?

서비스 재개를 기다리고 있다면

제한 후퇴를 사용하고, 최대 수와 총 대기 시간을 설정하며, 서버의Retry-After를 존중하세요.

권한이 있거나 계정 문제가 생기면

자동 재시도 중지, 재인증 또는 계정 상태 확인 알림.

입력 파일 구조가 잘못되었다면

제출 전에 파일을 복구해 달라고 요청하고, 같은 파일을 다시 보내지 마세요.

호출하는 인터페이스가 POST이고 타임아웃이 되어 있다면,

먼저, 인터페이스가 멪등 키나 작업 쿼리를 지원하는지 확인한 후 재전송 여부를 결정합니다.

❓ 자주 묻는 질문 (FAQ)

1. 모든 오류를 직접 재시도할 수 있나요?

아니, 그럴 수 없어. 권한 오류, 계정 과다 지급, 손상된 파일, 임시 서비스 사용 중은 별도로 처리해야 하며; 유한된 회피에는 일시적 실패만 적합합니다.

2. POST 타임아웃이 끝난 후에 다시 게시할 수 있나요?

직시적으로 재게시하는 것은 권장되지 않습니다. 클라이언트가 응답하지 않는다고 해서 서버가 작업을 생성하지 않았다는 뜻은 아닙니다. 멮등성 키나 작업 쿼리 메커니즘이 없으면 중복 작업이 발생할 수 있습니다.

3. 재시도 횟수와 대기 시간은 어떻게 결정해야 할까요?

고정된 1초, 2초, 4초는 합성 시연을 위한 것입니다. 생산 환경은 Retry-After, 랜덤 지터, 전체 컷오프 시간, 동시성 제약 조건을 결합하여 결정해야 합니다.

4. 시도 횟수가 사용자 요청 통계에 영향을 미칠까요?

아니요, 한 번의 사용자 작업은 논리적 작업으로 기록하고, 각 재시도는 그 작업 하에서 시도한 번으로 기록하면 됩니다.

📝 요약

재시도의 핵심은 여러 번 시도하는 것이 아니라, 먼저 실패 유형을 파악한 후에 어떻게 할지 결정하는 것입니다. 복구 가능한 결함은 경계가 설정되어 재시도되며, 인간이 처리해야 하는 문제는 즉시 사용자에게 반환됩니다.

지금 경험해보세요: 원본 형식을 유지하면서 번역을 시작하려면 문서를 업로드하세요