fix(revenue_recovery): Daily Retry History is being wrongly updated when its an expiry update

[NISHANTH1221]

Type of Change

• Bugfix
• New feature
• Enhancement
• Refactoring
• Dependency updates
• Documentation
• CI/CD

Description

When account updater is done on a particular card token it may result in new token with new details(New Token) or old token with new details(Expiry Update). The bug is that when we were updating the token in case of Expiry update we were copying the daily retry history of the token and sending it to upsert_payment_processor_token function that function get the daily retry history with the new token and get the token from redis and update the redis with the same retry histry which results in count to be doubled

Before doing account updater details
Redis -> Token1 ( daily_retry_history : {"02-12-25": 1} )

after getting
updated old token -> upsert_payment_processor_token ( In this we fetch the existing Token1 daily retry history which is this : ( daily_retry_history : {"02-12-25": 1} ) and we will get updated Token1 which will be same : ( daily_retry_history : {"02-12-25": 1} ) The upset function iterates through the daily_retry_history of the updated Old token and make the net daily retry history as ( daily_retry_history : {"02-12-25": 2} ) .

And second bug is that we shouldn't update the is_hard_decline field just after the expiry update and give it chance to do one more retry. If the hard decline flag is updated to true just after the expiry update then the token wont be picked up again. So there is no point of account updater and we didn't do any retry with the updated expiry details.

Additional Changes

• This PR modifies the API contract
• This PR modifies the database schema
• This PR modifies application configuration/environment variables

Motivation and Context

How did you test it?

Can follow the steps mentioned in #10112 to test this.

Checklist

• I formatted the code cargo +nightly fmt --all
• I addressed lints thrown by cargo clippy
• I reviewed the submitted code
• I added unit tests for my changes where possible

[semanticdiff-com]

Review changes with  

Changed Files

File	Status
crates/router/src/core/revenue_recovery/types.rs	68% smaller
crates/router/src/types/storage/revenue_recovery_redis_operation.rs	18% smaller

[codecov]

Codecov Report

❌ Patch coverage is 0% with 79 lines in your changes missing coverage. Please review.
⚠️ Please upload report for BASE (main@fd058d9). Learn more about missing BASE report.

Files with missing lines	Patch %	Lines
.../types/storage/revenue_recovery_redis_operation.rs	0.00%	55 Missing ⚠️
crates/router/src/core/revenue_recovery/types.rs	0.00%	24 Missing ⚠️

Additional details and impacted files

@@           Coverage Diff           @@
##             main   #10501   +/-   ##
=======================================
  Coverage        ?    6.47%           
=======================================
  Files           ?     1251           
  Lines           ?   311544           
  Branches        ?        0           
=======================================
  Hits            ?    20164           
  Misses          ?   291380           
  Partials        ?        0           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.