Hacktoberfest 2026: as issues que os mantenedores marcaram para outubro, abertas e boas para iniciantes. Ver issues do Hacktoberfest

A task output archive larger than the remote cache server's request limit can never be stored

Aberta
#888 0 comentários 0 reações 0 responsáveis Ver no GitHub

Mantenedores costumam responder em até 1 dia

Ninguém assumiu esta issue ainda.

Avaliação

Dificuldade
4/5
Tempo estimado
3-5 dias
Facilidade para iniciantes
45/100
Tipo de issue
Funcionalidade
Clareza
Claramente especificada
Status de atividade
Ativa
Stack de tecnologia
cloud, rust

Direção de pesquisa

Start with crates/vt_remote_cache/README.md and the Client::store request flow described there, then trace create_output_archive to understand archive creation and size. The work is done when oversized archives can be uploaded through a server-provided URL without breaking the existing single-request store protocol; no specific test file is named.

Escrita pelo modelo de indexação a partir do texto da issue.

Descrição

Written by an AI agent (Claude) on behalf of @jasonkuhrt.

What happens

A task whose output archive is larger than the remote cache server can accept in one request is never stored remotely, so every other machine runs it again:

not uploaded to the remote cache: HTTP status 413

Our remote cache server is a Cloudflare Worker storing blobs in R2. Cloudflare refuses a request body over 100 MB on the Free and Pro plans (200 MB on Business) with 413 before the Worker sees it (limits).

The case that motivates it

A full-stack app's development build (TanStack Start with Nitro, Vite 8.3.5 through Vite+ 1.4.0). Its output archive is 104.8 MB as create_output_archive writes it. It takes 60 s to build cold and 6 s to replay from the local cache, and it is the bundle every end-to-end test run serves, so every CI job and developer machine without a local hit builds it again. Moving 105 MB takes seconds; building it takes a minute.

For scope, the opposite case: a task that only downloads a 400 MB binary gains nothing from the remote tier, since it trades one download for another.

Why the server can't fix it

Client::store sends the metadata and the archive as one multipart/form-data POST to {endpoint}/store, follows no redirect, and counts only a 200 as success (crates/vt_remote_cache/README.md). The archive's size is the request's size, so a server behind a platform's request limit has no way to accept it.

A possible shape

Let the server take the archive outside the store request when it asks to: for example, the store's response names an upload URL for the blob (or one per part), and the client sends the archive there. Object stores already support exactly this through presigned and multipart uploads. A server that answers the single request as today keeps working unchanged.

Happy to test a branch against our server.

Linguagem predominante
Rust
Estrelas
480
Forks
50
Merge médio
1d 3h
PRs com merge (30d)
62

Preparar o ambiente

Abrir no Codespaces

Inicia o contêiner de desenvolvimento do projeto no navegador, com a sua própria conta do GitHub.

Primeiros passos

  1. Leia a issue inteira e depois o guia de contribuição do projeto.
  2. Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
  3. Faça um fork do repositório e trabalhe em uma branch.
  4. Abra um pull request que referencie o número da issue.

Mais de voidzero-dev/vite-task

Todas as issues de voidzero-dev/vite-task

Issues semelhantes

Mais issues de Rust

Receba novas issues na sua caixa de entrada

Um resumo curto de issues do GitHub para quem está começando.