Pular para o conteúdo
Development

A config que ficou embutida em todo vault, para sempre

Por Victor Da Luz•
rusttaurii18ndev-loggreenhouse

O Greenhouse tem uma metáfora de plantas correndo por todo o app. Ideias são “Seeds,” elas viram “Germinating,” um projeto passa por “Sprouting,” “Growing,” “Budding,” até chegar em “Fruiting.” Cada uma dessas palavras vivia numa struct do Rust e era serializada direto no config.yaml de cada vault no momento em que o vault era criado.

Isso soa inofensivo até você pensar no que significa para qualquer coisa que não seja o template de plantas atual, no idioma atual. Eu quero eventualmente oferecer traduções em espanhol e português, e, separadamente, venho segurando a ideia de um template que troca as palavras de plantas pelos nomes de estágio exatos que um professor específico de processo criativo já usa com os alunos dele. Nenhuma das duas coisas é uma mudança de interface. As duas são uma migração de dados por vault, porque todo vault já criado já tinha escrito “Sprouting” no disco em inglês, permanentemente, e nada estava lendo uma tabela de consulta em vez disso.

A correção foi parar de tratar essas palavras como dado. Nomes de estágio e os termos de roupagem de plantas agora são derivados no momento da leitura, a partir do id de um estágio, por uma única função, toda vez. Eles são marcados como #[serde(skip)] na struct do Rust, então não são escritos no config.yaml e também não são lidos de volta dele, mesmo que um vault antigo já os tenha ali de antes dessa correção. Decidi que valores antigos e obsoletos simplesmente passam a ser ignorados daqui para frente. Nenhum script de migração, nenhuma reescrita de arquivos existentes. Uma futura troca de template ou uma mudança de idioma agora é uma edição de uma função só, não um problema por vault.

Enquanto estava ali, encontrei uma segunda versão, menor, da mesma classe de bug. Os cards do dashboard adivinhavam o nome de exibição de um estágio capitalizando seu id bruto (humanizeStage), ignorando completamente a config real, enquanto a visão de detalhe do projeto usava o nome de fato configurado. Os dois concordavam hoje só porque os ids do template padrão acabam capitalizando nas mesmas palavras que seus nomes. Um template customizado teria mostrado “S1” numa tela e algo legível na outra. Mesma causa raiz, nomes de estágio tratados como strings improvisadas em vez de uma fonte real única de verdade, só aparecendo em duas camadas diferentes do app em vez de uma.

A parte que fico mais feliz de ter feito antes de considerar isso resolvido: minha primeira leva de cobertura de testes passou toda, e nada nela teria pego um fio cortado. Todo mock que eu tinha escrito alimentava o app com uma lista de estágios vazia ou com nomes de estágio que por acaso eram idênticos ao que o fallback antigo e quebrado já produzia. Um segundo olhar sobre o diff apontou que o bug que eu estava corrigindo, por definição, só é visível quando o nome real da config diverge do nome adivinhado, e nenhum dos meus testes exercitava esse caso. Adicionei testes que deliberadamente usam um nome de estágio que diverge do id, e então testei por mutação removendo temporariamente a conexão de volta e confirmando que eles de fato ficavam vermelhos. Ficaram. Testes verdes que não conseguem falhar não são testes, são decoração.

Leitura relacionada

Você também pode achar útil

Proton

Proton Pass

Gerenciador de senhas focado em privacidade, da equipe por trás do Proton Mail.

Como parceiro da Proton, ganho com compras qualificadas dos serviços de privacidade e segurança da Proton (Pass, Mail, VPN, Drive).

Saiba mais
Proton

Proton Mail

E-mail criptografado de ponta a ponta, com arquitetura de acesso zero.

Como parceiro da Proton, ganho com compras qualificadas dos serviços de privacidade e segurança da Proton (Pass, Mail, VPN, Drive).

Saiba mais
NordPass

NordPass

Gerenciador de senhas da equipe por trás da NordVPN, com um plano gratuito.

Como afiliado da NordPass, ganho com compras qualificadas.

Saiba mais