Hacktoberfest 2026:維護者為十月標記出來的 issue,仍然開放、適合新手。 瀏覽 Hacktoberfest issue

Publish a new cap-web Docker image with the R2 multipart fixes (#2275)

未關閉 適合新手
#2,384 1 則留言 0 個 reaction 已指派 0 人 在 GitHub 檢視

維護者通常 1 天內回覆

還沒有人認領這個 Issue。

評估

難度
2/5
預估耗時
1-3 小時
新手友好度
68/100
Issue 類型
缺陷
描述清晰度
描述清楚
活躍度
活躍
技術堆疊
docker
領域
devops, release

研究方向

從目前的 ghcr.io/capsoftware/cap-web:latest 映像開始,並將其與列出的修正 e65fac6、b215b9b 和 2237aa 進行比較。發布一個包含這些修正的新 Web 映像;完成的條件是該映像可用並包含 R2 multipart 變更,同時 cap-media-server 保持不變。

由索引模型根據 Issue 內容生成。

描述

Hi! Could you publish a new ghcr.io/capsoftware/cap-web image that includes the Cloudflare R2 multipart fixes?

The latest cap-web:latest was built on 2026-09-07 (from c5f22d7), so it doesn't have:

  • e65fac6 fix(recorder-core): slice streamed chunks into uniform parts for Cloudflare R2 compatibility (#2275)
  • b215b9b fix(recorder): align streamed multipart uploads for R2
  • 2237aa8 fix: harden web recording and upload recovery (#2343)

On our self-hosted instance with R2, this hits the web recorder in Chromium browsers too, not only camera-only desktop recordings. The streaming WebM upload flushes parts of about 5.0 to 5.8 MiB, so R2 rejects CompleteMultipartUpload with InvalidPart: All non-trailing parts must have the same length. The client treats the 500 as "uncertain", so the video stays in "uploading" forever and the local spool copy is disposed. 3 of our 16 browser recordings were lost this way.

cap-media-server:latest was already rebuilt on 2026-09-24, so only the web image is behind. Thanks for the fixes!

主要語言
Rust
星號
22.8k
分支
2k
平均合併
10 小時 44 分鐘
30 天內合併 PR
88

環境準備

  • 提供 Dockerfile 或 Docker Compose 檔案
  • 沒有 Pull Request 範本
  • 閱讀貢獻指南

從這裡開始

  1. 先讀完整個 Issue,再讀專案的貢獻指南。
  2. 在 Issue 下留言說明你要接手 —— 這能避免兩個人做同樣的事。
  3. Fork 儲存庫,在一個分支上完成修改。
  4. 送出 Pull Request,並在描述裡引用這個 Issue 編號。

CapSoftware/Cap 的其他 Issue

查看 CapSoftware/Cap 的全部 Issue

相似的 Issue

更多 Rust Issue

把新 issue 寄到你的電子郵件信箱

精選適合新手參與的 GitHub issue 摘要。