[SMRT] VRF v2.5: Cannot cancel subscription due to stuck 'Invalid key hash' request from Nov 2025

Description

VRF v2.5 subscription cannot be cancelled due to a stuck failed request from November 2025 with status "Invalid key hash." The subscription remains in an active state, preventing LINK token withdrawal. The failed request is permanently blocking cancellation attempts, with no auto-timeout or recovery mechanism triggered after ~9 months.

Basic Information

Smart Contract Files Affected:

VRF Coordinator v2.5

Chainlink Software Version:

VRF v2.5 (latest)

Network:

Ethereum Mainnet

Affected Subscription ID: 81748795925402121085493516811050644686292477025678169531320581446471470018479

Failed Request Transaction Hash: 0xb2e5b3cf4cab4e6ea39ed5066ac9ffa60cc829837d6b49d5b27f48baae06abe1

Request Status:

Date: November 2025
Error: "Invalid key hash"
Current State: Stuck (no auto-timeout or fulfillment after 9+ months)

Wallet Type:

Standard EOA (externally owned account)
Not a contract wallet
Steps to Reproduce
Create or locate a VRF v2.5 subscription on Ethereum Mainnet with active LINK balance
Make a VRF randomness request that references an invalid or revoked key hash
Wait for the request to fail with error: "Invalid key hash"
Observe the failed request remains in pending state on the Coordinator
Attempt to cancel the subscription via:
Chainlink UI cancel button
Direct contract call to cancelSubscription(subId, recipient) on VRF Coordinator v2.5
Result: Both attempts fail; subscription cannot be cancelled due to "pending request exists" error

Expected Behavior:

VRF Coordinator should implement request timeout logic (similar to v2's 7-day timeout or v2.5's documented 24-hour timeout)
After timeout period, failed requests should be auto-marked as expired/cleaned
Subscription should be cancellable regardless of failed request age

Actual Behavior:

Failed request from November 2025 remains permanently in pending state
No auto-timeout mechanism triggers
Subscription cancellation blocked indefinitely
LINK tokens cannot be withdrawn
Additional Information

Observed Issues:

No Timeout Enforcement: VRF v2.5 documentation suggests request expiration mechanisms exist, but they don't appear to be triggered for "Invalid key hash" status
No Recovery Path: No user-side method to force-expire or clean up failed requests
Support Gap: Chainlink support AI suggests "wait for it to resolve itself," but ~9 months elapsed without resolution
Subscription Lock: The failed request permanently locks the subscription, preventing fund recovery

Potential Root Causes:

Failed requests with "Invalid key hash" status may be excluded from timeout cleanup logic
Timeout logic may only apply to requests with specific error codes, not all failure states
Request state machine may lack cleanup handler for orphaned failed requests

Requested Solutions:

-help me cancel the subscription
-Implement universal request timeout (e.g., 7 days) that applies to ALL request states, including "Invalid key hash"
-Add user-callable recovery function like forceTimeoutRequest(requestId) for subscription owners
-Implement automatic cleanup of failed requests older than expiration window
-Update Coordinator to allow subscription cancellation even with old failed requests, or provide explicit cleanup path

Workaround Attempts:

✗ Chainlink UI cancel button: Blocked by pending request
✗ Direct contract call to cancelSubscription(): Failed with pending request error
✗ Waiting (9+ months): No change
✗ Chainlink support: No response

Wallet & Subscription Details (for testing):

Subscription Owner: Standard EOA (not contract)
Current Status: Active (locked by failed request)
LINK Balance: Locked (unable to withdraw)
All new VRF requests since failed one from Nov 2025 were successful for other approved consumers of this ID

Environment:

Date Reported: July 2026
Time Since Issue: ~9 months (since November 2025)
Severity: High (complete fund lockup)

Start by inspecting the VRF v2.5 Coordinator entry points for cancelSubscription and the request handling associated with the reported "Invalid key hash" state. Trace whether timeout or cleanup logic covers that state, then reproduce the cancellation failure using the supplied subscription and transaction details. Done means an aged failed request no longer prevents subscription cancellation and the behavior is covered by an appropriate test.