Skip to content

fix(nft): re-evaluate previous owner's eligibility on NFT ownership change#243

Open
rdmcd wants to merge 1 commit intoOpenBuilders:mainfrom
rdmcd:fix/nft-update-evicts-previous-owner-main
Open

fix(nft): re-evaluate previous owner's eligibility on NFT ownership change#243
rdmcd wants to merge 1 commit intoOpenBuilders:mainfrom
rdmcd:fix/nft-update-evicts-previous-owner-main

Conversation

@rdmcd
Copy link
Copy Markdown
Contributor

@rdmcd rdmcd commented May 6, 2026

Bug

When fetch_wallet_details runs for the new owner of an NFT (because the
transaction tracker observed activity on that address),
NftItemService.bulk_create_or_update overwrites nft.owner_address from
A to B. After completion, only the new owner's address (B) is added to
UPDATED_WALLETS_SET_NAME, so check-chat-members only re-evaluates B —
who is correctly eligible.

The previous owner A is never put into UPDATED_WALLETS_SET_NAME, so
check-chat-members does not re-evaluate them. They keep sitting in any
chat whose rules required this NFT, even though the DB already reflects
that they no longer own it.

Fix

NftItemService.bulk_create_or_update now returns a second value — the
set of addresses that lost ownership in this batch — alongside the
persisted items. The caller
(indexer_blockchain.tasks.fetch_wallet_details) forwards those addresses
into UPDATED_WALLETS_SET_NAME so check-chat-members re-evaluates them on
its next tick and kicks them via the existing path if the rule no longer
holds.

The Redis side-effect is intentionally kept out of the service layer — the
service stays data-access only, and the orchestration (Celery task) owns
the side-effects.

Tests

tests/unit/core/services/test_nft_item_service.py:

  • ownership change → previous owner returned in the evicted set
  • ownership unchanged → empty set
  • new NFT (_create path) → empty set
  • non-whitelisted collection skipped → empty set

Copilot AI review requested due to automatic review settings May 6, 2026 17:13
…hange

When fetch_wallet_details runs for the new owner of an NFT, the previous
owner is never queued into UPDATED_WALLETS_SET_NAME, so check-chat-members
does not re-evaluate them. They keep sitting in any chat whose rules
required this NFT, even though the DB already reflects that they no longer
own it.

NftItemService.bulk_create_or_update now returns the set of addresses that
lost ownership in the batch alongside the persisted items. The caller
(indexer_blockchain.tasks.fetch_wallet_details) forwards those addresses
into UPDATED_WALLETS_SET_NAME so check-chat-members picks them up via the
existing path. The service stays data-access only; the orchestration owns
the side-effects.
Copy link
Copy Markdown
Collaborator

@danoctua danoctua left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OK as a hot fix to mitigate side effects, but still won't work if tracked user transfers NFT to non-tracked, and event for tracked is not sent – we should work on improving the stability of delivered events for the long term instead.

@rdmcd rdmcd force-pushed the fix/nft-update-evicts-previous-owner-main branch from 67a0d5c to 8e19b72 Compare May 6, 2026 17:29
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants