Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Dynamic Review: fall back when a server refuses the blob size filter

Open
  • Is something wrong?
#304 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
35/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Active
Tech stack
git, typescript
Domain
backend

Research direction

Start with fetch_pack, which maps any ERR or fatal sideband line to CheckoutReason.PROTOCOL, and trace how the blob:limit filter is sent after PR #296. Reproduce with a local repository whose upload-pack disallows blob:limit, as test T01 describes. Done means the checkout prepares with the large blob omitted, the retry order is blob:limit, blob:none, then no filter, and docs/dynamic-checkout.md documents the fallback and its budget.

Written by the indexing model from the issue text.

Description

area: runner type: bug

Follows #296 / PR #300 (review finding F2).

Problem

Before #296 the only filter the checkout sent was blob:none. Now it sends filter blob:limit=<n> whenever the server advertises the filter capability. A server that allows some filters but not this one (a Git server or proxy configured with uploadpackfilter.blob:limit.allow=false) answers with an ERR or fatal sideband line. fetch_pack maps any such line to CheckoutReason.PROTOCOL, so the whole run fails with checkout_incomplete [protocol]. Reproduced with a local repository that has that setting: the code before #296 prepares it, the code after fails. GitHub.com honours blob:limit (verified live), so this concerns other servers, for example self-hosted ones.

Design

  • When a fetch with blob:limit is refused with the server's filter error, retry once with filter blob:none and keep the existing inference that a blob missing from the response is above the limit and is omitted. If blob:none is refused too, retry once without a filter. Every retry stays inside the transfer and preparation budgets and the deadline.
  • Recognize the refusal by its stable shape only (a fatal/ERR sideband line that mentions the filter), never by copying server text into logs or errors.
  • Remember the outcome for the rest of the run, so each later fetch (merge base, previous) does not repeat the failed attempt.
  • Only a filter refusal retries. Other errors keep their reason.

Test cases

ID kind level case expected
T01 regression integration (real upload-pack, blob:limit disallowed) prepare a repository with a large binary blob prepares; the large blob is omitted; fails with [protocol] before the fix
T02 behavior unit (protocol) the server refuses blob:limit, then blob:none retries in that order, then fails with the original reason if all are refused
T03 behavior unit (protocol) an unrelated ERR line no retry; reason unchanged
T04 behavior integration later fetches of the same run do not repeat the refused filter
T05 security unit server error text never appears in an error, a log line or the result
T06 docs review docs/dynamic-checkout.md the fallback and its budget bound are documented
Dominant language
TypeScript
Stars
0
Forks
1
Avg merge
1h 18m
Merged PRs (30d)
186

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from ExpidetGames/code-reviewer

All issues in ExpidetGames/code-reviewer

Similar issues

More TypeScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.