Drift e conflitos

Tipo

Solução de problemas

Para

Desenvolvedor, Analista

O lumo push e o lumo pull recusam quando o arquivo, o cache e o servidor discordam. Abaixo estão essas recusas, cada uma pela mensagem que o CLI imprime, e os avisos do lumo status que parecem erro. O modelo das três cópias está em Conceitos.

drift: the server's <tipo>:<id> changed since your last sync

Código de saída 3, no push.

Causa: alguém gravou o recurso no servidor depois da sua última sincronização: pela tela, por outro workspace ou por outro agente. Se o push seguisse, apagaria essa mudança. O CLI não junta as duas versões sozinho.

Como confirmar: a própria mensagem lista os campos que mudaram no servidor. Para ver a diferença completa:

lumo diff flow:5101 --include-remote

O lumo diff sem --include-remote compara só o arquivo com o cache e não mostra a mudança do servidor.

Conserto: escolha um dos três caminhos.

Você quer	Faça
Ficar com a versão do servidor e descartar a sua	lumo pull flow:5101 --discard-local
Juntar as duas	Guarde a sua versão (commit no Git ou cópia do arquivo), rode lumo pull flow:5101 --discard-local, reaplique as suas mudanças sobre o arquivo novo e dê lumo push flow:5101
Sobrescrever o servidor com a sua	lumo push flow:5101 --force-ours

CAUTION

--force-ours apaga o que a outra pessoa gravou, sem volta. Use só depois de ver a diferença e ter certeza de que ela não importa. Com --no-input ou --format json, o CLI exige também --i-know-what-im-doing.

Repetir o mesmo push não resolve: o drift é uma diferença real e continua lá até você escolher um lado.

<n> resource(s) have local modifications. Use --discard-local to overwrite, or push first.

Código de saída 4, no pull.

Causa: você pediu um pull e há arquivos editados que ainda não foram enviados. O pull sobrescreveria esse trabalho, então para.

Como confirmar: lumo status lista esses arquivos em Modified locally. lumo pull --dry-run mostra o que seria trazido, pulado ou dado como conflito, sem escrever nada.

Conserto: envie primeiro (lumo push), restrinja o pull aos recursos que você não editou (lumo pull app:7302) ou, se quiser jogar fora as edições, use --discard-local.

Código de saída 14 no push

Causa: entre a conferência e a gravação, outra escrita chegou ao servidor. O push grava com a condição de que o recurso ainda esteja na versão do seu cache, e o servidor recusou porque não estava.

Conserto: rode lumo fetch flow:5101, veja a diferença com lumo diff flow:5101 e dê push de novo. Se o push voltar com drift, siga a seção acima.

<tipo>:<id>: field alias(es) disappeared from fields[]

Código de saída 14, no push de um Cadastro (writeback).

Causa: um item saiu de fields[], ou o alias dele mudou. No Cadastro, fields[] é o esquema da tabela: tirar um campo apaga a coluna e os dados dela. O CLI não sabe se você renomeou ou apagou, então recusa.

Conserto: diga o que foi no próprio comando.

lumo push writeback:412 --rename META=META_MENSAL   # renomeou: preserva os dados
lumo push writeback:412 --allow-drop META           # apagou: a coluna e os dados somem

O alias do Cadastro inteiro (a chave alias no topo do corpo) é recusado sempre: ele é o nome físico da tabela e outros Cadastros apontam para ele.

<tipo>:<id> is published (deskId=<n>) and cannot be edited directly

Código de saída 9, no push.

Causa: o recurso está publicado numa Mesa. Dataflow publicado não aceita push. Aplicação publicada aceita só alguns campos; para ela a mensagem é app:<id> is published (deskId=<n>): <campos> requires clone→publish. e diz também quais campos teriam passado.

Conserto: clone, edite o clone e publique por cima do original:

lumo flow clone flow:5101 --name "Fato Vendas (ajuste)"
# edite o arquivo do clone e dê push nele
lumo flow publish flow:<id-do-clone> --desk 31

Os campos que uma Aplicação publicada aceita sem clone estão em Conceitos.

no STATE entry for <tipo>:<id>; run `lumo fetch` first

Código de saída 12.

Causa: o CLI não tem cache desse recurso. Acontece com workspace vindo de um clone do Git (o cache não é versionado) e com recurso criado no servidor depois do seu último fetch.

Conserto: lumo fetch <tipo>:<id> e repita o comando. Num clone limpo, leia antes o aviso em Lumo CLI em CI: o fetch seguido de push sobrescreve o servidor sem detectar drift.

Pushed (partial)

O push gravou e saiu com código 0, mas o servidor manteve o próprio valor em algum campo, que aparece na lista Ignored by server com o valor que ficou. São campos do servidor ou que não se editam naquele recurso, como o deskId ou o nome de uma coluna de tabela. O arquivo já foi reescrito com o que o servidor guardou.

Conserto: não repita o push. Corrija a causa: o nome da coluna, por exemplo, muda no nó do Dataflow que alimenta a tabela.

lumo status lista arquivos em Orphaned ou Out of scope

Orphaned são arquivos de recursos apagados no servidor. O fetch os deixa no disco para você recuperar um engano. Não dê push nem lumo new neles; para limpar todos, lumo pull --prune.

Out of scope são recursos que saíram do seu acesso, como os de uma Mesa revogada. Eles continuam existindo no servidor; o push sem argumento os pula. Não recrie: peça o acesso de volta se precisar deles.

Relacionado

• Conceitos
• Comandos e códigos de saída