Larges pushes fail, because they take too long
まだ誰も着手していません。
評価
- 難易度
- 5/5
- 見積もり時間
- 1週間以上
- 初心者へのやさしさ
- 35/100
調査の方向性
HgResumeApi.php から始め、特に unbundle フローと isComplete チェックを確認してから、incoming、unbundle、lockfile の処理に関する HgRunner.php と AsyncRunner.php を読みます。retry の経路を理解するために、Chorus の timeout リファレンスを確認します。リクエストがタイムアウトした後でも、大きな push を例外なしで再試行でき、unbundle の処理が完了するか意味のあるレスポンスを返せれば完了です。
索引モデルが issue の本文から書いたものです。
説明
We recently had a push of almost 2GB (surprisingly it only took about 3 min for the client to upload it).
Here's an overview of when things broken:
It failed on the last chunk, because that's when the server actually starts doing the heavy lifting: trying to apply the commit.
And here's what I think/know happened:
- Chorus sends the last chunk
- The resumable server detects that it's the last chunk
- It calls unbundle
- Which calls
hg incoming, which takes ~3.5m (it gets logged to/var/cache/hgresume/<transaction-ID>.bundle.incoming.async_run)
- Because the request takes so long
- Chorus cancels the push request after 30s (so Lexbox returns a 499)
- It's also fairly likely that PHP kills the script, because it takes longer than 30s and/or, because it was cancelled.
- It's also fairly likely that Cloudflare/the web server tear down the script process 🤷
- So, presumably the PHP script gets torn down while it's waiting for the
hg incomingcommand to finish (which does finish, because it's in its own process) - Because the PHP script gets torn down, no work actually happens: it never gets to running the command
hg unbundleand creating a lockfile for that command (A lockfile is created forhg incoming, but that's a seperate file) - Because the lockfile doesn't get created, when Chorus retries the push-bundle, the server throws an Exception
Do we want to allow big pushes like this? I think so! So how:
- It's fine if Chorus times out as long as the job actually happens and we returns a more meaningful response. The code tries to return a 200, but fails, because the lockfile it's expecting doesn't exist. The exception is good, because a missing lockfile means nothing is happening.
So we either need to:
- Move more stuff into an external command that doesn't get torn down 🙁
- Prevent the PHP script from getting torn down (e.g. move large pushes to a Lexbox Job and make sure we turn off everything that might kill a long PHP script)
- Make the retries smarter and have them pick up where the last one died
I think 3 sounds like the best bet. Something like:
- Replace the exception-throwing
isCompletecheck, with something that anticipates this senario:- If there's no lock file retry the unbundle
- In the unbundle, detect if
hg incomingalready ran and if so:- Do the necessary validation
- Then start
hg unbundle
- 主要言語
- C#
- スター
- 0
- フォーク
- 1
- PR マージ指標
- 30日以内にマージされた PR はありません
環境構築
- Dockerfile または Docker Compose ファイルあり
- プルリクエストのテンプレートなし
- コントリビューションガイドなし
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
sillsdev/hgresume のほかの issue
-
難易度 2/5 1〜3時間 初心者へのやさしさ 68/100
-
難易度 3/5 半日 初心者へのやさしさ 45/100
-
難易度 3/5 半日 初心者へのやさしさ 72/100
-
難易度 1/5 1時間未満 初心者へのやさしさ 50/100
-
難易度 4/5 3〜5日 初心者へのやさしさ 35/100
sillsdev/hgresume の issue をすべて見る
似ている issue
-
good first issue help wanted
難易度 2/5 1〜3時間 初心者へのやさしさ 65/100
-
untriaged
難易度 2/5 1〜3時間 初心者へのやさしさ 72/100
dotnet/dotnet-api-docs#13210 ·
メンテナーはふだん 1 日以内に返信
-
aspnet-core/svc doc-enhancement mvc/subsvc Pri2
難易度 2/5 1〜3時間 初心者へのやさしさ 72/100
dotnet/AspNetCore.Docs#38016 ·
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 64/100
HicServices/RDMP#2398 ·
-
area-drawing platform/android t/bug
難易度 2/5 1〜3時間 初心者へのやさしさ 70/100
dotnet/maui#39676 · コメント 1 件 · リアクション 1 件 ·
メンテナーはふだん 1 日以内に返信