fix: re-attempt to replenish the program cache on error

[bmuddha]

Summary by CodeRabbit

• Bug Fixes
  • Enhanced transaction processing reliability with intelligent cache management that automatically optimizes and prunes storage capacity when system limits are encountered, then gracefully retries the operation. This significantly reduces processing failures during high-volume transactions or complex computational scenarios, substantially improving overall system stability, throughput, and operational robustness. The system now handles resource-constrained environments more effectively, ensuring consistent transaction processing success rates.

_{✏️ Tip: You can customize this high-level summary in your review settings.}

[coderabbitai]

Walkthrough

A retry mechanism is added around replenish_program_cache in load_and_execute_sanitized_transactions. On encountering ProgramCacheHitMaxLimit, the program cache is pruned by deployment slot, a retry flag is set, and the operation is attempted once more. Subsequent failures return the error.

Changes

Cohort / File(s)	Summary
Cache replenishment retry logic src/transaction_processor.rs	Adds a retry loop around replenish_program_cache that prunes the cache by deployment slot on first ProgramCacheHitMaxLimit error, sets replenish_retried flag to prevent infinite loops, and retries the operation once before returning error on subsequent failures.

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~20 minutes

• Error path validation: Verify that the retry flag correctly prevents infinite loops and that both success and failure paths are properly handled
• Cache pruning logic: Confirm that pruning by deployment slot is the correct strategy and doesn't inadvertently remove essential cached programs
• Flag initialization and scope: Ensure the replenish_retried flag is initialized correctly and scoped appropriately to prevent state leakage across transaction batches

Pre-merge checks and finishing touches

✅ Passed checks (3 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title accurately describes the main change: implementing a retry mechanism for replenishing the program cache when errors occur.
Docstring Coverage	✅ Passed	Docstring coverage is 100.00% which is sufficient. The required threshold is 80.00%.

✨ Finishing touches

• 📝 Generate docstrings

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment
• Commit unit tests in branch bmuddha/fix/program-cache

---

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: 2

📜 Review details

Configuration used: CodeRabbit UI

Review profile: ASSERTIVE

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 51e1054 and 86c2cb0.

📒 Files selected for processing (1)

• src/transaction_processor.rs (1 hunks)

🔇 Additional comments (2)

src/transaction_processor.rs (2)

370-370: LGTM: Retry flag initialization.

The replenish_retried flag clearly tracks whether a retry attempt has occurred, preventing infinite loops.

---

391-398: Consider whether early return with errors for all transactions is appropriate.

When the program cache hits max limit even after pruning and retry, all transactions in the batch receive ProgramCacheHitMaxLimit errors. This might be overly harsh if only a subset of transactions caused the cache pressure.

However, if the cache cannot be replenished after pruning, continuing execution could lead to incorrect results. Verify this is the intended behavior.

[GabrielePicco]

LGTM!