Google Sheets - Erro de Correspondência Automática de Nomes

[Dwayne_Taylor]

Título: Google Sheets node (Auto-Map, typeVersion 3) escreve valores uma coluna desalinhada após atualização para 2.22.5

Descreva o problema/erro/pergunta

Após atualizar o n8n de uma versão anterior (~10 versões atrás) para 2.22.5, nodes Google Sheets usando “Auto-Map Input Data to Columns” começaram a escrever valores nas colunas erradas em Append e Update. Nenhum node foi alterado — eles ainda estão em typeVersion 3 (a mais recente é 4.7). A única variável foi a versão do n8n.

O desalinhamento é um deslocamento consistente de uma coluna para a esquerda que começa em algum ponto ao longo da linha:

• O primeiro bloco de colunas mapeia corretamente.

• A partir de uma coluna específica, cada valor fica uma célula à esquerda do seu cabeçalho correspondente, se propagando até o final da linha.

Ilustração mínima (chave JSON de entrada → onde deveria ir vs. onde vai):

header: ... | colN  | colN+1 | colN+2 | colN+3
should:     | (vazio)| fieldA | fieldB | fieldC
actual:     | fieldA | fieldB | fieldC | (vazio)   ← tudo deslocado 1 para a esquerda a partir de colN

Ponto chave: o lado de leitura está correto — é a escrita que desalinha os dados. O JSON de saída do node Append mostra p. ex. fieldA: "X" e relata sucesso, mas ler aquela mesma linha de volta pela chave retorna fieldA: "Y" (o valor da coluna vizinha). O valor foi fisicamente escrito uma coluna adiante. Posteriormente, qualquer coluna de fórmula na planilha e a etapa Update seguinte resolvem contra as células erradas e retornam #REF!.

Então o matching nome-→coluna do Auto-Map está parcialmente falhando: colunas iniciais combinam, um bloco contíguo posterior é deslocado por um.

Características da planilha que parecem disparar isso (uma planilha simples não reproduz):

• Uma planilha larga (~150 colunas), das quais o workflow fornece apenas ~30; o restante está em branco ou contém colunas de fórmula na planilha.

• Um nome de cabeçalho duplicado (texto de cabeçalho idêntico em duas colunas diferentes).

• Uma coluna cujo valor é um objeto aninhado / blob JSON em vez de um escalar.

Este padrão (Append → ler de volta → Update com contexto de linha/fórmula) é usado em muitos workflows, então afeta todos eles.

Qual é a mensagem de erro (se houver)?

Nenhum erro de node — Append/Update relatam sucesso. A única falha visível é #REF! em fórmulas de planilha dependentes, causada pelo deslocamento de coluna anterior.

Perguntas para o time:

1. A lógica de resolução de coluna Auto-Map para Google Sheets typeVersion 3 mudou entre versões recentes e 2.22.5? (A v3 agora é roteada através de código diferente?)

2. Cabeçalhos duplicados e/ou valores de célula com objetos aninhados são conhecidos por quebrar o alinhamento de coluna Auto-Map em versões atuais?

3. Caminho recomendado — mover esses nodes para “Map Each Column” explícito, atualizar para node 4.x, ou isto é uma regressão v3 que vale a pena consertar?

Workflow / saída: Tenho prazer em compartilhar um workflow de repro mínimo sanitizado e uma linha antes/depois sob demanda.

Configuração do n8n

• Versão do n8n: 2.22.5 (atualizado de ~10 releases anteriores, tag exata anterior desconhecida)

• Banco de dados: PostgreSQL

• EXECUTIONS_PROCESS: main

• Executando via: Docker, com workers

• OS: Ubuntu

• Google Sheets node: typeVersion 3 (inalterado ao longo da atualização)

[kjooleng]

Oi @Dwayne_Taylor

Seus dados estão se deslocando porque o recurso “Auto-Map” do n8n está ficando confuso sobre qual informação pertence a qual coluna. Pense nisso como uma esteira transportadora: uma vez que o sistema encontra um “obstáculo”—como um nome de coluna que aparece duas vezes ou um dado complexo—ele perde sua posição. Como não sabe onde colocar esse item específico, acaba empurrando tudo que vem depois dele um espaço para a esquerda, causando um efeito dominó de dados deslocados para o resto da linha.

Isso provavelmente está acontecendo agora porque a atualização recente do n8n mudou a forma como o software calcula essas posições nos bastidores. Mesmo que você não tenha alterado seus nós, o “mecanismo” que os executa foi atualizado. Em uma planilha larga com cabeçalhos duplicados, o sistema está tendo dificuldade em distinguir entre colunas com o mesmo nome, o que desencadeia o desalinhamento e leva às fórmulas quebradas que você está vendo em sua planilha.

Para corrigir isso, o movimento mais seguro é parar de depender do “Auto-Map” e mudar para “Map Each Column” para seus fluxos de trabalho críticos. Ao dizer manualmente ao n8n exatamente qual campo vai para qual coluna, você remove a incerteza e impede que o sistema desloque seus dados. Se possível, renomear seus cabeçalhos duplicados para que sejam únicos também resolveria a causa raiz da confusão.

Isso ajuda?

[nguyenthieutoan]

Além de mudar para “Map Each Column”, há mais uma opção que vale a pena tentar: atualizar o nó do Google Sheets para a versão mais recente do typeVersion (4.7) (edite o JSON deste nó). TypeVersion 4 reescreveu como o mapeamento de colunas funciona internamente, então o problema de desvio do Auto-Map vinculado ao comportamento do typeVersion 3 em builds mais recentes do n8n provavelmente não afetará. Vale a pena tentar antes de remapear manualmente todas as 150 colunas.

[Dwayne_Taylor]

Oi pessoal - valeu pelo follow up rápido

Isso assume que os nomes das colunas têm uma duplicata?
Já que algumas das minhas planilhas tinham duplicatas nelas e outras não, mas ainda estavam gerando erros

Alemais @nguyenthieutoan você tem documentação sobre o upgrade do node - não estou vendo a funcionalidade que você está mencionando

[nguyenthieutoan]

Oi @Dwayne_Taylor

Desculpe, você precisa editar a versão do nó manualmente editando o JSON deste nó.

Construindo a partir do que já foi compartilhado acima, existem alguns padrões de planilha que parecem tornar o Auto‑Map na typeVersion 3 muito mais fácil de quebrar após uma atualização do n8n:

• Planilhas muito largas (~150+ colunas) onde o workflow escreve apenas em um pequeno subconjunto de colunas e o resto está vazio ou contém colunas de fórmula.
• Nomes de cabeçalho duplicados – o Auto‑Map depende do texto do cabeçalho, então nomes idênticos podem confundir a lógica de correspondência.
• Nomes de cabeçalho com caracteres especiais (por exemplo, quebras de linha), que o Google Sheets aceita mas o n8n nem sempre reconhece como o mesmo nome.
• Colunas que armazenam objetos aninhados / blobs JSON em vez de valores escalares simples.

Quando alguns desses se combinam, é exatamente onde começamos a ver o deslocamento "uma coluna para a esquerda" que você descreveu, mesmo que o nó em si não tenha sido alterado. Nesses casos, mover fluxos críticos para o "Map Each Column" explícito em uma versão mais recente do nó Sheets geralmente é a correção de longo prazo mais confiável.

[achamm]

@Dwayne_Taylor sobre o typeVersion bump — abra o workflow afetado, clique no menu ... (canto superior direito da canvas) → Download. abra o arquivo JSON baixado em um editor de texto e encontre seu nó Google Sheets, depois altere typeVersion de 3 para 4.7 e adicione o campo mode correspondente. antes/depois fica assim:

{
  "before": {
    "parameters": {
      "operation": "append",
      "documentId": "...",
      "sheetName": "...",
      "dataMode": "autoMapInputData"
    },
    "type": "n8n-nodes-base.googleSheets",
    "typeVersion": 3
  },
  "after": {
    "parameters": {
      "operation": "append",
      "documentId": "...",
      "sheetName": "...",
      "columns": {
        "mappingMode": "defineBelow",
        "matchingColumns": ["row_id"],
        "value": {}
      }
    },
    "type": "n8n-nodes-base.googleSheets",
    "typeVersion": 4.7
  }
}

depois importe o JSON editado de volta (canto superior direito ... → Import). o nó v4 usa mapeamento defineBelow onde você vincula explicitamente cada campo de entrada a uma coluna da planilha, então headers duplicados + planilhas com 150 colunas de largura deixam de ser um problema.

sobre sua primeira pergunta (se aplica sem duplicatas) — sim, a mesma lógica de matching está subjacente a todos os 4 padrões que @nguyenthieutoan listou (planilhas amplas e esparsas, caracteres especiais em headers, objetos aninhados). duplicatas são só o mais óbvio. se algumas de suas planilhas afetadas não têm duplicatas, você provavelmente está enfrentando um dos outros — muito provavelmente o caso de objeto aninhado já que você disse que v3 estava lendo corretamente mas escrevendo errado (o serializador de blob JSON em v3 vaza para colunas adjacentes quando campos são esparsos).