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 摘要。