This pull request reverts commit 989c668b, which was introduced in PR #8254 to address issue TT-16259. The original change aimed to fix a race condition where a session token, particularly one with a quota under heavy load, could be recreated by an in-flight request immediately after being deleted. The fix involved introducing a conditional "set-if-exists" operation (SetKeyEx) at the storage layer.

This revert completely removes the SetKeyEx logic and its associated code, suggesting the original implementation may have caused unintended side effects or stability issues. The session update mechanism is now returned to a simpler, non-atomic "create-or-overwrite" operation, which unfortunately re-introduces the original race condition.

Files Changed Analysis

The changes are overwhelmingly deletions (~1084 lines removed vs. ~56 added), which is characteristic of a revert. Key changes include:

• Removal of SetKeyEx and SetRawKeyEx: These methods have been removed from the storage.Handler interface and all its implementations (redis_cluster.go, rpc_storage_handler.go, dummy.go, mdcb_storage.go).
• Reverted Session Update Logic: In gateway/auth_manager.go, the UpdateSession method no longer distinguishes between new and existing sessions based on an isRestored flag and unconditionally uses SetKey.
• Simplified Session State: The isRestored flag and its related methods have been removed from user/session.go.
• Test and Utility Removal: A significant number of tests related to the reverted functionality have been deleted. The log/hook.go utility file and its tests have also been removed entirely.
• Dependency Downgrade: go.mod shows a downgrade of github.com/TykTechnologies/storage from v1.3.2 to v1.3.1, aligning with the removal of the feature from the storage dependency.

Architecture & Impact Assessment

• What this PR accomplishes: It rolls back the fix for the session deletion race condition, effectively re-introducing the bug from TT-16259.
• Key technical changes introduced: The primary change is the removal of the atomic "update-if-exists" operation from the storage layer. Session updates will now always perform a "create-or-overwrite" operation.
• Affected system components: The main components affected are Session Management (gateway/auth_manager.go) and the Storage Abstraction Layer (storage/). The behavior of session persistence under high concurrent loads is directly impacted.

Session Update Flow Change

This revert simplifies the session update logic but re-introduces the race condition. The diagram below illustrates the change.

Before (Logic being reverted):

sequenceDiagram
    participant SM as SessionManager
    participant SS as SessionState
    participant Store as Storage
    SM->>SS: IsRestored()?
    alt Existing Session
        SS-->>SM: true
        SM->>Store: SetKeyEx(key, session) # Update only if key exists
    else New Session
        SS-->>SM: false
        SM->>Store: SetKey(key, session) # Create or overwrite key
    end

After (This PR's Logic):

sequenceDiagram
    participant SM as SessionManager
    participant Store as Storage
    SM->>Store: SetKey(key, session) # Always create or overwrite

Scope Discovery & Context Expansion

• The most significant impact of this revert is the reintroduction of the bug from TT-16259. The system is again vulnerable to a race condition where a session deleted by an administrator can be recreated by an in-flight request, effectively bypassing the deletion. This has security and resource management implications.
• The revert was likely necessary due to unforeseen issues with the original implementation, such as performance degradation, deadlocks, or bugs in specific storage backends (the removal of complex retry logic in rpc_storage_handler.go might be a clue).
• The next step for the team should be to investigate a new, more stable solution for the original race condition, as the problem of atomically updating sessions without resurrecting them remains a critical issue to be solved.

Powered by Visor from Probelabs

Last updated: 2026-06-15T09:36:22.245Z | Triggered by: pr_updated | Commit: 844afc8

💡 TIP: You can chat with Visor using /visor ask <your question>

Security Issues (1)

Performance Issues (2)

Quality Issues (2)

Powered by Visor from Probelabs

Last updated: 2026-06-15T09:36:15.302Z | Triggered by: pr_updated | Commit: 844afc8

💡 TIP: You can chat with Visor using /visor ask <your question>

SentinelOne CNS Hardcoded Secret Detector
✅ Congratulations, your code is safe

SentinelOne CNS is a cloud-agnostic, agentless CSPM & CWPP solution that continuously detects and prevents vulnerabilities that have the highest probability of being exploited in Azure, AWS, Google Cloud, and Kubernetes.

🚨 Jira Linter Failed

Commit: 844afc8
Failed at: 2026-06-15 09:34:27 UTC

The Jira linter failed to validate your PR. Please check the error details below:

failed to get Jira issue: failed to fetch Jira issue TT-16259: Issue does not exist or you do not have permission to see it.: request failed. Please analyze the request body for more details. Status code: 404

Next Steps

• Ensure your branch name contains a valid Jira ticket ID (e.g., ABC-123)
• Verify your PR title matches the branch's Jira ticket ID
• Check that the Jira ticket exists and is accessible

This comment will be automatically deleted once the linter passes.

Quality Gate failed

Failed conditions
C Reliability Rating on New Code (required ≥ A)

See analysis details on SonarQube Cloud

Catch issues before they fail your Quality Gate with our IDE extension SonarQube for IDE

@kofoworola asked for this to be merged since this is an agreed revert inside the team