gskril / farcaster-indexer Goto Github PK

• Yesterday, I asked on Farcaster whether it is possible to speed up query search results for searchcaster
• I looked into the code and found that it is using the LIKE syntax for text search: https://github.com/gskril/searchcaster/blob/main/src/pages/api/search.js#L162
• I looked through the database migrations to find if a specific full text search index was created: https://github.com/gskril/farcaster-indexer/tree/main/supabase/migrations (it doesn't look like it)

My plan is now to:

• successfully seed the indexer
• run a test query using full text search (and record the time it took)
• work through https://www.postgresql.org/docs/current/datatype-textsearch.html and see if I can improve search result performance
• if so, send a PR

yarn run seed
yarn run v1.22.18
warning ../package.json: No license field
$ tsc && node ./dist/helpers/seed.js
Seeding recent registrations from contract logs...
Error inserting registrations {
code: '42501',
details: null,
hint: null,
message: 'new row violates row-level security policy for table "profile"'
}
Seeding profiles from Merkle APIs...

Hello, please add information what hardware specs are needed to run indexer.

Error thrown when backfilling FIDs 308901 - 309000. The job stopped at 71%, so the issue is likely happening somewhere between FID 308970 - 308975.

When i run yarn kysely:migrate, it report errors: function public.gen_random_bytes(integer) does not exist.
How can i fix it?

Currently, if devs fetch a cast from Searchcaster, it returns children with depth 1. Would it be desirable if it returns all the grandkids per fetch? HN and Reddit does this - when users view a post, all the comments of that post gets displayed. The API looks like this: https://hn.algolia.com/api/v1/items/33757484 (notice that the "children" key recursively contains all the replies). Plus, it would be extra nice if it also returns all the ancestors (all the casts from the root thread to the fetched cast, if there's any).

I'm down to help to make this happen.

Backfill with >1 concurrency will seemingly just miss all the links (or some other data type) for a fid(s) but get all casts, reactions, etc from that user.

The user(s) and data type(s) it skips are inconsistent and there are no errors in the logs. It's as if only part of the getFullProfileFromHub() function is running, or Postgres is somehow missing requests.

Verified by running a backfill with WORKER_CONCURRENCY=5, then running it again with WORKER_CONCURRENCY=1 and seeing that some tables had rows with newer updated_at values even though the message timestamp was old.

Thanks to @stephancill for finding the bug by comparing the number of rows in different tables after backfills with different concurrency values.