Como um desenvolvedor Android trabalhando em um aplicativo de remessa popular que suporta mais de 100 mil usuários, é meu trabalho garantir que o aplicativo funcione sem problemas e que todos os problemas relatados sejam resolvidos prontamente. Eu estava acostumado a receber tíquetes de suporte ocasionais de usuários relatando problemas com o aplicativo. Mas, um dia, recebi uma enxurrada de tickets de pessoas que não conseguiam enviar dinheiro para uma determinada região por meio do aplicativo. Isso era especialmente preocupante porque era perto da temporada de férias, uma época em que muitas pessoas confiam em nosso aplicativo para enviar dinheiro para seus entes queridos.

Eu sabia que tinha que chegar ao fundo dessa questão o mais rápido possível. Então, recorri à sabedoria de Sherlock Holmes e comecei meu trabalho de detetive. Mas, como logo descobri, resolver esse problema não seria uma tarefa fácil. Seria preciso todas as minhas habilidades de detetive, bem como um pouco de sorte, para rastrear a causa raiz do bug e fazer o aplicativo funcionar corretamente novamente.

A Configuração

Comecei reproduzindo o problema no meu próprio dispositivo, tentando enviar dinheiro para a região afetada. Com certeza, o aplicativo congelou e exibiu uma mensagem de erro dizendo: "Falha na transação. Tente novamente mais tarde". Tentei usar um criador de perfil no Android Studio para ver se havia algum problema de desempenho que pudesse estar causando o problema. Sem problemas, o aplicativo estava funcionando conforme o esperado.

Rapidamente verifiquei os logs para ver se havia alguma informação ali que pudesse me ajudar a entender o que estava acontecendo. Infelizmente, os logs não foram muito úteis. Eles mostraram que o aplicativo estava fazendo as solicitações de rede usuais, mas não havia indicação do que estava causando o problema. Parecia, no entanto, que ocorreria um erro toda vez que tentássemos fazer uma solicitação POST para o terminal de transactions mas apenas para aquela região específica. Parecia que não importava o que eu tentasse; Eu não conseguia chegar mais perto de resolver o mistério.

Em seguida, peguei o código mais recente e verifiquei o branch de produção para ver se algum commit recente poderia ser relevante para o problema em questão. Também tentei fazer solicitações individuais usando o Postman e notei algo peculiar. A solicitação retornou um código de resposta de 400 , o que significa que foi uma solicitação inválida; isso normalmente significa que o cliente não está enviando todas as informações exigidas pelo back-end. No entanto, falhou ao retornar um erro significativo detalhando quais dados estavam faltando na solicitação. Como essa solicitação estava funcionando antes, parecia que o problema estava no lado do servidor.

Para testar essa teoria, usei um debugger para aprofundar o código. Estabeleci pontos de interrupção em pontos-chave do código e tentei enviar uma transação novamente, desta vez prestando muita atenção ao que estava acontecendo nos bastidores. Eu verifiquei se a solicitação continha todos os dados necessários que o back-end exigia e até desconectei a solicitação e a resposta. Infelizmente, tudo estava como esperado, mas eu ainda recebia o erro de solicitação inválida.

O enredo engrossa

Enquanto eu continuava minha investigação, não pude deixar de sentir que estava perdendo alguma coisa. Parecia que deveria haver uma explicação óbvia para o problema, mas não importava o quanto eu procurasse, não conseguia encontrá-la. Eu poderia sentir vontade de me provocar, meu próprio Moriarty, o bug não resolvido.

Quando eu estava começando a perder as esperanças, tive uma ideia. Lembrei-me de que duas semanas antes do início do problema, a equipe de back-end havia enviado uma atualização para o código do lado do servidor do aplicativo. Será que a atualização estava causando o problema?

Eu pinguei os desenvolvedores de back-end no Slack para ver se eles tinham alguma ideia sobre o problema. Eles me disseram que recentemente enviaram uma atualização para o código do lado do servidor, mas não tinham certeza se isso poderia estar relacionado ao problema que eu estava enfrentando. Eles estavam atualmente sobrecarregados consertando outro problema e só poderiam investigar o meu mais tarde. Eles mencionaram que a atualização foi lançada gradualmente, com apenas uma pequena porcentagem de usuários recebendo-a no início. Devido a uma nova política, nossos lançamentos agora eram faseados e os usuários o receberiam em um período de duas semanas. Será que a atualização causou o problema apenas para os usuários que a receberam?

O momento da lâmpada

Eu verifiquei rapidamente meus logs do firebase crashlytic para ver se havia alguma correlação entre o tempo da atualização e quando os usuários começaram a ter o problema. E com certeza, encontrei uma pista!

Depois de algumas idas e vindas com a equipe, minha teoria foi confirmada. A atualização incluiu uma alteração na maneira como o servidor lidava com certos tipos de transações. E descobriu-se que a mudança estava causando problemas especificamente para transações na região afetada. Após uma investigação mais aprofundada, descobri que o back-end agora exigia um campo extra a ser incluído nas solicitações de transação, um campo que antes era opcional. Essa mudança foi feita devido a novos regulamentos na região, mas infelizmente foi apressada, mal documentada e não foi testada exaustivamente. Como resultado, o campo não foi incluído nas solicitações de transação para a região afetada, causando falha nas transações.

Eu não podia acreditar. Depois de todo o meu trabalho de detetive, finalmente encontrei a causa raiz do bug. Foram necessárias muitas deduções de Sherlock e algum pensamento criativo, mas finalmente resolvi o caso do dinheiro desaparecido.

Imediatamente entrei em contato com a equipe de back-end para informá-los sobre o que eu havia descoberto. Eles ficaram chocados ao saber que sua atualização havia causado o problema e pediram desculpas pelo descuido. Nós concordamos com uma solução em duas frentes. A equipe de back-end lançaria um hotfix com um valor padrão para o campo agora obrigatório, permitindo que os usuários transacionassem enquanto a equipe de aplicativos móveis lançasse uma versão atualizada de nosso aplicativo Android que solicitaria essas informações extras.

Conclusão

Resolver esse bug foi uma experiência desafiadora e gratificante. Isso me lembrou da importância de pensar criativamente e não ter medo de tentar abordagens diferentes ao depurar um problema. E, assim como o forte vínculo entre Sherlock e Watson, também me lembrou do poder da colaboração e do trabalho em equipe – sem a ajuda da equipe de back-end, talvez eu nunca fosse capaz de resolver esse problema.

Espero que esta história do meu trabalho de detetive sirva como um lembrete para outros desenvolvedores sempre estarem atentos às pistas e nunca desistirem de resolver um problema desafiador. Como Sherlock Holmes disse uma vez: "Depois de eliminar o impossível, o que resta, não importa o quão improvável, deve ser a verdade." Com isso em mente, sei que qualquer bug pode ser superado, não importa o quão complicado possa parecer à primeira vista.