Add an IP-based cache context#45
Conversation
to ensure pages are cached separately for different IP addresses
WalkthroughThe access check now appends a new cache context, ip.embargo_range, to the AccessResult in EmbargoAccessCheck::access(). No control-flow or method signatures changed; only the caching metadata was updated to vary by client IP embargo range. Changes
Sequence Diagram(s)sequenceDiagram
autonumber
participant Client
participant Router
participant EmbargoAccessCheck as AccessCheck
participant AccessResult
Client->>Router: Request entity route
Router->>AccessCheck: access(entity, user)
AccessCheck->>AccessCheck: Evaluate embargo rules (unchanged)
AccessCheck->>AccessResult: Build result with cache tags/contexts
Note right of AccessResult: New cache context: ip.embargo_range
AccessCheck-->>Router: AccessResult (vary by IP embargo range)
Router-->>Client: Allow/Deny
Estimated code review effort🎯 1 (Trivial) | ⏱️ ~3 minutes Poem
Pre-merge checks and finishing touches✅ Passed checks (3 passed)
✨ Finishing touches
🧪 Generate unit tests
Warning Review ran into problems🔥 ProblemsErrors were encountered while retrieving linked issues. Errors (1)
Tip 👮 Agentic pre-merge checks are now available in preview!Pro plan users can now enable pre-merge checks in their settings to enforce checklists before merging PRs.
Please see the documentation for more information. Example: reviews:
pre_merge_checks:
custom_checks:
- name: "Undocumented Breaking Changes"
mode: "warning"
instructions: |
Pass/fail criteria: All breaking changes to public APIs, CLI flags, environment variables, configuration keys, database schemas, or HTTP/GraphQL endpoints must be documented in the "Breaking Change" section of the PR description and in CHANGELOG.md. Exclude purely internal or private changes (e.g., code not exported from package entry points or explicitly marked as internal).Please share your feedback with us on this Discord post. Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
| '@count embargoes preventing access.' | ||
| )->render() | ||
| )); | ||
| )->addCacheContexts(['ip.embargo_range'])); |
There was a problem hiding this comment.
This should not be necessary, as the embargo itself should bear the context definition:
embargo/src/Entity/Embargo.php
Lines 423 to 425 in a481d32
and so have already been merged into the caching result of the access result back on line 77.
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (2)
src/Access/EmbargoAccessCheck.php (2)
34-38: Typo in docblock“Th current user.” → “The current user.”
- * Th current user. + * The current user.
77-78: Avoid array_map for side effectsUse foreach for clarity.
- array_map([$state, 'addCacheableDependency'], $related_embargoes); + foreach ($related_embargoes as $embargo) { + $state->addCacheableDependency($embargo); + }
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
Disabled knowledge base sources:
- Jira integration is disabled by default for public repositories
You can enable these sources in your CodeRabbit configuration.
📒 Files selected for processing (1)
src/Access/EmbargoAccessCheck.php(1 hunks)
🔇 Additional comments (2)
src/Access/EmbargoAccessCheck.php (2)
73-75: Confirm: no-IP variation when no embargo statementsThis early return omits the
ip.embargo_rangecontext for entities without embargoes. Likely intentional to avoid unnecessary cache cardinality. Please confirm this matches the requirement.
85-93: LGTM: IP-based cache context registered and implemented
Ensure thecache_context.ip.embargo_rangeservice (IpRangeCacheContext implements CacheContextInterface) buckets IPs into ranges (low-cardinality) and verify CDN/Varnish honors this variation.
to ensure pages are cached separately for different IP addresses
Related discussion https://islandora.slack.com/archives/C019U12D44Q/p1758053670689559
Summary by CodeRabbit