feat(lens): update validation method #463
Conversation
🦋 Changeset detectedLatest commit: 645e14a The changes in this PR will be included in the next version bump. This PR includes changesets to release 52 packages
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
packages/lens/src/validate.ts
Outdated
| ) { | ||
| try { | ||
| return await checkMintedUsingBlockspan(actor, collectAddress) | ||
| } catch { |
There was a problem hiding this comment.
how to deal with error handling here?
There was a problem hiding this comment.
If the second check fails we should throw ValidationNotValid
https://github.com/rabbitholegg/rh/blob/main/src/indexer/v4/consumers/sqs-plugin-action-validator.ts#L154C28-L154C46
There was a problem hiding this comment.
It should be caught here and a ValidationNotValid is thrown. Is that okay or should I move this logic into the validateCollect function.
packages/lens/src/validate.ts
Outdated
| import { getClient } from './client' | ||
| import { Chains } from '@rabbitholegg/questdk-plugin-utils' | ||
| import axios from 'axios' | ||
| import dotenv from 'dotenv' |
There was a problem hiding this comment.
Just use process.env directly as done here and see if that works.
There was a problem hiding this comment.
Tried using process.env directly and it did not work. It logs as undefined.
But obviously it has worked for neynar package, so Im a bit confused 🫤
There was a problem hiding this comment.
I think it worked in Neynar because there was a check for process.env
There was a problem hiding this comment.
Did some more testing here, and it looks like as long as you have the environment variable in the RH repo .env file, it will be picked up in the plugin-validator. Ive removed the dotenv file from the lens package, since it is not needed.
|
@Quazia I got the ENV situation sorted out. It should just work as long as we have the ENV variable in the backend repo. I removed the dotenv as a dependancy in the lens package. I also added the |
|
Blockscan not reliable. It does not update fast enough. Took roughly 5 minutes for it to pick up the collect |
|
Switched to use Alchemy SDK. It is appears to be extremely fast to pick up and index fresh mint transactions and is quite responsive. Another benefit of using alchemy is that we already have an api key environment variable available. Pretty happy with the results. |
| const settings = { | ||
| apiKey: process.env.ALCHEMY_API_KEY, | ||
| network: Network.MATIC_MAINNET, | ||
| requestTimeout: 2000, |
There was a problem hiding this comment.
It isn't required, but I put an arbitrary value as the requestTimeout. Thought was to let it timeout soonish and hit the reservoir backup. I couldn't find the default value and didn't want it to hang for too long.
Not sure if this is too much or too little.
| ) | ||
|
|
||
| // only count nfts that originate from zeroAddress | ||
| const mintedNfts = transfers.nfts.filter((nft) => nft.from === zeroAddress) |
There was a problem hiding this comment.
Clever - you know we could actually handle this just with the contract Transfer events. Just ship this implementation though that's hilarious it's full circle though.
After checking through several api providers, the best suited one is blockspan, as it has the needed lookup for our usecase, and it has generous rate-limits available. It does require an api key, so we will need to set up an environment variable.Choose to use Alchemy SDK instead of blockspan due to high latency for the api to index new mints transactions.
Reservoir api will be used as a backup option in case
blockspanalchemy goes down or gets rate-limited. Reservoir does not require an API key, but adding one would increase the limits.There is minimal latency using this method, with most requests taking between 600-1000ms, which is around the same as the previous validation methods.
Will need to add theBLOCKSPAN_API_KEYto heroku.We already have an
ALCHEMY_API_KEYavailable, so no new env variables are required.