Jest: プロセス間のキャッシュ書き込み競合状態

これは関係ありませんか？ https://github.com/facebook/jest/pull/4432

私はそうは思わない。 私たちのリポジトリに見られるケースは、まったく同じファイルが2つの異なるプロセス（並列実行中）でモックされ、1つのプロセスでファイルがロックされているためにキャッシュ書き込み操作が失敗することだと思います。 そのチケットは、同じ内容の異なるファイルに関するもののように見えます。 私たちがホストしているリポジトリには、この問題に遭遇したケースはありません。

基本的に、テストで同じ問題が発生します。 再現する簡単な方法の1つは、jest cacheDirectoryを削除して、次の実行時にキャッシュを強制的に生成することでした。
`` `テストスイートの実行に失敗しました

jest: failed to cache transform results in:

C：/ myniceproject / src / jest-cache / jest-transform-cache-b2e8f1f700b9bd266a0d27bb01b47a2b-34a7e3d71d38ff01f65fdb5abdf5126b / 3f / settingsProvider_3f1439e55275a95ecfdb7dcb432f7958
失敗メッセージ：EPERM：操作は許可されていません。名前を変更してください
'C：\ myniceproject \ srcjest-cachejest-transform-cache-b2e8f1f700b9bd266a0d27bb01b47a2b-34a7e3d71d38ff01f65fdb5abdf5126b \ 3f \ settingsProvider_3f1439e55275a95ecfdb7dcb432f7958.1630729137
->
'C：\ myniceproject \ srcjest-cachejest-transform-cache-b2e8f1f700b9bd266a0d27bb01b47a2b-34a7e3d71d38ff01f65fdb5abdf5126b \ 3f \ settingsProvider_3f1439e55275a95ecfdb7dcb432f7958' `

同じ問題があり、それを回避する方法を見つけることができません。 ジェストは基本的にこのように使用できません。

20.0.4から21.2.0に更新しようとしていますが、ビルドサーバーで次のエラーが発生します。

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)

私は今、同じ問題のテストがランダムに壊れています。

--runInBandフラグを使用してテストを実行すると、予想どおりすべてがOKになります。

私は同じ問題をかなり一貫して見ることができます：

  ● 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)

冗談21.2.1
ノード6.11.1
OSウィンドウ

--no-cacheは役に立ちjest-transform-cacheはまだ書き込まれています。 役立つのは--runInBandだけです。これは、大規模なプロジェクトにはほとんど受け入れられません。

問題の診断に役立つことはありますか？ 再現ケースを作成する必要がありますか？

このエラーは重大ですか？ テストスイート全体を削除するのではなく、警告として扱うことはできますか？ バックオフして再試行する方法はありますか？

小さな再現があるといいでしょう

これが再現です： https ：
babel-jestを介してlodash-esを効果的に実行し、変換キャッシュにデータを入力します。
これは、2つの異なるマシン（Win8.1とWin10）で80％の確率で失敗します。
--no-cacheを削除すると、100％失敗します。 --runInBandを追加すると、0％になります。

（好奇心からWin10のWSLで実行しようとしましたが、Posix APIを使用して問題を再現することはできません）

これはWindowsで起こっているだけですか？ 仮想マシン以外のWindowsマシンにアクセスできないため、デバッグが最も簡単ではありません...

@ jeanlauliac write-file-atomic 4088にwrite-file-atomicを追加しましたが、手伝っていただけませんか？

この問題は、 https：//github.com/npm/write-file-atomic/issues/10およびhttps://github.com/npm/write-file-atomic/pull/22と非常によく似てい

procmonトレースを実行しただけです。問題の例を次に示します。

時刻| プロセス名| PID | 操作| パス| 結果| 詳細
-| -| -| -| -| -| -
16：54：43.2304011 | node.exe | 7624 | SetRenameInformationFile | ... \ constant_ee286bbcf367680ce61a90e506522f92.82986661 | 成功| ReplaceIfExists：True、ファイル名：... \ constant_ee286bbcf367680ce61a90e506522f92
16：54：43.2305499 | node.exe | 8208 | SetRenameInformationFile | ... \ constant_ee286bbcf367680ce61a90e506522f92.103872574 | アクセスが拒否されました| ReplaceIfExists：True、ファイル名：... \ constant_ee286bbcf367680ce61a90e506522f92

ご覧のとおり、2つのプロセスが互いに1ミリ秒以内に同じファイルの名前を変更しようとしており、2番目のプロセスは失敗します。

npm / write-file-atomic＃22はwriteFile()の非同期バージョンに対応していると思いますが、 writeFileSync()は引き続き影響を受けます。

同じファイルに対してworker-farmでwrite-file-atomicを使用するだけで、どういうわけか失敗することを示す再現を作成することは可能でしょうか？ そのプロジェクトに対して問題を開くのは素晴らしいことです。修正が必要なのはそこだと思います。

または、jest内で、同じエラー（appveyor CIがあります）を示すテストを作成できれば、それも開始になる可能性がありますか？

このエラーが発生した場合にどのような動作が必要かさえわかりません。 書き込みを再試行しますか？ テストを再実行しますか？ テストファイル全体？

OK、別の再現を作成してみます。 複数のプロセスを生成し、キャッシュを無効化/クリーンアップし、失敗するまで実行し続ける必要があるため、jestテストを作成できるかどうかはわかりません。

このエラーが発生した場合にどのような動作が必要かさえわかりません。

まず、 --no-cacheがオンの場合でも、キャッシュにデータが入力されるべきではないため、この問題は発生しないはずです。
次に、同期操作を正しく再試行できるかどうかわかりません- writeFileSync()代わりにwriteFile()を使用することは可能ですか？ そうすれば、 write-file-atomicは自動的に再試行する必要があります（確認のためのテストを作成します）。

まず、 --no-cacheがオンの場合でも、キャッシュにデータが入力されるべきではないため、この問題は発生しないはずです。

これは良い点であり、個別に修正する必要があります。 そうすれば、 --no-cacheは少なくとも回避策になります。

次に、同期操作を正しく再試行できるかどうかわかりません- writeFile()代わりにwriteFileSync() writeFile()を使用することは可能ですか？

@cpojerは、同期しないようにすることについて考えていますか？ それがどのようにスケーリングするかわからない。 または、これを修正する方法について別のアイデアがある場合

• --no-cacheは、実際には--reset-cacheに似ています。 これは、既存のキャッシュを使用しないことを意味しますが、それでもキャッシュを書き込みます。 それを保持したいと思います。
• これらの操作は、ユーザーコードのrequire呼び出し中に発生するため、同期する必要があります。そのため、これを変更することはできません。

これがworker-farmとwrite-file-atomicのもうwrite-file-atomicつの再現です： https ：

これまでの調査結果：同期バージョンは期待どおりに失敗しますが、驚くべきことに非同期バージョンも失敗します。 これは、おそらく同じプロセスで実行される場合にのみ再試行キューを実装することを意味しますが、この場合は役に立ちません。

それを保持したいと思います。

新しい旗？ 非常に誤解を招く名前です。 また、たとえばCIでは、キャッシュが必要になることはめったにないため、リソースが無駄になります。 または、1回のテスト実行で生成されたキャッシュが--no-cache間に使用され、既存のキャッシュのみが無視されますか？

これがworker-farmとwrite-file-atomicのもうworker-farmつの再現です

驚くばかり！ write-file-atomicに対する問題を開くことができますか？ 修正が必要なように感じます。そうでない場合（一度に複数のプロセスを作成することをサポートしたくない場合）、私たちの側で再検討できます。 WDYT？

私がローカルで試した、機能しているように見えるパッチは、同じ内容のファイルに名前を変更しようとした場合のエラーを無視しています。 別のプロセスがレースに「勝った」ことを意味するだけなので、それを無視して先に進むことができます。

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 、確かに、私は問題を提出します。

@cpojer 、このエラーを飲み込んだり無視したりして、警告として扱うことはできますか？ これは、ファイルがすでに書き込まれており、データが失われてはならないことを意味します。

アップストリームの問題：npm / write-file-atomic＃28

これは、「名前の変更」がWindowsでのアトミック操作ではないことを意味すると思います。したがって、 write-file-atomicによる仮定を破ります。 Windows APIレベルで有効にできるフラグがない限り、これは、Windowsでアトミックな書き込み/名前の変更を完全に行うことが不可能であることを意味する可能性があります。

@jwbayあなたの解決策は私には合理的に見えます！ 👍ただし、 indexOfを使用する代わりに、 e.code === 'EPERM'使用します（より堅牢で、特定のメッセージに依存しません）。 値を確認するためにファイルを再度読み取る必要はないと思います。これにより、追加の同時実行の問題が発生する可能性があります（たとえば、ファイルがさらに別のプロセスによって同時に書き込まれている場合）。 PRを送っていただけませんか。

「ファイル同期を書き込むように求められたが、非同期で書き込むためにすでにキューにある場合は、ベイルアウトする」（おそらくオプションを使用して）の行に沿ってwrite-file-atomic PRの作業を開始しようとしていました。動作をオンに切り替えます）。 しかし、これをJestレベルで処理できれば、急ぐことはありません。 cc @jeanlauliac

「ファイル同期を書き込むように求められたが、非同期で書き込まれるキューにすでにある場合は、ベイルアウトする」という行に沿って、write-file-atomicのPRの作業を開始しようとしていました（おそらく、動作をオンにします）。

このロジック（ローカルキュー）を追加しても問題は解決しないと思います。これは、ほとんどの場合、異なるプロセスが同じファイルに書き込もうとした（名前を変更した）ときに発生するためです。

並行性の問題を完全に修正するには、キャッシュの実行方法を再検討する必要がある場合があります。たとえば、キャッシュにアクセスする単一のプロセスがあり、ある種のIPCを介して通信します。 memcachedなどの既存のキー/値ストアシステムが便利な場合があります。

このロジック（ローカルキュー）を追加しても問題は解決しないと思います。これは、ほとんどの場合、異なるプロセスが同じファイルに書き込もうとした（名前を変更した）ときに発生するためです。

ああ、私はおそらくその時問題を誤解しました。 私の読み方では、ライブラリにはすでに非同期リクエストに対して適切に機能するキューイングメカニズムがありますが、同期リクエストを混在させると、衝突が発生する可能性があります。

上記のプルリクエストでこの問題を解決できるはずです。 少なくともそれは私のためにそれをしました！

@mekwall、私は彼らが使用していると思うrename()での非同期バージョンwriteFile() 、そしてそれはまだ私のテストで失敗しますhttps://github.com/asapach/write-atomic-issue。 私のリプロを実行してみてください。 あなたの変更はこの問題が起こる可能性を最小限に抑えるかもしれないと思いますが、それを完全に排除するわけではありません。

@asapach私の変更を試してみましたか？ 何度か試しましたが、変更を加えてもEPERM: operation not permitted, renameを取得できませんでしたが、変更を加えなくても毎回取得できました。

@mekwall 、

または、技術的には失敗しませんが（同期フローが中断されないため）、コンソールにはEPERMエラーが散らばっています。

@asapachあなたが抱えている問題を見つけました。 graceful-fsポリフィルにあります。 このPRに修正を投稿しました： https ：

@mekwall 、はい、これは問題に対処しているようです-同期バージョンと非同期バージョンの両方でエラーはもうありません。
問題は、 fs.unlinkSync(tmpfile)が呼び出されないため、一時ファイルが削除されないことです： https ：

@asapach graceful-fs名前変更にリンク解除を追加しましたが、それが正しい方法かどうかはわかりません。 Afaik fs.renameはMoveFile関数を使用しているため、ソースを宛先にコピーすることはできません。 ソースは名前を変更するだけで、ソースと宛先が同時に存在することはありません。

@mekwall 、それは少し役に立ちますが、場合によっては、ワーカーが早期に終了した場合（すべての作業が完了したため）、クリーンアップを待機しないため、一部のファイルはクリーンアップされません。 非同期バージョンは正常に機能しているようです。

@asapach期待どおりに機能していません。 ノードの内部に飛び込んで、ノードが実際にどのように機能しているか、および意図された動作がどうあるべきかを理解する必要があります。 graceful-fsの要点は、すべてのプラットフォームで同じように機能することだと思います。そのため、さらに深く掘り下げていきます。 少なくとも私たちは犯人を見つけました:)

@asapach私は気づいた私のPRのためにwrite-file-atomicでしょうではない仕事、私は追加することによって、別のアプローチを取ったので、 fs.renameSyncでgraceful-fsと同じ回避策とfs.renameしかし、ブロッキング。 これにより、テストは期待どおりに機能します。

@mekwall 、ありがとう、私は私の両方の再現ケースであなたの変更を確認しました、そしてそれらのどれも失敗しません。
マイナス面としては、同期のためのCPUとディスクの使用量が増えると思いますが、おそらく予想されます。

これを手に取って修正するのを手伝ってくれた多くの人々に感謝します。 大変感謝いたします！ ❤️うまくいけば、graceful-fsの修正が正しいものであり、リリースされます。

@SimenBどういたしまして！ 私たちは仕事でこれに苦しんでいるので、私は私のチームによってこれを調査する時間がありました。 変更は多くのパッケージに影響するため、受け入れられるまでに時間がかかる可能性があります：/

この回避策がいつリリースされるかについて何か考えはありますか？

@cpojer閉鎖された理由について、もう少し情報を

申し訳ありませんが、修正はまだgraceful-fsに到達していないようです:(

複数の人がhttps://github.com/isaacs/node-graceful-fs/pull/119を使用すると問題が解決することを確認できますか？

糸の解像度を使用してフォークを使用できます。https：//yarnpkg.com/en/docs/selective-version-resolutionsを参照して

例えば

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

@SimenB少なくとも、私にとっては問題は解決します😄

+1私にとっても。

@SimenBまた、私の問題を修正し、

編集：実際には、それは私の開発ラップトップでは機能しましたが、ビルドサーバーでは機能しませんでした。 それは糸1.2.1を実行していますが、多分それが理由ですか？

[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)

ヤーン1.0.0で十分ですが、アップグレードしてみる価値はありますが

解決策を入れようとしましたが、それでも失敗します。 ただし、ENOENT違反と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)

そして

    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ビルドサーバーはWindowsを実行していますか？ graceful-fsの修正はWindowsのみを対象としているため、LinuxベースのOSでは発生しないはずです。

@mekwallはい、 2012R2です

これは私にとって大きな問題であり、2016年11月以降、 graceful-fs何も起こっていません。 ですから、 @ mekwallが提供した修正が-iフラグと解決策以外に使用できる一時的な解決策はありますか？

--runInBandは@frenicでは機能しませんか？

これは-iと同じで、はい、機能します。 しかし残念ながら、大規模なプロジェクトでは長期的には持続可能ではありません。

自分でフォークして公開できると思いますが、修正がすべての人に役立つとは思えません

私は同じ状況にありますが、私の場合、-runInBandは機能しません。

graceful-fsオーバーライドを最新バージョンのJestで確認しましたが、残念ながら、最後にテストしてから、信頼性が高くないようです。 大規模なテストスイートで競合状態に陥る可能性はまだゼロではありません。

このスレッドをスクロールした後、 yarnを使用して解決策を見つけました。 代わりにnpmを使用する解決策はありますか？

これまでのところ、パッチを適用したバージョンのgraceful-fsをpackage.jsonに追加するだけで、かなり幸運に恵まれました。 npmとyarnで動作します。

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

こんにちは、

何らかの理由で、このエラーはJenkinsから実行した場合にのみ発生し、ローカルで実行した場合には発生しません（同じマシン/フォルダーなどでも）
@jsheetzatiのソリューションは（npmを使用して）私たちにも機能していますが、結局のところパッチです。 これを永続的に解決するためのETAはありますか？

ありがとう、
Mor

Jenkinsからjestを実行しているときにも、この問題が発生します。 --runInBandオプションは、単一のジョブの実行中の失敗を回避するのに役立ちますが、複数のビルドを並行して実行すると、jestは失敗します。
回避策として、ロック可能なリソースプラグインを使用して、 --runInBandオプションを維持しながら、 jestつの
このコメントが誰かに役立つことを願っています。

@nyrkovalex説明している問題を回避するために行うことは、 Jestのキャッシュディレクトリオプションを使用して、キャッシュがワークスペース間で共有されないようにすることです。

これを行うには、 cacheDirectory: '<rootDir>/.jest-cache'を設定するJestプリセットを公開し、すべてのパッケージでそれが使用されるようにします。 その場合は、必ず.jest-cacheを.gitignoreに追加してください。

そのオプションを追加する前に、Jenkinsエージェントごとに16のエグゼキュータ間でグローバルJestキャッシュを共有した結果、いくつかの問題が発生しました。 ロック可能なリソースを使用すると、前述の問題を防ぐこともできますが、Jenkinsエージェントを潜在的に使用していないため（Jestテストがボトルネックになるため）無駄になります。

@ anescobar1991そのオプションは間違いなくより良い解決策です、私たちはそれを使用することを検討します。
ヒントをありがとう！

こんにちは、

私たちはgradleを使用してnpmを実行し（理由は聞かないでください:)）、それとJenkinsの組み合わせはキラーです。
私たちは試しました：

1. キャッシュをグローバルキャッシュではなくローカルディレクトリに設定する
2. --runInBandを使用する
3. エージェントで実行されているジョブは1つだけで、並列ジョブはありません
4. gradleテストの実行--max-workers1（-parallelを使用しない）

すべて同じエラーで失敗します。
私たちのために働く唯一の解決策は@jsheetzatiによるもの

私たちはおそらくその修正でフォークして公開することができます

それは素晴らしいでしょう...

私はこの問題をたくさん抱えており、優雅なfsのパッチは私のために働いた。 だから私はこの修正をいただければ幸いです。

graceful-fsをいじる回避策として、競合状態を回避するために、各ワーカープロセス/スレッドに独自のキャッシュディレクトリを与えることはできませんか？

おそらく遅いですが、CIサーバーで--runInBandを使用する必要があり、それははるかに悪いことです。

誰かが私に適切なファイルを教えてくれるなら、私はパッチを書こうとするかもしれません。 私は冗談の源をナビゲートするのに本当に苦労しています。

それが何であるかはわかりませんが、それは数週間、おそらく数ヶ月であり、私はもう失敗を観察していません。 しばらくの間jest22.4.2を使用していて、最近22.4.4にアップグレードしました。 他のさまざまなパッケージも更新しました。

チップインするだけです-これは、Windows JenkinsCIサーバー上のjest23.6で見られます。

• --runInBandは機能しますが、テスト時間が2倍になるので、あまり良くありません。プッシュする前にテストを実行しているので、チームメンバーを非常に悲しくせずにこれを有効にすることはできません。
• @jsheetzati （https://github.com/facebook/jest/issues/4444#issuecomment-370533355）で言及されているように、 package.json graceful -fsオーバーライドは機能しますが、少しハックです。

graceful-fsはこれについてあまり行っていないので（https://github.com/isaacs/node-graceful-fs/pull/131は昨年7月以来アクションを見ていません）、おそらくフォークする時が来ました？ 私はそこにナグコメントを追加しましたが、誰かが突然これを整理することにジャンプすることを期待していません） '：

同じ問題が発生していますが、エラーメッセージが異なります
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

--runInBandを指定してjestを実行しても、最初は問題が解決しないようですが、次の実行後にのみエラーなしで実行されます。

TFSビルドの一部としてWindows10 EnterpriseVMで実行されます。

@EthanSankinは、リンクされた

私はこれらの問題を解決するはずのgraceful-fs交換に取り組んでいます。 現在アルファ版ですが、アーリーアダプターを獲得するのは素晴らしいことです： https ：

古いバージョンのwrite-file-atomicに戻すと、問題が解決しました。

@moizghどのバージョンからどのバージョンへ？

@moizghどのバージョンからどのバージョンへ？

2.4.2から2.3.0

@iarnaは、som回帰が導入されたようです。

また、この問題に遭遇しましたが、より良い/永続的な修正への洞察はありますか？

これは、ここ数か月で再び始まりました-ウィンドウ-非常に断続的です。

write-file-atomicはもはやgraceful-fsを使用しません-多分それはそれと関係がありますか？