Jest: condição de corrida de gravação de cache nos processos

Isso não está relacionado? https://github.com/facebook/jest/pull/4432

Eu não acredito nisso. Acredito que o caso que vemos em nosso repo é exatamente o mesmo arquivo sendo simulado para 2 processos diferentes (durante a execução em paralelo), o que faz com que a operação de gravação de cache falhe porque um processo está com o arquivo bloqueado. Esse tíquete parece mais sobre arquivos diferentes com o mesmo conteúdo. Não temos nenhum desses casos nos repositórios que hospedamos em que encontramos esse problema.

Basicamente, encontramos o mesmo problema com nossos testes. Uma maneira fácil de reproduzir era remover jest cacheDirectory para forçar a geração do cache na próxima execução.
`` `O conjunto de testes falhou ao executar

jest: failed to cache transform results in:

C: / myniceproject / src / jest-cache / jest-transform-cache-b2e8f1f700b9bd266a0d27bb01b47a2b-34a7e3d71d38ff01f65fdb5abdf5126b / 3f / settingsProvider_3f1439e55275795a95ddb795a95
Mensagem de falha: EPERM: operação não permitida, renomear
'C: \ myniceproject \ srcjest-cachejest-transform-cache-b2e8f1f700b9bd266a0d27bb01b47a2b-34a7e3d71d38ff01f65fdb5abdf5126b \ 3f \ settingsProvider_3f1439e55275a95ecfdb7dcb432f7958.1630729137'
->
'C: \ myniceproject \ srcjest-cachejest-transform-cache-b2e8f1f700b9bd266a0d27bb01b47a2b-34a7e3d71d38ff01f65fdb5abdf5126b \ 3f \ settingsProvider_3f1439e55275a7e3d71d38ff01f65fdb5abdf5126b \ 3f \ settingsProvider_3f1439e55275a7e3d71d38ff01f65fdb5abdf5126b \ 3f \ settingsProvider_32f1439e55275a7e495db495d95db

Tendo o mesmo problema e não consigo encontrar uma maneira de contornar isso. Jest é basicamente inutilizável para nós assim.

Estamos tentando atualizar para 21.2.0 de 20.0.4 e agora temos o seguinte erro em nossos servidores de compilação:

Test suite failed to run
[13:46:50]
[13:46:50]    jest: failed to cache transform results in: C:/TeamCity/buildAgent/temp/buildTmp/jest/jest-transform-cache-c60bb8ad55f1dbc29115038800657f2f-4895fc34da3cd9ad1e120af622bca745/3b/fe-selectors_3b56db772e798e2e4d0c9fc7c9e4a770
[13:46:50]    Failure message: EPERM: operation not permitted, rename '...\jest\jest-transform-cache-c60bb8ad55f1dbc29115038800657f2f-4895fc34da3cd9ad1e120af622bca745\3b\fe-selectors_3b56db772e798e2e4d0c9fc7c9e4a770.1701848979' -> '...\jest\jest-transform-cache-c60bb8ad55f1dbc29115038800657f2f-4895fc34da3cd9ad1e120af622bca745\3b\fe-selectors_3b56db772e798e2e4d0c9fc7c9e4a770'
[13:46:50]      
[13:46:50]      at Object.fs.renameSync (fs.js:772:18)
[13:46:50]      at Function.writeFileSync [as sync] (node_modules/write-file-atomic/index.js:192:8)

Agora estou tendo o mesmo problema, os testes são quebrados aleatoriamente.

Se eu executar os testes com a sinalização --runInBand, como esperado, está tudo OK.

Posso ver o mesmo problema de forma bastante consistente:

  ● Test suite failed to run

    jest: failed to cache transform results in: .../jest-transform-cache-...
    Failure message: EPERM: operation not permitted, rename '...' -> '...'
        at Error (native)

      at Object.fs.renameSync (fs.js:810:18)
      at Function.writeFileSync [as sync] (node_modules/write-file-atomic/index.js:192:8)

jest 21.2.1
nó 6.11.1
SO Windows

--no-cache não ajuda e jest-transform-cache ainda está sendo escrito. A única coisa que ajuda é --runInBand , o que dificilmente é aceitável para grandes projetos.

Podemos fazer algo para ajudar a diagnosticar o problema? Devo criar um caso de reprodução?

Este erro é crítico? Isso pode ser tratado como um aviso em vez de derrubar todo o conjunto de testes? Existe uma maneira de recuar e tentar novamente?

Ter uma pequena reprodução seria ótimo

Aqui está a reprodução: https://github.com/asapach/jest-cache-issue/
Ele efetivamente executa lodash-es por meio de babel-jest para preencher o cache de transformação.
Isso falha para mim 80% das vezes em duas máquinas diferentes (Win8.1 e Win10).
Se você remover --no-cache ele falhará 100% das vezes. Adicionar --runInBand reduz para 0%.

(Por curiosidade, tentei executá-lo em WSL no Win10 e o problema não é reproduzível usando a API Posix)

Isso está acontecendo apenas no Windows? Não tenho acesso a máquinas Windows além das máquinas virtuais, então não é a mais fácil de depurar para mim ...

@jeanlauliac você adicionou write-file-atomic no # 4088, você poderia ajudar?

Este problema é muito semelhante a https://github.com/npm/write-file-atomic/issues/10 e https://github.com/npm/write-file-atomic/pull/22.

Acabei de executar um rastreamento procmon , aqui está um exemplo do problema:

Hora do dia | Nome do processo | PID | Operação | Caminho | Resultado | Detalhe
- | - | - | - | - | - | -
16: 54: 43.2304011 | node.exe | 7624 | SetRenameInformationFile | ... \ constant_ee286bbcf367680ce61a90e506522f92.82986661 | SUCESSO | ReplaceIfExists: True, FileName: ... \ constant_ee286bbcf367680ce61a90e506522f92
16: 54: 43.2305499 | node.exe | 8208 | SetRenameInformationFile | ... \ constant_ee286bbcf367680ce61a90e506522f92.103872574 | ACESSO NEGADO | ReplaceIfExists: True, FileName: ... \ constant_ee286bbcf367680ce61a90e506522f92

Como você pode ver, dois processos estão tentando renomear o mesmo arquivo com 1 ms um do outro e o segundo falha.

Acho que npm / write-file-atomic # 22 aborda a versão assíncrona de writeFile() , mas writeFileSync() ainda é afetado.

Seria possível criar uma reprodução mostrando que apenas usar write-file-atomic em worker-farm no mesmo arquivo falha de alguma forma? Seria ótimo abrir um problema contra esse projeto, pois acho que é aí que a correção deveria estar.

Ou se você pudesse escrever um teste dentro de jest que mostre o mesmo erro (temos appveyor CI), isso poderia ser um começo também?

Eu nem tenho certeza de qual comportamento queremos em caso desse erro. Tentar escrever novamente? Executar o teste novamente? Todo o arquivo de teste?

OK, vou tentar criar outra reprodução. Não tenho certeza se é possível criar um teste de jest, porque exigiria a geração de vários processos, desabilitando / limpando o cache e continuando executando até que ele falhe.

Eu nem tenho certeza de qual comportamento queremos em caso desse erro.

Bem, em primeiro lugar, o problema nem deve acontecer quando --no-cache está ligado, pois o cache não deve ser preenchido.
Em segundo lugar, não tenho certeza se é possível repetir a operação de sincronização corretamente - é possível usar writeFile() vez de writeFileSync() ? Dessa forma, write-file-atomic deve tentar novamente automaticamente (vou criar um teste para confirmar).

Bem, em primeiro lugar, o problema nem deve acontecer quando --no-cache está ligado, pois o cache não deve ser preenchido.

Esse é um bom ponto e deve ser corrigido separadamente. Dessa forma, --no-cache pode pelo menos ser uma solução alternativa.

Em segundo lugar, não tenho certeza se é possível repetir a operação de sincronização corretamente - é possível usar writeFile() vez de writeFileSync() ?

@cpojer pensa em fazer com que não seja sincronizado? Não tenho certeza de como isso escala. Ou se você tiver outra ideia sobre como consertar isso

• --no-cache é mais parecido com --reset-cache na verdade. Isso significa que ele não usará o cache existente, mas ainda gravará o cache. Eu gostaria de manter isso.
• Essas operações devem ser sincronizadas, porque acontecem durante require chamadas no código do usuário, portanto, não podemos mudar isso.

Aqui está a outra reprodução com worker-farm e write-file-atomic : https://github.com/asapach/write-atomic-issue

Descobertas até agora: a versão de sincronização falha conforme o esperado, mas surpreendentemente a versão assíncrona também falha. Isso significa que eles provavelmente implementam uma fila de repetição apenas quando ela é executada no mesmo processo, o que não ajuda em nosso caso.

Eu gostaria de manter isso.

Nova bandeira? É um nome altamente enganoso. E em, por exemplo, CI você raramente quer o cache de qualquer maneira, então é apenas desperdício de recursos. Ou um cache é gerado dentro de uma única execução de teste usado durante --no-cache , e ele apenas ignora os caches existentes?

Aqui está a outra reprodução com worker-farm e write-file-atomic

Impressionante! Você poderia abrir um problema contra write-file-atomic? Parece que uma correção deve ser feita, caso contrário (eles não querem suportar a gravação de vários processos ao mesmo tempo), podemos revisitar do nosso lado. WDYT?

Um patch que tentei localmente e que parecia funcionar está ignorando o erro se ele vier de uma tentativa de renomear para um arquivo com o mesmo conteúdo. Já que significa apenas que outro processo 'ganhou' a corrida, podemos ignorá-lo e seguir em frente.

const cacheWriteErrorSafeToIgnore = (
  e: Error,
  cachePath: Path,
  fileData: string,
) => {
  if (
    e.message &&
    e.message.indexOf('EPERM: operation not permitted, rename') > -1
  ) {
    try {
      const currentContent = fs.readFileSync(cachePath, 'utf8');
      return fileData === currentContent;
    } catch (e) {
    }
  }
  return false;
};

@SimenB , claro, vou registrar um problema.

@cpojer , esse erro pode ser engolido / ignorado e tratado como um aviso? Isso implica que o arquivo já foi gravado e nenhum dado deve ser perdido.

Problema do upstream: npm / write-file-atomic # 28

Acho que isso significa que "renomear" não é uma operação atômica no Windows, portanto, quebra a suposição feita por write-file-atomic . A menos que haja um sinalizador que possa ser habilitado no nível da API do Windows, isso pode significar que é impossível ter gravações / renomeações atômicas no Windows completamente.

@jwbay sua solução parece razoável para mim! 👍 Em vez de usar indexOf , no entanto, eu usaria e.code === 'EPERM' (mais robusto, não depende de mensagem específica). Não acho que devamos ler o arquivo novamente para verificar o valor, porque isso poderia introduzir problemas adicionais de simultaneidade (por exemplo, se o arquivo estiver sendo gravado por outro processo ao mesmo tempo). Você se importaria de enviar um PR, por favor?

Eu estava prestes a começar a trabalhar em um PR para write-file-atomic ao longo das linhas de "se formos solicitados a escrever uma sincronização de arquivo, mas já está na fila para ser escrito de forma assíncrona, salve" (talvez com uma opção para ativar o comportamento). Mas se estamos felizes em lidar com isso no nível de brincadeira, não vou me apressar. cc @jeanlauliac

Eu estava prestes a começar a trabalhar em um PR para write-file-atomic ao longo das linhas de "se formos solicitados a escrever uma sincronização de arquivo, mas já está na fila para ser escrito assíncrono, resgate" (talvez com uma opção para ativar o comportamento).

Acho que adicionar essa lógica (fila local) não resolveria o problema, porque isso acontece principalmente quando diferentes processos tentam gravar (renomear) no mesmo arquivo.

Para consertar problemas de simultaneidade de uma vez por todas, podemos ter que reconsiderar como fazemos o cache, por exemplo, ter um único processo que acessa o cache, com o qual nos comunicamos através de algum tipo de IPC. Os sistemas de armazenamento de chave / valor existentes podem ser úteis, como memcached .

Acho que adicionar essa lógica (fila local) não resolveria o problema, porque isso acontece principalmente quando diferentes processos tentam gravar (renomear) no mesmo arquivo.

Ah, talvez eu tenha entendido mal a questão então. Do jeito que eu li, a biblioteca já tem um mecanismo de enfileiramento que funciona bem para as solicitações assíncronas, mas se você misturar as solicitações de sincronização _também_ você pode obter colisões.

Minha solicitação pull mencionada acima deve resolver esse problema. Pelo menos fez isso por mim!

@mekwall , acho que eles estão usando rename() na versão assíncrona de writeFile() , e ainda falha em meu teste: https://github.com/asapach/write-atomic-issue. Você poderia tentar executar meu repro? Acho que sua alteração pode minimizar a probabilidade de esse problema acontecer, mas não o elimina completamente.

@asapach Você tentou com minhas mudanças? Porque tentei várias vezes e nunca obtive EPERM: operation not permitted, rename com minhas alterações, mas sempre obtive sem.

@mekwall , sim, ainda falhando com suas alterações (embora de forma assíncrona). (Corrigido abaixo).

Ou melhor, tecnicamente, ele não falha (porque o fluxo de sincronização não é interrompido), mas o console ainda está cheio de erros de EPERM.

@asapach Encontrei o problema que você está tendo. Ele está no polyfill graceful-fs . Eu postei uma correção neste PR: https://github.com/isaacs/node-graceful-fs/pull/119

@mekwall , sim, isso parece resolver o problema - não há mais erros nas versões de sincronização e assíncrona.
O problema agora é que os arquivos temporários não são removidos, porque fs.unlinkSync(tmpfile) nunca é chamado: https://github.com/npm/write-file-atomic/pull/29/files#diff -168726dbe96b3ce427e7fedce31bb0bcR198

@asapach Eu adicionei desvincular a graceful-fs rename, mas não tenho certeza se esse é o caminho certo a seguir. Afaik fs.rename usa a função MoveFile e que não deve copiar a fonte para o destino. A origem deve apenas mudar de nome e a origem e o destino nunca devem existir ao mesmo tempo.

@mekwall , isso ajuda um pouco, mas em alguns casos se o trabalhador for encerrado mais cedo (porque todo o trabalho está feito), alguns arquivos não são limpos, já que não espera pela limpeza. A versão assíncrona parece funcionar bem.

@asapach Não está funcionando como esperado. Preciso mergulhar nas entranhas do nó para descobrir como ele está realmente funcionando e qual deve ser o comportamento pretendido. Acredito que o objetivo do graceful-fs é fazer com que funcione da mesma forma em todas as plataformas, então vou me aprofundar nisso. Pelo menos encontramos o culpado :)

@asapach Percebi que meu PR para write-file-atomic não funcionaria, então usei outra abordagem, adicionando fs.renameSync em graceful-fs com as mesmas soluções alternativas de fs.rename mas bloqueando. Isso faz com que seu teste funcione conforme o esperado!

@mekwall , Obrigado, verifiquei suas alterações em ambos os meus casos de reprodução e nenhum deles falhou.
Acho que o lado negativo é que vejo um aumento no uso de CPU e disco para sincronização, mas provavelmente é esperado.

Muito obrigado pessoal por pegar isso e ajudar a consertá-lo. Muito apreciado! ❤️ Espero que a correção em graceful-fs seja a correta e seja lançada.

@SimenB De nada! Estamos sofrendo com isso no trabalho, então eu tenho algum tempo para investigar isso por minha equipe. As mudanças afetarão muitos pacotes, então provavelmente levará algum tempo para que eles aceitem: /

Alguma ideia de quando essa solução alternativa chegará ao lançamento?

@cpojer poderia fornecer mais algumas informações por que ele está fechado? existe uma correção fornecida? Ainda temos esse problema

Desculpas, parece que a correção ainda não atingiu o graceful-fs :(

Várias pessoas podem confirmar que o uso de https://github.com/isaacs/node-graceful-fs/pull/119 corrige seus problemas?

Você pode usar o fork por meio de resoluções de yarn, consulte https://yarnpkg.com/en/docs/selective-version-resolutions , que deve permitir que você implante a correção para CI etc.

por exemplo

{
  "resolutions": {
    "graceful-fs": "mekwall/node-graceful-fs#a10aa576f771d7cf3dfaee523f2e02d6eb11a89f"
  }
}

@SimenB Isso resolve o problema para mim, pelo menos 😄

1 Para mim também.

@SimenB Também

Edit: Na verdade, funcionou no meu laptop de desenvolvimento, mas não funcionou no servidor de compilação. Mas está rodando o yarn 1.2.1, talvez seja por isso?

[16:47:55][Step 5/8]     jest: failed to read cache file: D:/TeamCity/buildAgent2/temp/buildTmp/jest/jest-transform-cache-c39254d365b4bcb2c90f133d4b359d91-56a1804d8d831b3401a35a7e81857f3b/7e/rafPolyfill_7e7a83ed3f2680ba9aec0e45f59ade5d
[16:47:55][Step 5/8]     Failure message: EPERM: operation not permitted, open 'D:\TeamCity\buildAgent2\temp\buildTmp\jest\jest-transform-cache-c39254d365b4bcb2c90f133d4b359d91-56a1804d8d831b3401a35a7e81857f3b\7e\rafPolyfill_7e7a83ed3f2680ba9aec0e45f59ade5d'
[16:47:55][Step 5/8]       
[16:47:55][Step 5/8]       at readCacheFile (node_modules/jest-runtime/build/script_transformer.js:465:60)

Yarn 1.0.0 deve ser suficiente, mas vale a pena tentar atualizá-lo

Apenas tentei colocar a resolução, mas ainda está falhando para mim. No entanto, tenho violações ENOENT e EPERM:

    jest: failed to read cache file: C:/Users/dev/AppData/Local/Temp/jest/jest-transform-cache-857f905b2da01d52a9d1d17b6772ea4a-3a91587e29d4fef23c6e0cf16b2f5679/7d/index_7d0afc82f0b29ec31c4b5f296cbdee74
    Failure message: ENOENT: no such file or directory, open 'C:\Users\dev\AppData\Local\Temp\jest\jest-transform-cache-857f905b2da01d52a9d1d17b6772ea4a-3a91587e29d4fef23c6e0cf16b2f5679\7d\index_7d0afc82f0b29ec31c4b5f296cbdee74'

      at Object.fs.openSync (../fs.js:653:18)
      at Object.fs.readFileSync (../fs.js:554:33)

e

    jest: failed to read cache file: C:/Users/dev/AppData/Local/Temp/jest/jest-transform-cache-857f905b2da01d52a9d1d17b6772ea4a-3a91587e29d4fef23c6e0cf16b2f5679/c4/std_pb_c403e6e7645c904896b66f44a3e43606
    Failure message: EPERM: operation not permitted, open 'C:\Users\dev\AppData\Local\Temp\jest\jest-transform-cache-857f905b2da01d52a9d1d17b6772ea4a-3a91587e29d4fef23c6e0cf16b2f5679\c4\std_pb_c403e6e7645c904896b66f44a3e43606'

      at Object.fs.openSync (../fs.js:653:18)
      at Object.fs.readFileSync (../fs.js:554:33)

@mreishus Seu servidor de compilação executa o Windows? Porque as correções em graceful-fs serão direcionadas apenas ao Windows, mas não deve acontecer em um sistema operacional baseado em Linux.

@mekwall sim, Windows - mas é o Windows Server 2012 R2

Este é um grande problema para mim e nada aconteceu com graceful-fs desde novembro de 2016 do que posso ver. Portanto, estou ficando bastante pessimista de que a correção fornecida pelo @mekwall não será mesclada tão cedo. Existe alguma solução temporária que possamos usar além do sinalizador -i e da solução alternativa?

--RunInBand não funciona para você @frenic?

Isso é o mesmo que -i e sim, funciona. Mas, infelizmente, não é sustentável no longo prazo para projetos maiores.

Acho que poderíamos fazer um fork e publicar o nosso próprio, mas não parece que a correção funcione para todos

Estou na mesma situação, mas no meu caso, --runInBand não funciona.

Eu verifiquei a substituição de graceful-fs com a versão mais recente do Jest e, infelizmente, não parece mais funcionar tão confiável desde a última vez que testei. Ainda há chance diferente de zero de que ele entre em uma condição de corrida em grandes suítes de teste.

Depois de percorrer este tópico, encontrei uma resolução usando yarn . Existe uma resolução usando npm vez disso?

Tivemos muita sorte até agora apenas adicionando a versão corrigida de graceful-fs ao nosso package.json. Funciona para nós com npm e fios.

"graceful-fs": "https://github.com/mekwall/node-graceful-fs.git#patch-1",

Oi,

Por algum motivo, só obtemos esse erro ao executar a partir do Jenkins, não quando executado localmente (mesmo na mesma máquina / pasta etc.)
A solução de @jsheetzati está funcionando para nós também (usando npm), mas é um patch afinal. Existe um ETA para resolver isso permanentemente?

Obrigado,
Mor

Também temos esse problema ao executar jest do Jenkins. --runInBand ajuda a evitar falhas durante a execução de um único trabalho, mas jest ainda falha ao executar várias compilações em paralelo.
Para contornar o problema, usamos o plugin de recursos bloqueáveis para garantir que apenas um jest processo seja executado ao mesmo tempo, mantendo a opção --runInBand .
Espero que este comentário seja útil para alguém.

@nyrkovalex O que fazemos para evitar o problema que você está descrevendo é usar a opção de diretório de cache do Jest para garantir que o cache não seja compartilhado entre os espaços de trabalho.

Fazemos isso publicando uma predefinição Jest que define cacheDirectory: '<rootDir>/.jest-cache' e nos certificando de que todos os pacotes a usam. Se fizer isso, certifique-se de adicionar .jest-cache a .gitignore .

Antes de adicionar essa opção, teríamos vários problemas como resultado de ter um cache Jest global compartilhado entre 16 executores por agente Jenkins. Usar recursos bloqueáveis também evitará os problemas mencionados, mas é um desperdício, pois você não está usando seu agente Jenkins em todo o seu potencial (pois os testes de Jest se tornam um gargalo).

@ anescobar1991 Essa opção é definitivamente a melhor solução, vamos considerar usá-la.
Obrigado pela dica!

Oi,

usamos gradle para executar o npm (não pergunte por quê :)) e a combinação disso com o Jenkins é matadora.
Nós tentamos:

1. definir o cache para o diretório local em vez do cache global
2. usando --runInBand
3. apenas um único trabalho em execução no agente - nenhum trabalho paralelo
4. executando o teste gradle --max-workers 1 (e não usando --parallel)

Todos falham com o mesmo erro.
A única solução que funciona para nós é a de @jsheetzati - gostaria que isso fosse corrigido formalmente.

Provavelmente poderíamos bifurcar e publicar com essa correção

isso seria demais ...

Eu tenho muito esse problema e o patch para o Graceful Fs funcionou para mim. Então, eu agradeceria essa correção.

Como uma solução alternativa para brincar com graceful-fs, você não poderia simplesmente dar a cada processo / thread de trabalho seu próprio diretório de cache para evitar a condição de corrida?

Provavelmente é lento, mas temos que usar --runInBand em nosso servidor de CI e isso é muito pior.

Se alguém puder me indicar os arquivos certos para examinar, posso até tentar escrever um patch. Eu tenho muita dificuldade em navegar na origem da piada.

Não tenho certeza do que é, mas já se passaram algumas semanas, possivelmente alguns meses, e não observei mais a falha. Estamos usando o jest 22.4.2 há algum tempo e atualizamos para o 22.4.4 recentemente. Também atualizamos vários outros pacotes.

apenas para ajudar - estou vendo isso com o gracejo 23.6 em um servidor Windows Jenkins CI.

• --runInBand funciona, mas dobra o tempo de teste, então não é ótimo, e como temos testes executados antes do envio, não posso habilitar isso sem deixar os membros da minha equipe super tristes
• a substituição graceful-fs em package.json , conforme mencionado por @jsheetzati (https://github.com/facebook/jest/issues/4444#issuecomment-370533355) funciona, mas é um pouco um hack.

Já que graceful-fs não está fazendo muito sobre isso (https://github.com/isaacs/node-graceful-fs/pull/131 não viu ação desde julho do ano passado), talvez seja hora de bifurcar ? Eu adicionei um comentário importuno lá, mas não espero que isso faça alguém de repente começar a resolver isso) ':

Estou tendo o mesmo problema, mas a mensagem de erro é diferente
Failure message: EBADF: bad file descriptor, close

jest: failed to cache transform results in: C:/agent/_work/_temp/jest/jest-transform-cache-2a12bf9796741cb06fb97a276aa09712-7d718cda2d798ae78eb741b3feff799e/7b/test-setup_7bdb1937d8dbbf5088142bc21e74a530
2019-01-24T13:44:55.5496091Z     Failure message: EBADF: bad file descriptor, close

Parece que executar jest com --runInBand não resolve o problema da primeira vez, mas somente após outra execução é executado sem erros.

Executando no Windows 10 Enterprise VM como parte de um TFS Build.

@ EthanSankin, você também pode testar com o PR gracioso-fs vinculado?

Estou trabalhando em uma substituição de graceful-fs que deve resolver esses problemas. Atualmente está em alfa, mas seria ótimo obter alguns adotantes iniciais: https://github.com/mekwall/normalized-fs

reverter para uma versão anterior do write-file-atomic resolveu o problema.

@moizgh de qual versão para qual versão?

@moizgh de qual versão para qual versão?

2.4.2 a 2.3.0

@iarna parece que

Também enfrentando esse problema, alguma ideia sobre uma solução melhor / permanente?

Isso começou novamente para nós nos últimos dois meses - janelas - muito intermitente.

write-file-atomic não usa mais graceful-fs - talvez isso tenha algo a ver com isso?