Então eu estou usandoGoogle Volley para solicitação HTTP, que basicamente usaJavaéHttpURLConnection.

De acordo com meus testes, oproblema é esse:
Quando o tempo limite de 'leitura' noHttpURLConnection atinge, uma nova tentativa silenciosa é executada antes que a conexão seja fechada e a exceção relevante lançada (SocketTimeoutException)

Nota este:
- notei esse erro ao usarHTTP POST solicitação.
- O tempo limite de 'leitura' é diferente do tempo limite de 'conexão'.
- Se o tempo limite de 'leitura' (definido chamandoconnection.setReadTimeout(int)) NÃO está definido (0) ou definido como um valor maior queconnection.setConnectTimeout(int), esse erro não ocorre.
- Esta questão foi discutida,aqui por exemplo, mas não encontrei nenhuma solução satisfatória.
- Um problema um pouco relacionado pode ser encontradoaqui, mas não tenho certeza se é relevante (não é?)

Mais Antecedentes
Meu aplicativo é usado para pagar, portanto, não tentar novamente uma solicitação é crucial (sim, eu sei que ela pode ser tratada pelo servidor, quero que meu cliente esteja "correto" de qualquer maneira).

Quando o tempo limite de 'leitura' é definido, no caso de a conexão do servidor ser estabelecida, mas o servidor aguarda / dorme / atrasa a resposta que o tempo de espera excede antes de responder (aumentando assim a exceção de 'leitura' e não a exceção de 'conexão') , outra solicitação (silenciosa) é enviada logo antes da exceção ser gerada, resultando em duas solicitações semelhantes, o que não é aceitável.

Que tipo de solução estou procurando?
Bem, aquele que resolverá bem esse problema / bug, assim como a correção explicadaaqui (mas, novamente, acho que é irrelevante neste caso).
Além disso, eu gostaria de manter o fluxo original como está, o que significa não forçar a conexão a fechar ou algo assim.

O que vou fazer por enquanto é definir o tempo limite de 'leitura' para o dobro do tempo limite de 'conexão' (eles começam a contar ao mesmo tempo), para garantir que a exceção de 'conexão' seja levantada primeiro. Também tentarei superar esse problema no lado do servidor. O problema é que esse tempo limite de 'leitura' existe por um motivo, e minha implementação atual praticamente o ignora e lida apenas com os tempos limite de 'conexão'.

EDITAR oVolley da bibliotecaRetryPolicy não afeta esse problema, pois é uma nova tentativa silenciosa. Eu olhei o mais fundo possível dentro da biblioteca. Registros / pontos de interrupção em todos os lugares, cancelaram as chamadas para tentar novamente. Que como eu sei é 99,99% aHttpURLConnection questão.