Node-redis: retry_strategy에서 오류를 반환하면 on(error) 이벤트가 발생하지 않습니다.

이것은 실제로 의도적으로 수행된 작업입니다. 그 이유는 클라이언트가 실패했다는 정보가 이미 있으므로 더 이상 내보낼 필요가 없기 때문입니다. 이것은 실제로 semver를 유지하는 것에 대한 좋은 변화가 아닙니다./ 죄송합니다.

다른 사람들은 어떻게 생각하는지 알아보기 위해 작은 설문조사를 하고 싶습니다. 핑 @NodeRedis/기고자 @dirkbonhomme

예: 오류 수신기에 오류를 버블링합니다.

아니오: 현재 솔루션 유지

전자를 위한 사용 사례를 제공하기 위해 connect-redis 는 오류가 발생하지 않는 경우 retry_strategy 와 (분명히) 상호 배타적이 되는 logErrors 옵션을 제공합니다.

new RedisStore({
  logErrors: (err) => console.error, // does nothing
  retry_strategy: (options) => {
    if (options.error.code === 'ECONNREFUSED' || options.error.code === 'ENOTFOUND') {
      return new Error('The server could not be found or refused the connection');
    }
    return 1000;
  }
})

@tj

현재 기능은 문서에 있는 한 괜찮다고 생각하지만 그렇지 않습니다. 재시도 전략에서 반환된 오류를 여전히 버블링하는 옵션을 추가하는 것도 허용될 것이라고 생각합니다.
전.:

redis.createClient({
    retry_strategy: ...,
    retry_strategy_bubble_up: true or false (default to false to keep existing functionality)
});

오류가 기록되지 않는 이유를 파악하는 데 마지막 날을 보냈습니다. 이제 로깅이 retry_strategy 콜백에 있으므로 모든 것이 내 애플리케이션에서 원하는 대로 이루어집니다.

오류를 던지는 대신 오류 핸들러가 잡을 수 있는 오류 이벤트를 수동으로 내보냅니다.

retry_strategy: function(options) {
            logger.debug('Retry redis connection: ', options.attempt);

            // 5 mins
            if (options.total_retry_time > 1000 * 60 * 5) {
                // End reconnecting after a specific timeout and flush all commands with a individual error
                return logger.error('Redis: maximum retry time exhausted');
            }
            if (options.attempt > 5) {
                // End reconnecting with built in error
                logger.error('Redis: maximum connection retry reached');
                return client.emit('error', 'maximum retry');
            }
            return 1000 * 2;
        },

버블 업! (또는 다른 것)

@alannesta가 쓴 것과 같은 사용자 정의 오류 이미터는 지저분하고 retry_strategy 는 생성자의 매개변수 중 하나이므로 함수 외부의 개체에 액세스해서는 안 됩니다.

NodeRedis 이미 이벤트 시스템이 있습니다. 그냥 사용하세요!

end 가 사용되었고 "연결이 닫혔습니다"를 의미하므로 "할 수 있는 모든 작업을 수행했으며 이 연결이 끊어졌습니다"라는 새 이벤트를 추가할 수 있습니다(지금은 "종료"라고 함). , 지금부터 우리는 그것에 대해 아무 것도하지 않습니다. 청소 작업을하는 것이 좋습니다."

이 변화가 정말 필요합니다.

이 문제와 관련하여 문제가 발생했습니까?

이것이 고정되지 않거나 우선 순위가 아닌 이유가 있습니까? 이벤트를 내 보내지 않으면 어떤 이점이 있습니까? retry_strategy 사용할 때 더 이상 작동하지 않는 redis 연결 없이 서비스를 종료하는 확실한 방법은 없으며 이는 매우 기본적인 사용 사례여야 합니다. 가장 좋은 해결책은 아마도 @AaronJan이 제안한 별도의 이벤트일 것입니다.

이제 error 이벤트 리스너까지 반환된 retry_strategy 오류를 버블링하는 v3.0.0을 출시했습니다.