Fix: use ILIKE instead of == for address comparison.

[1yam]

Camel case issue on

https://api2.aleph.im/api/v0/addresses/0xA6a49d09321f701AB4295e5eB115E65EcF9b83B5/balance WORK
https://api2.aleph.im/api/v0/addresses/0xa6a49d09321f701ab4295e5eb115e65ecf9b83b5/balance FAILED

http://51.159.106.166:4024/api/v0/addresses/0xA6a49d09321f701AB4295e5eB115E65EcF9b83B5/balance WORK
http://51.159.106.166:4024/api/v0/addresses/0xa6a49d09321f701ab4295e5eb115e65ecf9b83b5/balance WORK

Changes

This pull request updates the logic for querying balances in the get_total_detailed_balance function to improve address matching. Instead of requiring an exact match, the queries now use case-insensitive matching for addresses, which helps handle variations in address formatting and improves robustness.

Improvements to balance querying:

• Updated all relevant queries in src/aleph/db/accessors/balances.py to use AlephBalanceDb.address.ilike(address) for case-insensitive address matching instead of strict equality. [1] [2] [3]

Improvements to address matching in balance queries:

• Updated address comparison from == to ilike in three queries within get_total_detailed_balance in src/aleph/db/accessors/balances.py to enable case-insensitive address matching. [1] [2] [3]

Notes

Things that the reviewers should know: known bugs that are out of the scope of the PR, other trade-offs that were made.
If the PR depends on a PR in another repo, or merges into another PR (i.o. main), it should also be mentioned here

[Copilot]

Pull Request Overview

This pull request addresses a case-sensitivity issue in address comparisons for balance queries. The changes modify the get_total_detailed_balance function to use case-insensitive matching instead of exact equality checks, resolving an issue where addresses with different casing (e.g., mixed case vs lowercase Ethereum addresses) would fail to match.

Key changes:

• Updated three SQL queries in get_total_detailed_balance to use ilike instead of == for address comparison
• Enables case-insensitive address lookups for balance retrieval across chains

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

Using ilike for address comparison is problematic because it's a SQL pattern matching operator that treats % and _ as wildcards. If an address contains these characters, they will be interpreted as wildcards rather than literal characters, potentially matching multiple addresses incorrectly.

For case-insensitive exact matching, consider using func.lower() on both sides of the comparison instead:

func.lower(AlephBalanceDb.address) == func.lower(address)

This approach:

• Performs exact case-insensitive matching without wildcard interpretation
• Is clearer in intent
• Maintains SQL injection safety
• Can potentially use functional indexes if needed for performance

[Copilot]

Using ilike for address comparison is problematic because it's a SQL pattern matching operator that treats % and _ as wildcards. If an address contains these characters, they will be interpreted as wildcards rather than literal characters, potentially matching multiple addresses incorrectly.

For case-insensitive exact matching, consider using func.lower() on both sides of the comparison instead:

func.lower(AlephBalanceDb.address) == func.lower(address)

This approach:

• Performs exact case-insensitive matching without wildcard interpretation
• Is clearer in intent
• Maintains SQL injection safety
• Can potentially use functional indexes if needed for performance

[Copilot]

Using ilike for address comparison is problematic because it's a SQL pattern matching operator that treats % and _ as wildcards. If an address contains these characters, they will be interpreted as wildcards rather than literal characters, potentially matching multiple addresses incorrectly.

For case-insensitive exact matching, consider using func.lower() on both sides of the comparison instead:

func.lower(AlephBalanceDb.address) == func.lower(address)

This approach:

• Performs exact case-insensitive matching without wildcard interpretation
• Is clearer in intent
• Maintains SQL injection safety
• Can potentially use functional indexes if needed for performance

[Copilot]

Inconsistent address comparison methods across the codebase. While get_total_detailed_balance now uses case-insensitive matching, other functions in the same file (get_balance_by_chain at line 22 and get_total_balance at line 69) still use exact match (==).

This inconsistency could lead to:

• Different results for the same address with different casing across different API endpoints
• Confusion for developers maintaining this code
• Unexpected behavior for API consumers

Consider applying the same case-insensitive logic consistently across all address comparison functions in this file.

[moshemalawach]

I would prefer to fix the issues upstream... ie: check where we get non-checksummed addresses.
It opens the door for a lot of issues if we start treating the addresses in a case insensitive way.

[1yam]

I would prefer to fix the issues upstream... ie: check where we get non-checksummed addresses. It opens the door for a lot of issues if we start treating the addresses in a case insensitive way.

We thought there was an issue and that we needed this change here as well, but we were receiving the user’s address in the wrong format. That made us believe the error was still present, while in fact it was already fixed by restarting nodestatus.

I think we can close this PR.