Merging to release-5.8: [TT-15141] Toggling default policy from inactive to active does not activate JWT in some cases (#7431)

[buger]

User description

TT-15141 Toggling default policy from inactive to active does not activate JWT in some cases (#7431)

User description

TT-15141

Summary	Toggling default policy from inactive to active does not activate JWT in some cases
Type	Bug
Status	In Dev
Points	N/A
Labels	2025_long_tail, AI-Complexity-Medium, AI-Priority-High, codilime_refined, customer_bug, jira_escalated

---

Description

Setting a policy to draft will deactivate keys (as expected), but
setting it back to active does not reactivate the keys when policy is in
draft in time of the first request. Setting the policy back to active
should reactivate the keys.

Related Issue

Motivation and Context

How This Has Been Tested

Screenshots (if appropriate)

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing
  functionality to change)
• Refactoring or add test (improvements in base code or adds test
  coverage to functionality)

Checklist

• I ensured that the documentation is up to date
• I explained why this PR updates go.mod in detail with reasoning
  why it's required
• I would like a code coverage CI quality gate exception and have
  explained why

---

PR Type

Bug fix, Enhancement

---

Description

• Compute inactivity from applied policies only

• Persist session state by touching session

• Refactor inactivity aggregation logic

• Improve key validity evaluation robustness

---

Diagram Walkthrough

flowchart LR
  A["Apply(session)"] -- "iterate policyIDs" --> B["Aggregate policy.IsInactive"]
  B -- "result" --> C["sessionInactiveState"]
  C -- "set" --> D["session.IsInactive"]
  A -- "after validations" --> E["session.Touch()"]

Loading

File Walkthrough

	Relevant files
Bug fix	apply.go Aggregate inactivity and persist session via Touch              internal/policy/apply.go Introduce local sessionInactiveState aggregator. Set session.IsInactive once from aggregated state. Call session.Touch() to persist updated session. Clarify intent with comment on key validity basis. +8/-1

---

---

Co-authored-by: Radosław Krawczyk 98938598+radkrawczyk@users.noreply.github.com

---

PR Type

Bug fix, Enhancement

---

Description

• Aggregate inactivity across applied policies only

• Set session.IsInactive from aggregated state

• Persist updated session via session.Touch()

• Test updates and policy fixtures adjusted

---

Diagram Walkthrough

flowchart LR
  A["Apply(session)"] --> B["Iterate applied policy IDs"]
  B -- "OR policy.IsInactive" --> C["Aggregate inactivity"]
  C -- "set" --> D["session.IsInactive"]
  D -- "persist" --> E["session.Touch()"]

Loading

File Walkthrough

	Relevant files
Bug fix	apply.go Aggregate inactivity and persist session via Touch              internal/policy/apply.go Add local aggregator sessionInactiveState Compute inactivity from applied policies only Assign session.IsInactive once after loop Call session.Touch() to persist session Add clarifying comment on key validity basis +8/-1
Tests	apply_test.go Adjust tests for new inactivity evaluation                              internal/policy/apply_test.go Update expectations for inactivity with active policies Improve error assertion logic with conditional match +8/-3      policies.json Align policy fixtures with ACL and access rights                  internal/policy/testdata/policies.json Add access_rights to multiple test policies Enable acl partition where required Ensure rate/quota/complexity partitions align with ACL +50/-0

---

[github-actions]

API Changes

no api changes detected

[github-actions]

PR Code Suggestions ✨

Explore these optional code suggestions:

Category	Suggestion	Impact
General	Improve unexpected error reporting Replace t.Fail() with a failure that includes the unexpected error for debuggability. As-is, it drops the error detail and makes failures harder to diagnose. internal/policy/apply_test.go [1293-1301] if err := service.Apply(sess); err != nil { if tc.errMatch != "" { assert.ErrorContains(t, err, tc.errMatch) } else { - t.Fail() + t.Fatalf("unexpected error: %v", err) } return } Suggestion importance[1-10]: 6 __ Why: Replacing t.Fail() with t.Fatalf("unexpected error: %v", err) improves test diagnostics without changing logic. It’s a minor but useful readability/debuggability enhancement.	Low
	Touch only on success Avoid touching the session after returning an error path. Ensure session.Touch() is only reached on success and consider moving it earlier could be fine, but ensure it's not executed when an error is returned. internal/policy/apply.go [246-248] if len(rights) == 0 && policyIDs != nil { return errors.New("key has no valid policies to be applied") } +// Mark session as updated only on successful application. session.Touch() Suggestion importance[1-10]: 5 __ Why: session.Touch() is already after the error return, so it only executes on success; the suggestion restates current behavior with no functional change. It’s accurate but low impact.	Low
Possible issue	Preserve prior inactive state Preserve a pre-existing inactive session state when evaluating policy activity. If session.IsInactive was already true before applying policies, the new logic resets it to false when all policies are active, which may unintentionally reactivate the key. internal/policy/apply.go [113-116] // Only the status of policies applied to a key should determine the validity of the key. -sessionInactiveState := false +// Preserve pre-existing inactive session state. +sessionInactiveState := session.IsInactive ... sessionInactiveState = sessionInactiveState || policy.IsInactive ... session.IsInactive = sessionInactiveState Suggestion importance[1-10]: 3 __ Why: The PR intentionally changes semantics to base session.IsInactive solely on applied policies, resetting any pre-existing inactive state; the suggestion contradicts this goal. While technically harmless code-wise, it undermines the PR’s stated behavior.	Low

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
100.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud