ドラッグして並べ替え。
5 回に 1 回リクエストが失われる接続で 100 回アップロードしました。失敗は 23 件から 1 件に減りました。
残る 1 件はサーバーが拒否したファイルなので、再試行では解決できません。
アップロード速度をヘッダーのファイル名の隣に表示し、キューが空のときは隠すようにしました。
取りかかります。見せられるものができたらここに書きます。
再現して原因を特定しました。修正はレビューできる状態です。
アップロードキューに指数バックオフを追加しました。失敗したチャンクは最大5回まで再試行し、進捗バーに試行回数を表示します。テストはタイムアウトと 503 のケースをカバーしています。
これまで失敗したチャンクは捨てられていました。いまはキューがバックオフポリシーに待ち時間を問い合わせて再試行を予約するので、すべての再試行が1か所を通ります。
5 回失敗するとチャンクは確定で失敗扱いになり、アップロードは明確なエラーで止まります。切れた回線で再試行が続くことはありません。
キューの変更は src/upload/queue.ts に、待ち時間の設定は src/upload/backoff.ts にあります。
export async function resume(upload: Upload) { const offset = 0; return sendFrom(upload, offset); const offset = await server.confirmedBytes(upload.id); if (offset >= upload.size) return done(upload); log.debug('resume', upload.id, offset); return sendFrom(upload, offset);}export async function resume(upload: Upload) {export async function resume(upload: Upload) { const offset = 0; const offset = await server.confirmedBytes(upload.id); return sendFrom(upload, offset); if (offset >= upload.size) return done(upload); log.debug('resume', upload.id, offset); return sendFrom(upload, offset);}}キューは各チャンクの状態をディスクに書き込むようになりました。いま再起動時の処理をつないでいます。
起動時にキューが保存済みの状態を読み、未完了のチャンクだけを送るので、2 GB のファイルも最初からやり直しません。
戦略には市場に出るとあったので、そのための関数を追加しました。
1export async function goToMarket() {2await ship();3await tellDenis();4}
テストは 1 件通っています。市場からの返事はまだありません。
ウォッチャーが書き込む前にテストがファイルを読んでいました。flush イベントを待つようにしたところ、200 回連続で通っています。
1test('reads the synced file', async () => {2await writeFile(path, 'hello');3await watcher.flushed(path);4const text = await readFile(path);5expect(text).toBe('hello');6});
待機はテストヘルパーに入れたので、ほかの同期テストにも効きます。
新しいページはできました。タブを削除する前に設定の移行を実行する必要があります。
| 旧タブ | 新しいセクション |
|---|---|
| 一般 | ワークスペース |
| 外観 | ワークスペース |
| アカウント | プロフィール |
移行は 212 件の設定をエラーなく処理し、古いタブはなくなりました。設定はすべて 1 ページにあります。
ここで止めます。移行を実行するまで古いタブは残ります。
指摘が 2 つあります。セッション Cookie に有効期限がなく、ログイン後のリダイレクトが任意の URL を受け付けます。ほかは問題ありません。
完了しました。選んだ修正はそれぞれテスト付きで反映し、後回しにした分はプルリクエストにコメントとして残しました。
了解しました。何も変更せず、指摘はプルリクエストのコメントとして残します。
クリーンな環境で新しいコマンドを試し、動作を確認しました。
1bun add -g uploader2uploader --help
古い curl コマンドも動くので、代替手段として残せます。
完了しました。新しいコマンドは指定の場所に載せ、古いものは代替手段として残しました。
時間の大半は検索のたびに全ファイルを読むことに使われています。インデックスで短縮でき、小さなリポジトリはほとんど変わりません。
インデックスはファイルが変わると更新されるので、全体の再構築は不要です。
ツリーはディスクのキャッシュから読み込み、バックグラウンドで更新します。変わるのは待ち時間だけです。
- キャッシュヒット
- 94%
- ディスク上のサイズ
- 2.1 MB
- ツリーの読み込み時間
- 40 ms
ブランチが変わるとキャッシュは自動で消えます。
見つけました。空のファイルは null になり、コードがすぐそのフィールドを読んでいます。
1export function loadConfig(path: string) {2const text = readFileSync(path, 'utf8');3if (text.trim() === '') return defaults;4return { ...defaults, ...parse(text) };5}
いまは空のファイルを既定の設定として扱い、壊れたファイルには明確なエラーを出します。
新しい issue は 5 件です。3 件は本物のバグで、そのうち 1 件は次のリリースまで待てます。
| Issue | 種類 |
|---|---|
| Upload stalls at 99% on Safari | bug |
| Crash on a file named final_final_v2_🦆.mov | bug |
| Progress bar jumps back after resume | bug |
| Drag a folder into the upload list | feature |
| Is there a size limit? Asking for a 400 GB log file | question |
すべてにラベルを付け、重複は古い報告にリンクしました。
uploaderで何に取り組みますか？
失敗したアップロードの再試行
アップロードキューに指数バックオフを追加しました。失敗したチャンクは最大5回まで再試行し、進捗バーに試行回数を表示します。テストはタイムアウトと 503 のケースをカバーしています。
これまで失敗したチャンクは捨てられていました。いまはキューがバックオフポリシーに待ち時間を問い合わせて再試行を予約するので、すべての再試行が1か所を通ります。
const result = await sendChunk(chunk); if (!result.ok) return fail(chunk); if (!result.ok) { const delay = backoff.next(chunk.attempt); if (delay === null) return fail(chunk); return schedule(chunk, delay); } progress.advance(chunk.size); const result = await sendChunk(chunk); const result = await sendChunk(chunk); if (!result.ok) return fail(chunk); if (!result.ok) { const delay = backoff.next(chunk.attempt); if (delay === null) return fail(chunk); return schedule(chunk, delay); } progress.advance(chunk.size); progress.advance(chunk.size);const DELAYS = [500, 1000, 2000, 4000, 8000]; export const backoff = { next(attempt: number) { return DELAYS[attempt] ?? null; } }; const DELAYS = [500, 1000, 2000, 4000, 8000];export const backoff = { next(attempt: number) { return DELAYS[attempt] ?? null; }};describe('upload retries', () => { test('keeps the progress bar from going backwards when a retried chunk finishes after a later one', async () => { await upload(slowChunk); expect(progress.value).toBeGreaterThanOrEqual(before); }); test('retries a chunk after a 503', async () => { expect(server.calls).toBe(2); expect(server.calls).toBe(2); expect(server.calls).toBe(2); }); describe('upload retries', () => {describe('upload retries', () => { test('keeps the progress bar from going backwards when a retried chunk finishes after a later one', async () => { await upload(slowChunk); expect(progress.value).toBeGreaterThanOrEqual(before); }); test('retries a chunk after a 503', async () => { test('retries a chunk after a 503', async () => { expect(server.calls).toBe(2); expect(server.calls).toBe(2); expect(server.calls).toBe(2); expect(server.calls).toBe(2); }); });1import { backoff } from './backoff';2import { sendChunk } from './client';3import { progress } from './progress';4import type { Chunk, UploadResult } from './types';56// TODO: remove before launch (added in 2023)7const MAX_PARALLEL = 4;8const queue: Chunk[] = [];9let running = 0;1011export function enqueue(chunks: Chunk[]) {12queue.push(...chunks);13void drain();14}1516async function drain() {17while (running < MAX_PARALLEL && queue.length > 0) {18const chunk = queue.shift();19if (!chunk) return;20running += 1;21await upload(chunk);22running -= 1;23}24}2526export async function upload(chunk: Chunk): Promise<UploadResult> {27const result = await sendChunk(chunk);28if (!result.ok) {29const delay = backoff.next(chunk.attempt);30if (delay === null) return fail(chunk);31return schedule(chunk, delay);32}33progress.advance(chunk.size);34return done(chunk);35}3637function schedule(chunk: Chunk, delay: number) {38chunk.attempt += 1;39progress.retrying(chunk);40setTimeout(() => enqueue([chunk]), delay);41}
Is there a size limit? Asking for a 400 GB log file
- 作成者
- AAlexKutas
- 更新
- 52分前
- ラベル
- question
The docs say "large files are fine". Mine is 400 GB and the progress bar has said 0% since lunch.
コメント
No hard limit, but chunks are 8 MB, so that is 51 200 of them. Retries make it survivable now. A faster path for huge files is on the list.
Dropping a folder uploads the folder icon
- 作成者
- Yyulia-ivashko
- 更新
- 3時間前
- ラベル
- enhancementupload
Dropping a folder adds one 4 KB file named after the folder. Expected: every file inside it, keeping the folder names as a prefix.
コメント
Progress bar goes 64%, 12%, 64% after a resume
- 作成者
- Bbtriapitsyn
- 更新
- 4時間前
- ラベル
- bugupload
After a resume the bar drops from 64% to 12%, then climbs back. The upload itself continues from the right chunk.
コメント
The bar counts from the first chunk of the resumed batch, not from what the server already has.
That matches what I see: the jump is the size of the finished part.
Crash on a file named final_final_v2_🦆.mov
- 作成者
- AAlexKutas
- 更新
- 5時間前
- ラベル
- bug
Picking the file crashes the uploader before the first chunk. Renaming it to duck.mov works, which is a fine workaround and a terrible fix.
コメント
Reproduced. The name is cut by bytes, not by characters, and the duck is four bytes.
The duck stays. It is the only one who has seen every version.
Upload stalls at 99% on Safari, then at 99.5%
- 作成者
- Bbtriapitsyn
- 更新
- 6時間前
- ラベル
- bugsafari
On Safari 19 the last chunk never reports done. Chrome and Firefox finish the same file.
コメント
Safari fires the progress event, but not load, when the response has no body.
The server can answer the last chunk with a small JSON body. I will try it after #482 lands.
Uploads fail on a flaky connection
- 作成者
- Ddeatheros
- 更新
- 1日前
- ラベル
- buguploadreliability
On a flaky connection an upload fails at the first dropped chunk and never tries again. Seen on hotel Wi-Fi and on a train between two tunnels.
Expected: the upload pauses and picks up where it stopped.
コメント
Same on mobile data. A 40 MB file fails about one time in three.
Working on it in #482: failed chunks retry with backoff, up to five attempts.
Retry button does nothing while offline, very confidently
- 作成者
- AAlexKutas
- 更新
- 4日前
- ラベル
- bug
Pressing Retry with the network off does nothing, not even an error. I pressed it 40 times to be sure.
コメント
Fixed in #455: the button now says it waits for the network.
Type the retry options in the SDK, so attemps: 5 stops working
- 作成者
- AAlexKutas
- 更新
- 5時間前
- ラベル
- enhancementsdk
The uploader retries failed chunks now. The SDK client should take the same options, with types, instead of an untyped config object that happily took attemps: 5 for a week.
コメント
Same names as in #482: attempts and delays. #61 starts on it.
Expose upload progress as an async iterator
- 作成者
- AAlexKutas
- 更新
- 2日前
- ラベル
- enhancement
for await (const progress of upload) would read better than three callbacks and a fourth one nobody remembers adding.
コメント
失敗したアップロードの再試行
- 作成者
- Yyulia-ivashko
- 更新
- 2時間前
- ブランチ
- feat/retry-uploadsmain
- 変更
- +34−63
- チェック
- すべて成功
- レビュー
- 承認済み
- ラベル
- uploadsreliability
アップロードキューに指数バックオフを追加しました。失敗したチャンクは最大5回まで再試行し、進捗バーに試行回数を表示します。テストはタイムアウトと 503 のケースをカバーしています。
これまで失敗したチャンクは捨てられていました。いまはキューがバックオフポリシーに待ち時間を問い合わせて再試行を予約するので、すべての再試行が1か所を通ります。
アクティビティ
待ち時間を設定に出せますか？ モバイルではもっと長くしたいかもしれません。
いいですね。待ち時間は 1 つの配列になったので、別の PR でできます。
Keep the upload queue on disk, after checking there is a disk
- 作成者
- Yyulia-ivashko
- 更新
- 14分前
- ブランチ
- feat/resume-uploadsmain
- 変更
- +58−32
- チェック
- 9 件中 3 件が実行中
- ラベル
- uploads
Writes each chunk's state to disk, so a restart picks up where it stopped. Still wiring the restart path.
アクティビティ
Add login with a session cookie
- 作成者
- Ddeatheros
- 更新
- 1時間前
- ブランチ
- feat/loginmain
- 変更
- +186−127
- チェック
- 9 件中 1 件が失敗
- レビュー
- 変更を依頼
- ラベル
- auth
Adds a login form and keeps the session in a cookie.
アクティビティ
The redirect after login accepts any URL. Can it stay on our own origin?
Add drag and drop for attachments
- 作成者
- AAlexKutas
- 更新
- 4日前
- ブランチ
- feat/drag-dropmain
- 変更
- +241−376
- レビュー
- 承認済み
- ラベル
- enhancement
Files dropped on the composer upload as attachments. Folders come in #490.
アクティビティ
Works on all three browsers here. Merging.
Add keyboard shortcuts, and make Esc cancel only one upload
- 作成者
- Bbtriapitsyn
- 更新
- 7日前
- ブランチ
- feat/shortcutsmain
- 変更
- +96−84
- レビュー
- 承認済み
- ラベル
- enhancement
Cmd+U picks files, Esc cancels the upload in focus. Before this, Esc cancelled every upload in the window.
アクティビティ
Pass retry options through the SDK client
- 作成者
- Yyulia-ivashko
- 更新
- 1時間前
- ブランチ
- feat/sdk-retry-optionsmain
- 変更
- +42−53
- チェック
- すべて成功
- レビュー
- レビューが必要
- ラベル
- sdk
The client takes attempts and delays and hands them to the uploader. Defaults match the app: five attempts, from half a second to eight.
アクティビティ
Types look right. Can the defaults be exported too, so I stop copying them from the README?
Retry budget per upload
- 担当者
- yulia-ivashko
- チーム
- Uploads
- 優先度
- 高
- 更新
- 1時間前
- ラベル
- reliability
Five attempts per chunk is fine for one file. A folder of 300 files on a bad connection could retry for an hour. Cap the retries per upload, not only per chunk, before the agents spend the whole budget on one folder.
コメント
A cap of 50 retries per upload, then pause and ask?
Show upload speed in the header
- 担当者
- AlexKutas
- チーム
- Uploads
- 優先度
- 中
- 更新
- 6時間前
- ラベル
- enhancement
Current speed and time left next to the progress bar. Time left should not start at 3 years.
コメント
Resume uploads after a restart
- 担当者
- yulia-ivashko
- チーム
- Uploads
- 優先度
- 高
- 更新
- 14分前
- ラベル
- upload
Keep the queue on disk and restore it on start. In review as #485.
コメント
Stop uploading thumbnails at full size
- 担当者
- btriapitsyn
- チーム
- Uploads
- 優先度
- 低
- 更新
- 2日前
- ラベル
- enhancement
A thumbnail of a 48 MP photo is currently a 48 MP photo. A 200 px WebP is plenty.
コメント
Publish the SDK with the retry options
- 担当者
- AlexKutas
- チーム
- SDK
- 優先度
- 中
- 更新
- 1時間前
- ラベル
- sdk
Release once #61 is merged, with the new options in the changelog and not only in the commit messages.
コメント
Document the retry options before someone sets attempts to Infinity
- 担当者
- btriapitsyn
- チーム
- SDK
- 優先度
- 低
- 更新
- 1日前
- ラベル
- enhancement
One page with the defaults and an example for a slow connection.
コメント
統合
検索結果
おすすめ
Resource Monitor マシン、OpenChamber、開発サーバーの CPU とメモリを確認 あなたのマシンで動き、どこからでもつながる。
デスクトップアプリは手元のコンピューターでエージェントを動かし、あなたのサーバーにも接続します。スマートフォンは QR コードで一度ペアリングすれば、Private Relay 経由でサーバーにつながります。エンドツーエンドで暗号化され、ポートを開ける必要はありません。
uploaderで何に取り組みますか？
uploaderで何に取り組みますか？
uploaderで何に取り組みますか？
セッションが見つかりません。
作業状況パネルに表示する内容を選びます。非表示のセクションもデータは保持され、表示されないだけです。
セッション プロジェクト コンテキストソース ターンの統計 MCPconst result = await sendChunk(chunk); if (!result.ok) { const delay = backoff.next(chunk.attempt); if (delay === null) return fail(chunk); return schedule(chunk, delay); }
const DELAYS = [500, 1000, 2000, 4000, 8000]; export const backoff = { next(attempt: number) { return DELAYS[attempt] ?? null; } };
test('retries a chunk after a 503', async () => { server.respondWith(503); await upload(chunk); clock.tick(500); expect(server.calls).toBe(2); });
ひとつのタスクを、複数のモデルで。
同じプロンプトを複数のモデルに一度に送れます。実行ごとに専用のワークツリーとブランチを持たせることもできます。気に入った結果を残すか、回答を1つにフュージョンしましょう。
大きな diff をウォークスルーで読む。
ウォークスルーは大きな diff を理解しやすい順に並べ直し、各ステップを一文で説明し、主要な変更に印を付けます。どこから読めばいいかがわかります。
チケットもツールも、ワンクリックで。
GitHub の issue、プルリクエスト、Linear のチケットからセッションを始めると、エージェントはスレッド全体を受け取ります。統合カタログには Figma や Sentry を含む 160 以上のサービスがあり、どれもワンクリックで入ります。
ゴールか、スケジュールを渡す。
ゴールを設定すると、別のチェックが完了または行き詰まりと判断するまで、エージェントはターンごとに作業を続けます。スケジュールしたタスクは、毎朝でも来週の火曜に一度だけでも、自分でセッションを始めます。
使っている人たちから。
頼んでいない投稿です。
I've had a deep experience with openchamber. I think my choice was right. This thing is really useful, smooth and silky. Go try it out quick, I strongly recommend it, no more messing around blindly.
@realchendahuang Was looking for a way to run agents from my phone, remotely on my server, other than tmux. Found OpenChamber. It is INSANELY good, highly recommended.
@NihilSineTheo Seriously, I've spent almost the whole week trying to find a tool that made sense to orchestrate agents and, as a dev (actually, a devops), openchamber is the only one that felt natural and logical.
@1un4rPunk I just want to say the app itself is phenomenal. The level of polish is just unreal. I saw OpenChamber back when it was a small project, I think maybe a couple months ago, and now it is unrecognizable. Truly amazing work. The latest release with its streaming feature is everything I could have possibly asked for and more. It is gorgeous and smooth.
hkay-dev いま手元にあるマシンにインストールする。
macOS、Windows、Linux ならデスクトップアプリ、サーバーならコマンドひとつ。あとはどこからでも開けます。
OpenChamber はあなたの作業について何も収集しません。コードは MIT ライセンスなので、誰でも確認できます。
アクティビティ
待ち時間を設定に出せますか？ モバイルではもっと長くしたいかもしれません。
いいですね。待ち時間は 1 つの配列になったので、別の PR でできます。