Repository navigation
Conversation
## Summary ### Why? The object-info implementation was not compatible with the Git client: its capability omitted the supported attribute, missing objects used an invalid numeric sentinel, requests were unbounded, and excluded hosts could start object synchronization. ### What? Advertise `object-info=size`, return protocol-defined empty values for missing objects, cap requests at 1,024 OIDs before sync, and apply the existing placement refusal before any object work. Preserve manifest-versioned positive and negative caching across local and remote-served object access. The healthy request path remains one conditional manifest GET. Warm cache hits and local header lookups add zero bucket reads; remote misses add only the pack range reads required by `RemotePacks::header`. ## Test Plan ✅ `cargo check -p walgit-server` ✅ `cargo test -p walgit-git read_object_info_args_reads_size_and_oids_after_delimiter` ✅ `cargo test -p walgit-server --test e2e info_refs_v2_advertises_capabilities -- --exact` ✅ `cargo test -p walgit-server --test e2e object_info_v2` ✅ `cargo test -p walgit-server --test maintain host_excluded_from_serving_a_repo_refuses_object_work_with_503 -- --exact` ✅ `cargo test -p walgit-server --test e2e fetch_from_front_that_serves_the_base_remotely -- --exact` ✅ `cargo clippy -p walgit-server --all-targets -- -D warnings` ✅ `cargo fmt --all -- --check` ✅ `git diff --check` ## Issue Closes tobi#80 (cherry picked from commit c51b778)
…runtime Follow-ups from the review of the object-info change: - Remote pack header reads for one request run at most 16 at a time, in request order, instead of up to 1,024 at once. - Only found sizes are cached. A miss cached under a manifest version read after the sync could hide an object pushed in between; misses are cheap to recompute. - Local header lookups run on a blocking thread rather than on the async runtime. Adds an end to end test that an object pushed after a lookup missed it is reported with its size.
git sends up to 10,000 object ids in one object-info request (cat-file remote-object-info, MAX_ALLOWED_OBJ_LIMIT), and the protocol has no way to advertise a lower limit, so a cap of 1,024 made ordinary clients fail and fall back to downloading objects. The cap stays a guard against unbounded requests: remote reads are still at most 16 at a time and local lookups run on a blocking thread.
Owner
Author
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Stacked on #19.
Imports tobi/walgit#88 by @behinddwalls: advertises
object-info=size, answers in the protocol's format (sizeheader,<oid> <size>, empty size for a missing object), caps a request at 1,024 object ids before any sync, applies the placement refusal, and reads object headers instead of inflating objects. Clients such as lazy mounts get file sizes without downloading content.One follow-up commit addresses the review still open on tobi#88:
A second follow-up raises the per-request cap from 1,024 to 10,000 object ids. git's own client sends up to 10,000 ids per object-info request (
cat-fileremote-object-info,MAX_ALLOWED_OBJ_LIMIT) and the protocol cannot advertise a lower limit, so with 1,024 ordinary clients failed and fell back to downloading objects.It adds an end to end test that an object pushed after a lookup missed it is reported with its size. That test does not reproduce the cache race itself, which is not deterministic.
Verified on the top of this stack:
cargo clippy --workspace --all-targets -- -D warnings,cargo fmt --check, the crate test suites, and the Azure harness (just test-azure: store contract plus git push, clone, pull and cold restart on Azurite) pass. Known unrelated failures: the runtime stall timing tests ine2e(also intermittent on main) and the web UI asset tests that needpnpm run build.