Por que uma página de diagnóstico com aparência saudável continuava exibindo undefined

Algumas pessoas que usavam uma pequena página de diagnóstico receberam a palavra undefined, de nove letras, no lugar do endereço de visitante. A página carregava normalmente, sem erro e sem tela em branco. A resposta errada ficava ali, com cara de resposta certa, enquanto a gente perdia tempo tentando achar o problema.

A tarefa: pegar a primeira resposta real entre três

Durante uma mudança na forma como os endereços de visitantes chegavam ao site, a página precisava escolher a primeira resposta real entre três lugares possíveis. Se o primeiro lugar estivesse vazio, ela deveria tentar o segundo. Se o segundo também estivesse vazio, deveria usar o último.

É como pegar a primeira maçã madura de três cestas. Se a primeira cesta está vazia, você passa para a próxima.

A correção que veio tarde demais

Primeiro, colocamos as três opções em uma única linha curta e transformamos o resultado final em texto. Esperávamos que esse passo tornasse a resposta segura para exibir. Não tornou. A conversão aconteceu tarde demais, porque a página já tinha escolhido a coisa errada antes de ela virar palavras.

A página roda em JScript, um tipo mais antigo de JavaScript. Nesse ambiente, pedir um valor que não existe não devolve uma resposta vazia. Devolve um recipiente vazio.

Imagine um pote vazio em cima da bancada da cozinha. Não há nada dentro dele, mas ele continua sendo um pote. Se alguém perguntar se há alguma coisa na bancada, a resposta é sim. O programa cometeu o mesmo erro. Ele viu o primeiro recipiente, achou que valia a pena escolhê-lo e nunca olhou o segundo nem o terceiro lugar, onde uma resposta real podia estar esperando.

Quando a página finalmente transformou aquele recipiente vazio em texto, ela não imprimiu um espaço em branco. Imprimiu a palavra undefined, literalmente.

Por isso o erro era tão escorregadio. Uma verificação simples via que a página tinha carregado. A resposta era de sucesso. Havia um texto com aparência normal no corpo da página. Nada indicava que algo estava quebrado. Mas, para os visitantes que dependiam do caminho alternativo, a página estava dizendo com toda a confiança algo que não era verdade.

A rotina compartilhada que funcionava

Um bom trecho de código compartilhado tinha nos enganado. Em outro lugar, uma pequena rotina foi criada para resolver exatamente esse problema. Antes de escolher entre os três valores possíveis, ela limpava cada um separadamente. Um valor ausente virava uma resposta em branco. Uma resposta em branco não é escolhida, então a rotina seguia para a próxima possibilidade.

Essa rotina compartilhada estava funcionando. As três páginas que falharam não a usavam. Cada uma tinha uma versão copiada da mesma ideia, com uma diferença minúscula: elas escolhiam primeiro e limpavam depois.

Quanto isso custou

Não foi uma queda dramática. Nenhum alarme dispara para uma página que, tecnicamente, continua funcionando. O custo foi o tempo de investigação, porque a tela parecia saudável. Custou paciência, porque uma resposta normal teve de ser tratada como suspeita. E três páginas diferentes, incluindo uma de trabalho administrativo, podiam mostrar a coisa errada antes de o padrão ficar claro.

O conserto, e perguntar à própria página

Esconder a palavra undefined só teria encoberto o problema. O conserto foi fazer com que cada resposta possível ficasse vazia ou utilizável antes de a página escolher entre elas. Depois disso, uma requisição controlada por todos os caminhos afetados devolveu um valor real em vez da palavra errada.

Essa verificação foi importante. Ler uma linha de código alterada e concordar com a cabeça não é a mesma coisa que fazer à página a pergunta que ela precisa responder na vida real.

O trabalho maior veio depois da correção visível. Procuramos outras cópias do mesmo atalho. Uma receita compartilhada e mais segura e várias receitas copiadas à mão tinham se afastado umas das outras. A rotina compartilhada antiga se protegia. As cópias, não.

Isso não tem nada a ver com endereços de visitantes. Uma planilha, um formulário, um modelo de e-mail para clientes ou uma página de site podem ter o mesmo problema. Quando existe uma versão confiável que funciona e há versões parecidas em outros lugares, cada uma delas precisa ser verificada quanto à mesma proteção e testada do jeito que um visitante a usaria.

O recipiente vazio estava fazendo exatamente o que um pote vazio faz. Ele existia, ocupava um lugar e respondia “tem alguma coisa aqui?” com um sim. O JScript nunca mentiu para a gente. A página perguntou se havia alguma coisa ali, quando precisava perguntar se a resposta era utilizável antes de o endereço de um visitante ser impresso na tela.