Set limit for L1 cache in bit Boilerplate (#12108)

[yasmoradi]

closes #12108

Summary by CodeRabbit

• Chores
  • Updated memory cache configuration with explicit size limits and optimized cache entry handling for improved resource management.

[coderabbitai]

Important

Review skipped

Auto incremental reviews are disabled on this repository.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

Walkthrough

The pull request adds explicit memory cache size limits to the boilerplate's caching infrastructure. Client HTTP responses, FusionCache, and shared memory cache are configured with size constraints to prevent unbounded cache growth and memory exhaustion.

Changes

Cohort / File(s)	Summary
Client HTTP Response Caching src/Client/.../HttpMessageHandlers/CacheDelegatingHandler.cs	Modified HTTP cache storage to use MemoryCacheEntryOptions with Size = 1 instead of passing expiration timespan directly, enabling cache size tracking.
Server Cache Configuration src/Server/.../WebApplicationBuilderExtensions.cs, src/Shared/.../ISharedServiceCollectionExtensions.cs	Added default entry size (Size = 1) to FusionCache configuration and configured shared memory cache with SizeLimit of 1,000,000, establishing size constraints across cache layers.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~10 minutes

Poem

🐰 With caches now bounded and sized just right,
No memory swells to an unbounded height,
A thousand entries in the L1 store,
Keep the boilerplate lean, forevermore! ✨

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%.	Write docstrings for the functions missing them to satisfy the coverage threshold.

✅ Passed checks (4 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title clearly and concisely summarizes the main change: setting a limit for the L1 cache in the bit Boilerplate, which directly aligns with all modifications across the three files.
Linked Issues check	✅ Passed	The PR successfully implements the objective from issue #12108 by configuring memory cache limits across all three files: setting SizeLimit on IMemoryCache, adding Size to FusionCache entries, and updating CacheDelegatingHandler to use MemoryCacheEntryOptions.
Out of Scope Changes check	✅ Passed	All changes are directly related to implementing L1 cache size limits as specified in issue #12108; no unrelated modifications were introduced.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment

---

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.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[Copilot]

Pull request overview

This PR updates the bit Boilerplate template to introduce bounded sizing for the in-memory (L1) cache layer, addressing issue #12108 about unbounded memory cache growth.

Changes:

• Configures AddMemoryCache with a SizeLimit to cap L1 cache capacity.
• Sets default FusionCache entry Size so L1 sizing can be enforced.
• Updates the client HTTP response caching handler to set a cache entry Size and preserve absolute expiration behavior.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 1 comment.

File	Description
src/Templates/Boilerplate/Bit.Boilerplate/src/Shared/Infrastructure/Extensions/ISharedServiceCollectionExtensions.cs	Adds a global MemoryCacheOptions.SizeLimit to bound L1 cache capacity.
src/Templates/Boilerplate/Bit.Boilerplate/src/Server/Boilerplate.Server.Shared/Infrastructure/Extensions/WebApplicationBuilderExtensions.cs	Sets default FusionCache entry Size to support size-based eviction in L1.
src/Templates/Boilerplate/Bit.Boilerplate/src/Client/Boilerplate.Client.Core/Infrastructure/Services/HttpMessageHandlers/CacheDelegatingHandler.cs	Ensures cached HTTP responses include a Size and use absolute expiration from Cache-Control: max-age.

[coderabbitai]

Actionable comments posted: 1

🧹 Nitpick comments (1)

src/Templates/Boilerplate/Bit.Boilerplate/src/Shared/Infrastructure/Extensions/ISharedServiceCollectionExtensions.cs (1)

43-44: Advisory: SizeLimit = 1_000_000 is an entry-count cap, not a byte cap.

Each entry counts as 1 unit regardless of the actual bytes in the cached value. For CacheDelegatingHandler, a cached 10 KB JSON response and a 5 MB binary response both consume exactly 1 unit. 1 M cached HTTP responses of even moderate size can exhaust process memory well before the count limit is reached, particularly on memory-constrained clients (Blazor WASM, mobile Hybrid).

Consider whether the client-side SizeLimit should be substantially lower (e.g., 10_000 entries for client-only HTTP response caching) to reduce the risk of memory pressure on constrained devices.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@src/Templates/Boilerplate/Bit.Boilerplate/src/Shared/Infrastructure/Extensions/ISharedServiceCollectionExtensions.cs`
around lines 43 - 44, The hardcoded options.SizeLimit = 1_000_000 in
ISharedServiceCollectionExtensions should be reduced and made configurable
because SizeLimit counts entries (not bytes) and 1M entries can exhaust memory
on constrained clients (see CacheDelegatingHandler). Change the default to a
much smaller safe value (e.g., 10_000) and/or read the limit from configuration
(inject IConfiguration or a feature flag) so consumers can override it per-host
(Blazor WASM, mobile). Update the code that sets options.SizeLimit and add a
short comment noting it is an entry-count limit, not a byte limit.

🤖 Prompt for all review comments with AI agents

Verify each finding against the current code and only fix it if needed.

Inline comments:
In
`@src/Templates/Boilerplate/Bit.Boilerplate/src/Server/Boilerplate.Server.Shared/Infrastructure/Extensions/WebApplicationBuilderExtensions.cs`:
- Around line 61-64: Three call sites construct new FusionCacheEntryOptions
without setting Size, which allows entries to be silently dropped by the
size-limited IMemoryCache; update each construction to include Size = 1. Find
the direct new FusionCacheEntryOptions { ... } usages in AppChatbot (class
AppChatbot), IdentityController.WebAuthn (class IdentityController partial for
WebAuthn), and UserController.WebAuthn (class UserController partial for
WebAuthn) and add Size = 1 to the object initializers so they explicitly set
Size alongside the existing properties.

---

Nitpick comments:
In
`@src/Templates/Boilerplate/Bit.Boilerplate/src/Shared/Infrastructure/Extensions/ISharedServiceCollectionExtensions.cs`:
- Around line 43-44: The hardcoded options.SizeLimit = 1_000_000 in
ISharedServiceCollectionExtensions should be reduced and made configurable
because SizeLimit counts entries (not bytes) and 1M entries can exhaust memory
on constrained clients (see CacheDelegatingHandler). Change the default to a
much smaller safe value (e.g., 10_000) and/or read the limit from configuration
(inject IConfiguration or a feature flag) so consumers can override it per-host
(Blazor WASM, mobile). Update the code that sets options.SizeLimit and add a
short comment noting it is an entry-count limit, not a byte limit.