Stable verify contracts

[mirooon]

Which Jira task belongs to this PR?

Why did I implement it this way?

Checklist before requesting a review

• I have performed a self-review of my code
• This pull request is as small as possible and only tackles one problem
• I have added tests that cover the functionality / test the bug
• For new facets: I have checked all points from this list: https://www.notion.so/lifi/New-Facet-Contract-Checklist-157f0ff14ac78095a2b8f999d655622e
• I have updated any required documentation

Checklist for reviewer (DO NOT DEPLOY and contracts BEFORE CHECKING THIS!!!)

• I have checked that any arbitrary calls to external contracts are validated and or restricted
• I have checked that any privileged calls (i.e. storage modifications) are validated and or restricted
• I have ensured that any new contracts have had AT A MINIMUM 1 preliminary audit conducted on by <company/auditor>

[coderabbitai]

Walkthrough

Updates configuration for the stable network across multiple files: switches explorer API from Blockscout to Etherscan v2 in networks.json and foundry.toml, removes devNotes field, and marks numerous smart contract deployments as verified in the deployment log.

Changes

Cohort / File(s)	Change Summary
Network Configuration config/networks.json, foundry.toml	Updated stable network's explorer API endpoint from Blockscout (partners-explorer.stable.xyz) to Etherscan v2 API (api.etherscan.io/v2); switched API key environment variable from BLOCKSCOUT_API_KEY to MAINNET_ETHERSCAN_API_KEY; removed devNotes field from stable network entry
Deployment Verification Log deployments/_deployments_log_file.json	Flipped VERIFIED status from "false" to "true" across multiple smart contract deployment entries
Code Formatting script/deploy/shared/cached-deployment-querier.ts	Reformatted return expression in findByAddress method to multiline formatting

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~10 minutes

• Configuration changes are straightforward and self-contained
• Deployment log updates are voluminous but highly repetitive (all VERIFIED flag flips follow identical pattern)
• Code formatting change is cosmetic with no behavioral impact

Possibly related PRs

• deployed glacis to katana, mantle, sei #1261: Modifies etherscan entries in foundry.toml configuration for different networks
• re-use Etherscan API key for other networks #944: Updates foundry.toml to use MAINNET_ETHERSCAN_API_KEY across multiple network entries
• Fix issue in log function #1248: Updates VERIFIED field in deployment log entries with related verification status handling

Suggested labels

AuditNotRequired

Pre-merge checks and finishing touches

❌ Failed checks (2 inconclusive)

Check name	Status	Explanation	Resolution
Title check	❓ Inconclusive	The title 'Stable verify contracts' is vague and generic; it lacks specificity about what verification work was done or what changed.	Use a more descriptive title that clarifies the main change, such as 'Update stable network explorer configuration and verify contracts' or 'Migrate stable network to Etherscan API and verify deployments'.
Description check	❓ Inconclusive	The description follows the template structure but lacks substantive content; the Jira task and rationale sections are empty, and only basic checklist items are marked without context.	Fill in the Jira task reference and provide a clear explanation of why the stable network configuration was changed and what contracts are being verified.

✅ Passed checks (1 passed)

Check name	Status	Explanation
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

✨ 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 stable-verify-contracts

---

📜 Recent review details

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro

Disabled knowledge base sources:

• Jira integration is disabled by default for public repositories

You can enable these sources in your CodeRabbit configuration.

📥 Commits

Reviewing files that changed from the base of the PR and between cce33e0 and d9bec3e.

📒 Files selected for processing (4)

• config/networks.json (1 hunks)
• deployments/_deployments_log_file.json (26 hunks)
• foundry.toml (1 hunks)
• script/deploy/shared/cached-deployment-querier.ts (1 hunks)

🧰 Additional context used

📓 Path-based instructions (3)

**/*.{ts,tsx}

📄 CodeRabbit inference engine (.cursor/rules/099-finish.mdc)

After TypeScript changes, run lint/tests with Bun

Files:

• script/deploy/shared/cached-deployment-querier.ts

{src,script,test}/**/*.{sol,ts}

📄 CodeRabbit inference engine (.cursor/rules/105-security.mdc)

Validate all external inputs and configuration (including script/env values) explicitly; prefer existing validation helpers (e.g., Validatable, config readers) over ad-hoc checks

Files:

• script/deploy/shared/cached-deployment-querier.ts

{script,tasks}/**/*.ts

📄 CodeRabbit inference engine (.cursor/rules/200-typescript.mdc)

{script,tasks}/**/*.ts: TS scripts use .eslintrc.cjs rules, bunx tsx, citty, consola, and env validated via helpers (e.g., getEnvVar()).
DO NOT use deprecated ethers-based helpers (getProvider, getWalletFromPrivateKeyInDotEnv, ethers sendTransaction, ensureBalanceAndAllowanceToDiamond).
Obey .eslintrc.cjs; avoid any; use TypeChain types from typechain/ directory (e.g., ILiFi.BridgeDataStruct).
Import organization: Group imports as: external libs (viem, consola, citty, dotenv) → TypeChain types → config files → internal utils/helpers. Use type imports for types-only.
Error handling: Use try/catch with consola.error() for logging; exit with process.exit(1) on fatal errors. Provide meaningful error messages.
CLI: use citty; logging via consola; validate env via getEnvVar(); exit 0/1 appropriately.
New TypeScript helpers must be covered by a colocated *.test.ts file using Bun (describe / it / expect) with 100% coverage. Cover edge cases and error paths.

Files:

• script/deploy/shared/cached-deployment-querier.ts

🧠 Learnings (23)

📓 Common learnings

Learnt from: 0xDEnYO
Repo: lifinance/contracts PR: 1256
File: deployments/zksync.diamond.json:81-87
Timestamp: 2025-07-04T08:59:08.108Z
Learning: When analyzing deployment PRs in the lifinance/contracts repository, carefully verify that target state configuration files (like script/deploy/_targetState.json) have been updated before flagging missing entries. The AI summary section should be consulted to understand all file changes, as manual searches might miss entries due to formatting differences or search limitations.

Learnt from: mirooon
Repo: lifinance/contracts PR: 1283
File: deployments/ronin.diamond.json:65-68
Timestamp: 2025-08-07T10:20:01.383Z
Learning: When analyzing deployment PRs in the lifinance/contracts repository, carefully verify that target state configuration files (like script/deploy/_targetState.json) and deployment log files have been updated before flagging missing entries. The AI summary section should be consulted to understand all file changes, as manual searches might miss entries due to formatting differences or search limitations.

Learnt from: 0xDEnYO
Repo: lifinance/contracts PR: 1334
File: deployments/mainnet.json:54-54
Timestamp: 2025-08-26T02:20:52.515Z
Learning: For deployment PRs in the lifinance/contracts repository, carefully verify the specific scope mentioned in the PR title and description before suggesting updates to other networks. Not all deployments are cross-network updates - some are targeted to specific chains only.

Learnt from: 0xDEnYO
Repo: lifinance/contracts PR: 1109
File: deployments/worldchain.json:28-28
Timestamp: 2025-04-21T03:17:53.443Z
Learning: For deployment PRs updating contract addresses (like RelayFacet on Worldchain), verify the presence of entries in all relevant files (worldchain.json, worldchain.diamond.json, _deployments_log_file.json) before reporting inconsistencies. The RelayFacet entry exists in all required deployment files with the correct address.

Learnt from: 0xDEnYO
Repo: lifinance/contracts PR: 1168
File: script/deploy/_targetState.json:1564-1589
Timestamp: 2025-05-27T12:36:26.987Z
Learning: When reviewing deployment PRs in the lifinance/contracts repository, target state configuration files (like script/deploy/_targetState.json) may be updated for multiple networks even when the PR is focused on deploying to a specific network. The scope should be determined by the PR title and description, not just by all configuration changes present in the files.

Learnt from: mirooon
Repo: lifinance/contracts PR: 1283
File: deployments/ronin.diamond.json:65-68
Timestamp: 2025-08-07T10:20:01.383Z
Learning: When analyzing deployment PRs in the lifinance/contracts repository, understand that _targetState.json tracks contract version numbers (not addresses) and _deployments_log_file.json contains deployment records with addresses that may not be organized in obvious network sections. Always verify the actual file structure before flagging missing entries.

Learnt from: mirooon
Repo: lifinance/contracts PR: 1187
File: .github/workflows/versionControlAndAuditCheck.yml:596-612
Timestamp: 2025-06-05T11:25:43.443Z
Learning: The user mirooon has an internal system for tracking tickets and technical debt. They acknowledged the security concern about disabled commit hash verification in the audit workflow and plan to implement conditional logic to skip verification only for revert PRs in a future update.

Learnt from: 0xDEnYO
Repo: lifinance/contracts PR: 1109
File: deployments/worldchain.json:28-28
Timestamp: 2025-04-21T03:17:53.443Z
Learning: For deployment PRs involving address updates like the RelayFacet to Worldchain, verify the actual presence of entries in files before reporting issues. The RelayFacet exists in the diamond log file and the PR diff already contains the necessary address change.

Learnt from: 0xDEnYO
Repo: lifinance/contracts PR: 1357
File: deployments/lens.diamond.json:48-51
Timestamp: 2025-09-09T10:39:26.383Z
Learning: In the lifinance/contracts repository, when deployment JSON files show address changes (like AcrossFacetV3 address updates in deployments/*.diamond.json), the corresponding _deployments_log_file.json updates may be handled in separate PRs rather than the same PR that updates the diamond configuration files.

Learnt from: 0xDEnYO
Repo: lifinance/contracts PR: 819
File: deployments/boba.diamond.json:68-68
Timestamp: 2024-10-09T03:47:21.269Z
Learning: In the `lifinance/contracts` repository, `ReceiverStargateV2` may not be deployed to all networks, and it's acceptable for its address to remain empty in deployment files when it is not deployed. PRs unrelated to `ReceiverStargateV2` should not raise comments about its absence.

Learnt from: mirooon
Repo: lifinance/contracts PR: 1283
File: config/networks.json:837-839
Timestamp: 2025-07-17T11:31:50.058Z
Learning: In config/networks.json for the Ronin network (chainId 2020), there is a problematic mismatch between verificationType ("blockscout") and explorerApiUrl ("https://sourcify.roninchain.com/server"). This inconsistency can lead to verification issues and should be flagged when networks.json is modified in future PRs.

Learnt from: mirooon
Repo: lifinance/contracts PR: 1524
File: config/whitelist.json:4358-4366
Timestamp: 2025-12-10T17:36:54.412Z
Learning: Repo lifinance/contracts: In config/whitelist.json, temporary network keys (e.g., "stable") may appear under DEX entries (such as Fly) while deployments are in progress and the corresponding chain configuration PR hasn’t merged yet. This is expected, does not break the workflow, and should not be flagged as an unsupported chain key.

Learnt from: ezynda3
Repo: lifinance/contracts PR: 861
File: config/global.json:146-146
Timestamp: 2024-11-21T08:34:30.300Z
Learning: The project is deprecating `safeAddresses` and `safeApiUrls` in `global.json` and moving these configurations to `config/networks.json` for network configurations.

Learnt from: ezynda3
Repo: lifinance/contracts PR: 861
File: script/deploy/safe/add-owners-to-safe.ts:8-13
Timestamp: 2024-11-21T08:24:05.881Z
Learning: In `script/deploy/safe/add-owners-to-safe.ts`, validation for network configuration when casting imported JSON data to `NetworksObject` is not required as per the user's preference.

Learnt from: mirooon
Repo: lifinance/contracts PR: 985
File: deployments/bsca.json:0-0
Timestamp: 2025-02-12T09:44:10.963Z
Learning: When setting up new network deployments, it's expected that contract addresses in the deployment JSON files (e.g., bsca.json, bscb.json) may not have deployed code initially, as these files serve as target configurations for future deployments.

Learnt from: mirooon
Repo: lifinance/contracts PR: 1328
File: docs/LDAPeripheryRegistryFacet.md:14-27
Timestamp: 2025-08-29T14:05:25.335Z
Learning: mirooon prefers interface-level documentation to focus on the API contract and function purposes rather than implementation details like access control restrictions or specific modifiers, keeping documentation clean and consumable at the interface level.

📚 Learning: 2024-12-04T12:57:56.493Z

Learnt from: ezynda3
Repo: lifinance/contracts PR: 875
File: script/utils/fetch-missing-deployments.ts:0-0
Timestamp: 2024-12-04T12:57:56.493Z
Learning: In the TypeScript file `script/utils/fetch-missing-deployments.ts`, the existing regex pattern `/\/\/\/\s*custom:version\s*([\d.]+)/` used for version extraction is sufficient and does not require modification.

Applied to files:

• script/deploy/shared/cached-deployment-querier.ts

📚 Learning: 2025-04-21T03:17:53.443Z

Learnt from: 0xDEnYO
Repo: lifinance/contracts PR: 1109
File: deployments/worldchain.json:28-28
Timestamp: 2025-04-21T03:17:53.443Z
Learning: For deployment PRs involving address updates like the RelayFacet to Worldchain, verify the actual presence of entries in files before reporting issues. The RelayFacet exists in the diamond log file and the PR diff already contains the necessary address change.

Applied to files:

• script/deploy/shared/cached-deployment-querier.ts
• deployments/_deployments_log_file.json

📚 Learning: 2025-07-04T08:59:08.108Z

Learnt from: 0xDEnYO
Repo: lifinance/contracts PR: 1256
File: deployments/zksync.diamond.json:81-87
Timestamp: 2025-07-04T08:59:08.108Z
Learning: When analyzing deployment PRs in the lifinance/contracts repository, carefully verify that target state configuration files (like script/deploy/_targetState.json) have been updated before flagging missing entries. The AI summary section should be consulted to understand all file changes, as manual searches might miss entries due to formatting differences or search limitations.

Applied to files:

• script/deploy/shared/cached-deployment-querier.ts
• deployments/_deployments_log_file.json

📚 Learning: 2025-08-07T10:20:01.383Z

Learnt from: mirooon
Repo: lifinance/contracts PR: 1283
File: deployments/ronin.diamond.json:65-68
Timestamp: 2025-08-07T10:20:01.383Z
Learning: When analyzing deployment PRs in the lifinance/contracts repository, carefully verify that target state configuration files (like script/deploy/_targetState.json) and deployment log files have been updated before flagging missing entries. The AI summary section should be consulted to understand all file changes, as manual searches might miss entries due to formatting differences or search limitations.

Applied to files:

• script/deploy/shared/cached-deployment-querier.ts
• deployments/_deployments_log_file.json

📚 Learning: 2025-04-21T03:17:53.443Z

Learnt from: 0xDEnYO
Repo: lifinance/contracts PR: 1109
File: deployments/worldchain.json:28-28
Timestamp: 2025-04-21T03:17:53.443Z
Learning: For deployment PRs updating contract addresses (like RelayFacet on Worldchain), verify the presence of entries in all relevant files (worldchain.json, worldchain.diamond.json, _deployments_log_file.json) before reporting inconsistencies. The RelayFacet entry exists in all required deployment files with the correct address.

Applied to files:

• script/deploy/shared/cached-deployment-querier.ts
• deployments/_deployments_log_file.json

📚 Learning: 2025-12-10T17:36:54.412Z

Learnt from: mirooon
Repo: lifinance/contracts PR: 1524
File: config/whitelist.json:4358-4366
Timestamp: 2025-12-10T17:36:54.412Z
Learning: Repo lifinance/contracts: In config/whitelist.json, temporary network keys (e.g., "stable") may appear under DEX entries (such as Fly) while deployments are in progress and the corresponding chain configuration PR hasn’t merged yet. This is expected, does not break the workflow, and should not be flagged as an unsupported chain key.

Applied to files:

• foundry.toml
• config/networks.json

📚 Learning: 2025-07-17T11:31:50.058Z

Learnt from: mirooon
Repo: lifinance/contracts PR: 1283
File: config/networks.json:837-839
Timestamp: 2025-07-17T11:31:50.058Z
Learning: In config/networks.json for the Ronin network (chainId 2020), there is a problematic mismatch between verificationType ("blockscout") and explorerApiUrl ("https://sourcify.roninchain.com/server"). This inconsistency can lead to verification issues and should be flagged when networks.json is modified in future PRs.

Applied to files:

• foundry.toml
• config/networks.json

📚 Learning: 2025-01-22T07:30:01.787Z

Learnt from: 0xDEnYO
Repo: lifinance/contracts PR: 944
File: foundry.toml:77-109
Timestamp: 2025-01-22T07:30:01.787Z
Learning: Etherscan V2 API (api.etherscan.io/v2/api) supports contract verification across 30+ networks using the chainId parameter in the URL. Network-specific API endpoints are not required when using V2 API.

Applied to files:

• foundry.toml

📚 Learning: 2025-01-16T00:24:10.002Z

Learnt from: 0xDEnYO
Repo: lifinance/contracts PR: 927
File: foundry.toml:78-78
Timestamp: 2025-01-16T00:24:10.002Z
Learning: Avalanche chain (chainid=43114) is supported by Etherscan V2 API and can use the endpoint https://api.etherscan.io/v2/api?chainid=43114 instead of Snowtrace.

Applied to files:

• foundry.toml

📚 Learning: 2025-08-07T10:20:01.383Z

Learnt from: mirooon
Repo: lifinance/contracts PR: 1283
File: deployments/ronin.diamond.json:65-68
Timestamp: 2025-08-07T10:20:01.383Z
Learning: When analyzing deployment PRs in the lifinance/contracts repository, understand that _targetState.json tracks contract version numbers (not addresses) and _deployments_log_file.json contains deployment records with addresses that may not be organized in obvious network sections. Always verify the actual file structure before flagging missing entries.

Applied to files:

• deployments/_deployments_log_file.json

📚 Learning: 2025-05-28T17:33:33.959Z

Learnt from: mirooon
Repo: lifinance/contracts PR: 1170
File: deployments/_deployments_log_file.json:28060-28072
Timestamp: 2025-05-28T17:33:33.959Z
Learning: Deployment log files like `deployments/_deployments_log_file.json` are historical records that document the actual versions deployed at specific times. They should not be updated to match current contract versions - they must accurately reflect what was deployed when the deployment occurred.

Applied to files:

• deployments/_deployments_log_file.json

📚 Learning: 2025-09-09T10:39:26.383Z

Learnt from: 0xDEnYO
Repo: lifinance/contracts PR: 1357
File: deployments/lens.diamond.json:48-51
Timestamp: 2025-09-09T10:39:26.383Z
Learning: In the lifinance/contracts repository, when deployment JSON files show address changes (like AcrossFacetV3 address updates in deployments/*.diamond.json), the corresponding _deployments_log_file.json updates may be handled in separate PRs rather than the same PR that updates the diamond configuration files.

Applied to files:

• deployments/_deployments_log_file.json

📚 Learning: 2025-05-28T17:33:10.529Z

Learnt from: mirooon
Repo: lifinance/contracts PR: 1170
File: deployments/_deployments_log_file.json:28706-28717
Timestamp: 2025-05-28T17:33:10.529Z
Learning: Deployment log files (like `_deployments_log_file.json`) are historical records that should not be updated to match current contract versions. They should accurately reflect the versions that were actually deployed at specific timestamps.

Applied to files:

• deployments/_deployments_log_file.json

📚 Learning: 2024-09-30T03:52:27.281Z

Learnt from: 0xDEnYO
Repo: lifinance/contracts PR: 812
File: deployments/_deployments_log_file.json:1914-1927
Timestamp: 2024-09-30T03:52:27.281Z
Learning: Duplicate entries in `deployments/_deployments_log_file.json` that are outdated do not require changes.

Applied to files:

• deployments/_deployments_log_file.json

📚 Learning: 2024-10-08T07:14:52.296Z

Learnt from: 0xDEnYO
Repo: lifinance/contracts PR: 825
File: config/networks.json:462-462
Timestamp: 2024-10-08T07:14:52.296Z
Learning: In the `networks.json` file and related configuration files, when updating the `name` property of a network (e.g., from `Scroll` to `zkScroll`), the key of the network object should remain unchanged (e.g., `'scroll'`) to ensure it matches references elsewhere in the codebase.

Applied to files:

• config/networks.json

📚 Learning: 2024-11-21T08:34:30.300Z

Learnt from: ezynda3
Repo: lifinance/contracts PR: 861
File: config/global.json:146-146
Timestamp: 2024-11-21T08:34:30.300Z
Learning: The project is deprecating `safeAddresses` and `safeApiUrls` in `global.json` and moving these configurations to `config/networks.json` for network configurations.

Applied to files:

• config/networks.json

📚 Learning: 2025-08-28T02:02:56.965Z

Learnt from: 0xDEnYO
Repo: lifinance/contracts PR: 1136
File: config/dexs.json:0-0
Timestamp: 2025-08-28T02:02:56.965Z
Learning: Different networks in config/dexs.json naturally and appropriately have different DEX addresses. Do not flag different addresses across different networks as issues - only flag if the same network's addresses appear to have changed unintentionally between branches.

Applied to files:

• config/networks.json

📚 Learning: 2025-08-07T06:42:38.555Z

Learnt from: 0xDEnYO
Repo: lifinance/contracts PR: 1316
File: config/networks.json:0-0
Timestamp: 2025-08-07T06:42:38.555Z
Learning: For zkEVM networks in config/networks.json, it's correct for the `create3Factory` field to be missing entirely rather than set to a placeholder address, as deployment scripts skip CREATE3 factory deployment on zkEVM chains.

Applied to files:

• config/networks.json

📚 Learning: 2024-11-18T07:19:28.651Z

Learnt from: 0xDEnYO
Repo: lifinance/contracts PR: 858
File: config/networks.json:17-17
Timestamp: 2024-11-18T07:19:28.651Z
Learning: In the `config/networks.json` file, it's expected that the `safeWebUrl` field may have different formats and URLs across networks; standardizing them is not desired.

Applied to files:

• config/networks.json

📚 Learning: 2024-11-21T08:24:05.881Z

Learnt from: ezynda3
Repo: lifinance/contracts PR: 861
File: script/deploy/safe/add-owners-to-safe.ts:8-13
Timestamp: 2024-11-21T08:24:05.881Z
Learning: In `script/deploy/safe/add-owners-to-safe.ts`, validation for network configuration when casting imported JSON data to `NetworksObject` is not required as per the user's preference.

Applied to files:

• config/networks.json

📚 Learning: 2024-11-22T08:50:28.878Z

Learnt from: ezynda3
Repo: lifinance/contracts PR: 827
File: config/networks.json:448-448
Timestamp: 2024-11-22T08:50:28.878Z
Learning: In `config/networks.json`, Safe addresses (`safeAddress` fields) do not need to be verified, as they are handled separately.

Applied to files:

• config/networks.json

📚 Learning: 2024-11-25T09:05:43.045Z

Learnt from: 0xDEnYO
Repo: lifinance/contracts PR: 782
File: deployments/base.diamond.json:148-148
Timestamp: 2024-11-25T09:05:43.045Z
Learning: In deployment configuration files (e.g., `deployments/base.diamond.json`), empty addresses for contracts like `Permit2Proxy` may be placeholders and will be updated after approvals are released from the multisig safe.

Applied to files:

• config/networks.json

⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)

• GitHub Check: run-unit-tests

🔇 Additional comments (4)

script/deploy/shared/cached-deployment-querier.ts (1)

134-138: LGTM!

The formatting change improves readability with no logic impact.

foundry.toml (1)

164-164: LGTM!

The migration from Blockscout to Etherscan v2 API is consistent with the networks.json configuration change and follows the standard pattern used for other networks.

config/networks.json (1)

1083-1083: Verify that Etherscan v2 API fully supports contract verification for chainId 988 (Stable network).

Etherscan API V2 provides access across 60+ chain IDs, and contract verification endpoints are available across all supported networks. While extensive multi-chain support is documented, explicit confirmation of chainId 988 support requires checking the official Etherscan supported chains list at docs.etherscan.io/supported-chains.

deployments/_deployments_log_file.json (1)

1251-1251: Verification status updates look correct.

All 26 entries consistently update the VERIFIED field to "true", aligning with the PR objective and the explorer API migration from Blockscout to Etherscan v2 configured in the accompanying networks.json and foundry.toml changes.

Also applies to: 2496-2496, 3740-3740, 5297-5297, 6551-6551, 7785-7785, 9029-9029, 10233-10233, 12527-12527, 16447-16447, 17805-17805, 18951-18951, 27603-27603, 30615-30615, 32294-32294, 32985-32985, 33567-33567, 35104-35104, 36222-36222, 39037-39037, 40452-40452, 42026-42026, 43607-43607, 44661-44661, 45792-45792, 47595-47595

Warning

Review ran into problems

🔥 Problems

Errors were encountered while retrieving linked issues.

Errors (1)

• JIRA integration encountered authorization issues. Please disconnect and reconnect the integration in the CodeRabbit UI.

---

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.}