Add OCI tag pagination

[epompeii]

• OCI tag pagination
• Refactor OCI authentication logic

[github-actions]

Bencher Report

Branch	u/ep/oci-tags
Testbed	ubuntu-22.04

⚠️ WARNING: No Threshold found!

Without a Threshold, no Alerts will ever be generated.

• Latency (nanoseconds (ns))

Click here to create a new Threshold
For more information, see the Threshold documentation.
To only post results if a Threshold exists, set the --ci-only-thresholds flag.

Click to view all benchmark results

Benchmark	Latency	microseconds (µs)
Adapter::Json	📈 view plot ⚠️ NO THRESHOLD	3.71 µs
Adapter::Magic (JSON)	📈 view plot ⚠️ NO THRESHOLD	3.70 µs
Adapter::Magic (Rust)	📈 view plot ⚠️ NO THRESHOLD	25.91 µs
Adapter::Rust	📈 view plot ⚠️ NO THRESHOLD	2.80 µs
Adapter::RustBench	📈 view plot ⚠️ NO THRESHOLD	2.78 µs
head_version_insert/batch/10	📈 view plot ⚠️ NO THRESHOLD	87.50 µs
head_version_insert/batch/100	📈 view plot ⚠️ NO THRESHOLD	223.56 µs
head_version_insert/batch/255	📈 view plot ⚠️ NO THRESHOLD	452.54 µs
head_version_insert/batch/50	📈 view plot ⚠️ NO THRESHOLD	145.73 µs
threshold_query/join/10	📈 view plot ⚠️ NO THRESHOLD	127.09 µs
threshold_query/join/20	📈 view plot ⚠️ NO THRESHOLD	142.56 µs
threshold_query/join/5	📈 view plot ⚠️ NO THRESHOLD	122.35 µs
threshold_query/join/50	📈 view plot ⚠️ NO THRESHOLD	183.70 µs

🐰 View full continuous benchmarking report in Bencher

[github-actions]

🤖 Claude Code Review

PR: #660
Base: devel
Head: u/ep/oci-tags
Commit: 29852a032f416d9350d67a97b9f480de98fee5c3

---

I've now reviewed the full diff. Let me provide a comprehensive code review.

---

Pull Request Review

Summary

This PR contains significant OCI registry improvements including:

• Refactored authentication helpers (require_pull_access, require_push_access)
• Added pagination support for tags list endpoint with proper Link header
• Updated rate limiting to use max() for Bencher Self-Hosted
• Various CI/CD workflow improvements
• Extensive new tests for auth flows

---

Code Quality & Best Practices

Good:

• Excellent refactoring of validate_push_access into smaller, focused functions (handle_existing_project, handle_claimed_project, handle_unclaimed_project, handle_nonexistent_project)
• Comprehensive test coverage for the new auth branches
• Proper use of #[expect(...)] instead of #[allow(...)] per CLAUDE.md guidelines
• Clean extraction of require_pull_access and require_push_access helper functions

Suggestions:

1. Unused field warning suppression in plus/api_oci/src/auth.rs:193-194:

   pub struct OciAccess {
       #[expect(dead_code, reason = "May be used in the future for audit logging")]
       pub claims: OciClaims,
   }

   The claims field is marked dead_code but is public. If it's truly for future use, consider making it private or using it now. Otherwise, this suppression is appropriate.

2. Documentation improvement: The new streaming limitations documentation in blobs.rs:7-20 is excellent and follows best practices for documenting memory constraints.

---

Potential Bugs or Issues

1. Rate limiting change in lib/bencher_schema/src/context/rate_limiting/mod.rs:147-149:

   (false, None) => {
       slog::info!(log, "No rate limits applied for Bencher Self-Hosted");
       Self::max()
   }

   Changing from default() to max() for Self-Hosted could be a breaking change if existing deployments relied on the default limits. The removed TODO comment indicated this was intentional but users should be notified.

2. OCI conformance test is now continue-on-error: true in .github/workflows/deploy.yml:67-68:

   - name: Run OCI Conformance Test
     continue-on-error: true

   This means OCI conformance failures won't block deployment. Is this intentional? If OCI conformance is critical, this could mask regressions.

---

Security Concerns

1. Authentication flow looks correct: The refactored auth functions properly:

   • Validate tokens before granting access
   • Apply rate limiting after authentication
   • Return appropriate 401/403 errors with www-authenticate headers
   • Don't leak internal error details (uses clippy::map_err_ignore appropriately)

2. URL encoding for pagination in plus/api_oci/src/tags.rs:131-138:

   format!(
       "</v2/{}/tags/list?n={}&last={}>; rel=\"next\"",
       name_str,
       n,
       urlencoding::encode(last_tag)
   )

   Using urlencoding::encode for the last_tag parameter prevents injection attacks.

---

Performance Implications

1. Tags pagination is well-implemented:

   • S3 storage uses native start_after and max_keys for efficient server-side pagination
   • Local storage must still read all entries before paginating (noted in comments)
   • Fetching limit + 1 to detect "has more" is a standard efficient pattern

2. Rate limiting change: Moving Self-Hosted to max() limits removes rate limiting overhead for self-hosted deployments.

---

Compliance with CLAUDE.md

• ✅ New dependency urlencoding added to workspace Cargo.toml
• ✅ cargo gen-types was run - openapi.json updated with new endpoint documentation
• ✅ Uses #[expect(...)] instead of #[allow(...)]
• ✅ No shell scripts added (changes to existing workflows only)

---

Minor Issues

1. CI workflow change in .github/workflows/ci.yml:9:
   Added services/api/openapi.json to CLI change detection - makes sense since CLI is generated from the OpenAPI spec.

2. Removed VM scaling in deploy.yml: Removed flyctl scale vm performance-8x and scale-down steps. This simplifies deployment but should be verified that dev machines have adequate resources.

3. Added --hash flag in track_benchmarks.yml:76 - good for explicit commit tracking.

---

Recommendations

1. Document the rate limiting change in release notes - the behavior change from default to max limits for Self-Hosted could affect users.

2. Reconsider continue-on-error: true for OCI conformance tests, or add an issue to track when this should be made required again.

3. Consider adding a test for the edge case where pagination last parameter contains special characters that need URL encoding.

---

Overall Assessment

This is a solid PR with good refactoring, improved documentation, and comprehensive test coverage. The main concerns are:

• The rate limiting behavior change should be documented
• The continue-on-error on OCI conformance tests could mask regressions

---

_{Model: claude-opus-4-5-20251101}