Conversation
|
Are we missing the code refactor to use the new flag on the users table? |
There was a problem hiding this comment.
Pull request overview
Adds a database-level optimization for NIP-62 “request-to-vanish” checks by introducing a persisted users.is_vanished flag and backfilling it from existing kind-62 events, reducing reliance on repeated events table lookups.
Changes:
- Add
is_vanishedboolean column to theuserstable (defaultfalse, not nullable). - Backfill
is_vanished = truefor users with non-deleted kind-62 events and insert missingusersrows for pubkeys that have active kind-62 events.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| await knex.raw(` | ||
| INSERT INTO users (pubkey, is_admitted, balance, is_vanished, created_at, updated_at) | ||
| SELECT DISTINCT e.event_pubkey, false, 0, true, NOW(), NOW() | ||
| FROM events e | ||
| LEFT JOIN users u ON u.pubkey = e.event_pubkey | ||
| WHERE e.event_kind = 62 | ||
| AND e.deleted_at IS NULL | ||
| AND u.pubkey IS NULL | ||
| `) | ||
| } | ||
|
|
||
| exports.down = function (knex) { | ||
| return knex.schema.alterTable('users', (table) => { | ||
| table.dropColumn('is_vanished') | ||
| }) |
There was a problem hiding this comment.
Yes , the current code is adding users from the events table which is a wrong practice.We should handle missing users at runtime. User existence should be checked at event receiving instance and if user doesn't exist ,we create the user first and then apply the vanish check logic.I am thinking about going with (B) approach. Please add your suggestion and feedback for it
There was a problem hiding this comment.
We can handle missing users in event handler. When a event comes , it will check its existence and then create a new user if does not exist and then continue with flow,
| FROM events e | ||
| WHERE u.pubkey = e.event_pubkey | ||
| AND e.event_kind = 62 | ||
| AND e.deleted_at IS NULL |
There was a problem hiding this comment.
Will fix this re-addition of users by adding a EXIST check in next commit with other changes
This PR introduces a new
is_vanishedcolumn on theuserstable to support a more efficient way of handling NIP-62 (request-to-vanish) checks.Related Issue
Currently NIP-62 query the
eventstable for active kind-62 records on every check.Fixes issue #436
Motivation and Context
The relay have to check every pubkey for an active request-to-vanish by querying events.As events volume grows ,this becomes less efficient. So we introduced a
is_vanishedflag in users table for faster checks.How Has This Been Tested?
npm run build:checknpm run test:unit(504 passing)Types of changes
Checklist: