3.5 KiB
Deferred resource work
These two proposals remain deferred after the completed audit remediation for
v0.7.0. Their assessments are complete; production limits and exclusion indexing
await a future decision supported by consumer needs. The assessment evidence
was recorded in commit 9dc87ae.
Forge JSON response budgets
Status: Deferred; local sizing assessment complete.
Forge JSON decoding can consume memory proportional to response size. Release notes and unpaginated attachment lists have no established supported maximum. A future proposal should establish an appropriate response envelope before selecting byte/time budgets or configuration. Any limit must retain context cancellation, useful error classification, and uncertain-write reconciliation: a rejected response does not establish that a create or upload failed remotely.
The Gitea fixtures construct repository, release, tag, and attachment responses. Representative encoded fixtures measured 81 bytes for repository identity, 136 with permissions, 125 for a sparse release, 144 for a populated release, 73 for a one-item attachment list, and 62 for an upload response, including the encoder's newline. Four literal release-ID fixtures measured 21, 28, 29, and 29 bytes without a newline. Generated URLs, notes, and lists vary with fixture inputs.
The checked-in v0.1.0–v0.6.0 release notes measured 1,235–7,899 bytes during the assessment. These observations describe local examples and establish no deployment or protocol maximum. Production response caps remain deferred.
File-size exclusion indexing
Status: Deferred; benchmark assessment complete.
The current exclusion scan compares each selected file with the normalized exclusions until a match is found. The adoption decision weighs measured speedups against allocation and path-walking costs for consumer workloads. Preserve literal component boundaries, module-relative normalization, shared inputs, and the first oversized-file result.
The benchmark-only prototype compares the scan with a normalized set and ancestor lookups. It covers 1,000 and 10,000 paths, 1/10/100/1,000 exclusions, shallow/deep paths, early matches, and nonmatches. Each measured operation includes normalization and one index construction where applicable; fixture strings are prepared outside timing.
On Linux/amd64, Go 1.26.8, Intel Core i5-7260U, 64 combinations ran with three samples each using:
GOTOOLCHAIN=local GOPROXY=off GOSUMDB=off go test ./internal/validation \
-run '^$' -bench '^BenchmarkFileSizeExclusions$' -benchtime=100ms -count=3
Representative median times and allocations were:
| Paths / exclusions / case | Scan | Index |
|---|---|---|
| 1,000 / 1 / shallow early match | 24.5 µs, 16 B, 1 allocation | 44.0 µs, 16 B, 1 allocation |
| 1,000 / 1 / deep nonmatch | 25.7 µs, 16 B, 1 allocation | 119.0 µs, 16 B, 1 allocation |
| 10,000 / 1,000 / shallow early match | 270 µs, 16,384 B, 1 allocation | 564 µs, 70,992 B, 6 allocations |
| 10,000 / 1,000 / shallow nonmatch | 227.0 ms, 16,384 B, 1 allocation | 521 µs, 70,992 B, 6 allocations |
| 10,000 / 1,000 / deep nonmatch | 233.4 ms, 16,384 B, 1 allocation | 1.36 ms, 70,992 B, 6 allocations |
The prototype was slower for small lists and early matches, and faster for large nonmatching lists with higher allocation costs. Production matching remains unchanged pending an adoption decision.