1

Sobre a pergunta do fim: se não me engano, quando o problema é o token o BadRequest vem com o fieldViolations apontando pro campo message.token. Se for outro campo, é payload, e eu nem contaria como falha do token. Esperar a segunda falha ajuda pouco, porque payload ruim falha igual toda vez.

No Unregistered do APNs eu usaria o timestamp antes de apagar. Se o app registrou o token de novo depois daquele horário, ele voltou a valer, e apagar seria perder um aparelho bom. Era a mesma regra que a Apple dava no antigo feedback service.

Carregando publicação patrocinada...
1

Boa, as duas observações são certeiras.

No FCM é isso mesmo: o detalhe google.rpc.BadRequest traz fieldViolations[].field, e quando ele aponta para message.token o problema é o token; qualquer outro campo é payload. Aqui a gente separa olhando para qual campo o erro aponta: se é um campo da mensagem (message.android, message.data, message.notification…), o token fica intacto e o erro vai para o log do envio com o texto do FCM. E concordo que esperar a segunda falha não ajuda no caso de payload, porque ele falha igual toda vez.

No Unregistered, o timestamp é o que separa "token morto" de "token que voltou". A regra do antigo feedback service continua valendo: só apaga se o app não registrou o token de novo depois daquele horário. Comparar com o horário do último registro resolve a corrida entre o app se registrar e a resposta do APNs chegar.

Valeu por complementar, deixa o texto mais completo pra quem chegar depois.