fix(jans-cedarling): disable token cache when max TTL is zero

[pradhankukiran]

Prepare

• Read PR guidelines
• Read license information

---

Description

Target issue

closes #14154

Implementation Details

CEDARLING_TOKEN_CACHE_MAX_TTL=0 now disables the token cache entirely. This avoids repeated SparkV ttl too long warnings and avoids unbounded cache growth when no TTL cap is configured.

For non-zero values, existing token cache behavior is preserved:

• max_ttl > 0: cache TTL is capped by configured value
• token has no exp: configured max_ttl is used

Regression tests cover disabled-cache behavior for tokens with and without exp, plus the positive TTL cap path.

---

Test and Document the changes

• Static code analysis has been run locally and issues have been fixed
• Relevant unit and integration tests have been added/updated
• Relevant documentation has been updated if any (i.e. user guides, installation and configuration guides, technical design docs etc)

Tests run:

• cargo test -p cedarling token_cache --lib
• cargo clippy -p cedarling --lib

Please check the below before submitting your PR. The PR will not be merged if there are no commits that start with docs: to indicate documentation changes or if the below checklist is not selected.

• I confirm that there is no impact on the docs due to the code changes in this PR.

Summary by CodeRabbit

• Bug Fixes

  • Setting max_ttl to 0 now fully disables the token cache: cache lookups, writes, and expiration handling are skipped.

• Documentation

  • Configuration docs and comments clarified to state that a value of 0 disables the token cache entirely (not just the TTL cap).

• Tests

  • Added unit tests confirming caching is disabled when max_ttl = 0 and that positive max_ttl properly caps token TTLs.

[mo-auto]

✅ Snyk checks have passed. No issues have been found so far.

Status	Scan Engine	Critical	High	Medium	Low	Total (0)
✅	Open Source Security	0	0	0	0	0 issues

💻 Catch issues earlier using the plugins for VS Code, JetBrains IDEs, Visual Studio, and Eclipse.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: ASSERTIVE

Plan: Pro

Run ID: ac8a26db-bf7d-492a-8e39-8cc8ee3f348c

📥 Commits

Reviewing files that changed from the base of the PR and between 86cd1d5 and 3f70a0d.

📒 Files selected for processing (4)

• docs/cedarling/reference/cedarling-properties.md
• jans-cedarling/cedarling/src/bootstrap_config/jwt_config.rs
• jans-cedarling/cedarling/src/bootstrap_config/raw_config/config.rs
• jans-cedarling/cedarling/src/jwt/token_cache.rs

---

📝 Walkthrough

Walkthrough

TokenCache now treats max_ttl == 0 as "cache disabled": find immediately returns None (recording a miss) and save returns early without persisting. Tests were added and documentation updated to state that 0 disables caching entirely.

Changes

Token Cache Behavior and Docs

Layer / File(s)	Summary
Implementation and tests jans-cedarling/cedarling/src/jwt/token_cache.rs	Reordered imports, changed TokenCache.cache to Option, updated max_ttl doc; TokenCache::new constructs SparKV only when max_ttl > 0. TokenCache::find, save, clear_expired, and invalidate_by_index early-return when caching is disabled. Added unit tests validating: no caching for max_ttl = 0 (with and without exp) and that positive max_ttl caps cache duration.
Docs and config comments docs/cedarling/reference/cedarling-properties.md, jans-cedarling/cedarling/src/bootstrap_config/jwt_config.rs, jans-cedarling/cedarling/src/bootstrap_config/raw_config/config.rs	Updated property and inline comments: 0 now documented as disabling the token cache entirely instead of removing the TTL cap.

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~20 minutes

Possibly related PRs

• JanssenProject/jans#14098: Modifies JWT token-cache TTL/max_ttl handling and overlaps at token-cache behavior changes.

Suggested labels

kind-bug, comp-jans-cedarling, area-documentation

Suggested reviewers

• olehbozhok
• haileyesus2433

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title accurately describes the main change: disabling the token cache when max TTL is set to zero.
Description check	✅ Passed	The PR description follows the template and includes target issue, implementation details, testing confirmation, and documentation updates.
Linked Issues check	✅ Passed	The PR implements the revised objective from issue #14154 by disabling the token cache entirely when max_ttl=0, with regression tests covering both tokens with and without exp claims.
Out of Scope Changes check	✅ Passed	All changes are directly related to fixing the token cache behavior and updating documentation to reflect the new behavior when max_ttl=0.
Docstring Coverage	✅ Passed	Docstring coverage is 100.00% which is sufficient. The required threshold is 80.00%.

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

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

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.}

[coderabbitai]

Actionable comments posted: 1

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@jans-cedarling/cedarling/src/jwt/token_cache.rs`:
- Around line 289-318: Update the three tests
(max_ttl_zero_uses_token_expiration,
max_ttl_zero_does_not_cache_token_without_exp,
positive_max_ttl_caps_token_expiration) to include descriptive messages on their
assertions: for the first two tests add a message to the assert! calls that
explains the expected presence or absence of the cached token when saving via
cache.save(&TokenKind::StatusList, "jwt", token, now) and retrieving with
cache.find(...), and for the third test add a message to assert_eq! that
explains that cache.cache_duration(&token, now) should return Some(5) when token
has an exp and cache created by token_cache(5); locate these tests and update
the assert!/assert_eq! calls to include the explanatory string arguments.

🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: ASSERTIVE

Plan: Pro

Run ID: 3b06e995-979e-40bf-af12-58a772fba2f5

📥 Commits

Reviewing files that changed from the base of the PR and between a8dc7ae and e964373.

📒 Files selected for processing (1)

• jans-cedarling/cedarling/src/jwt/token_cache.rs

[dagregi]

Hi @pradhankukiran thank you for the contributions but the issue #14154 has been updated, sorry I should have written the issue clearly first. If you're willing to update your pr, we'd appreciate it

[pradhankukiran]

Updated the PR to match the revised issue behavior: CEDARLING_TOKEN_CACHE_MAX_TTL=0 now disables the token cache entirely, and the docs have been updated to say the same.\n\nValidation run:\n- cargo test -p cedarling token_cache --lib\n- cargo clippy -p cedarling --lib

[dagregi]

Nicely done but how about doing this check in the constructor and making TokenCache.cache optional so this check becomes

let Some(ref cache) = self.cache else {
    self.metrics.record_cache_miss();
    return None;
};

[pradhankukiran]

Updated per your suggestion: disabled token cache is now represented as cache: None from the constructor, and cache operations handle that as a no-op / miss.\n\nAlso rebased on latest main.\n\nValidation run:\n- cargo test -p cedarling token_cache --lib\n- cargo clippy -p cedarling --lib