P0 - Save failed donations reported by back-up service

[MoeNick]

As we now have a backup service that saves the lost donations in MongoDB, we need a flow to save them in the impact-graph again and mark them as saved.

Questions:

• When do we save? what will be the flow?
• Do we have the missed items in data like price? How we could fetch it?
• How do we mark them as save and what information we will add for tracking?

I invite @aminlatifi @jainkrati @mhmdksh @mohammadranjbarz @CarlosQ96 and @MohammadPCh @geleeroyale to discuss here and make a decision ASAP as it's a p0 story.

[MoeNick]

FYI: @laurenluz @divine-comedian

[laurenluz]

If it's possible, I would ideally like to add the saved donations at least once/day so that we can have up to date information about round stats every day.

Just my 2 cents :) looking forward to hearing from the masterminds

[jainkrati]

• When do we save? what will be the flow? : We can save every 8 hours. That would be ideal for most time zones.Flow could be: Backup service dumps transactions to be backed up in redis from where we add to DB every 8 hours and then delete. @mhmdksh what are your thoughts here?
• Do we have the missed items in data like price? How we could fetch it? : There are historical token prices which we can fetch from some chainlink historical price feed api or with an API like https://docs.moralis.io/web3-data-api/evm/how-to-get-historical-erc20-token-price;
• How do we mark them as save and what information we will add for tracking? : We could mark all mongoDB entries as 'Pending' by default. This is a one time operation. Then we can mark them 'Backed' as we create the backup. cc @aminlatifi @mohammadranjbarz

[aminlatifi]

• When do we save? what will be the flow? : We can save every 8 hours. That would be ideal for most time zones.Flow could be: Backup service dumps transactions to be backed up in redis from where we add to DB every 8 hours and then delete. @mhmdksh what are your thoughts here?
• Do we have the missed items in data like price? How we could fetch it? : There are historical token prices which we can fetch from some chainlink historical price feed api or with an API like https://docs.moralis.io/web3-data-api/evm/how-to-get-historical-erc20-token-price;
• How do we mark them as save and what information we will add for tracking? : We could mark all mongoDB entries as 'Pending' by default. This is a one time operation. Then we can mark them 'Backed' as we create the backup. cc @aminlatifi @mohammadranjbarz

• I think it can be more frequent than that as the number of items are not a lot and gives the users more liveness sense. I think it's better to not delete them and only mark them with a flag like (saved in mongo) for further investigation.
• Regarding the price, you are right @jainkrati we need historical price service as our backend only is capable of fetching price of the very moment it's querying.
• Plus, it's good idea to tag the these recovered donations in our DB as well. About pending flag, I think we should not be worried about, we can mimic the same way the createDonation mutation works. What we miss here and is important for verification, is the donation time! As I know we check donations are not made far long time before being saved! (am I right @mohammadranjbarz ?). If that's true, we need to add extra field to the backup service which we have not foreseen. @MohammadPCh Would you please push a hotfix to include query time be inserted in the saved documents in mongo?

[aminlatifi]

About the time, till @MohammadPCh adds it, we can fill them with the transaction time so far.

[MoeNick]

Another question:

as the data comes from frontend, we need to verify them again with nouns with network,how would it be so?

[aminlatifi]

Another question:

as the data comes from frontend, we need to verify them again with nouns with network,how would it be so?

It's already been done in the donation verification process in the backend. That's part of usual donation verification process.

[MoeNick]

Related https://github.com/Giveth/giveth-dapps-v2/issues/3640 Thansk Amin for creating this

[mohammadranjbarz]

First of all I would appreciate if @mhmdksh give use the number of failed donations by day. After that I think the best way is someonereview the donations of each day and put it somewhere ( in a group, channel, ..) and one of backend devs can execute the query with those data (but as @aminlatifi said with pending status, to our verification service verify that donation). Also I think as we don't have many missed donations we can manually confirm the valueUdd and doesn't need the historical price services at this moment ( good to have it for future, but now we can do it without it)

[aminlatifi]

Reference

@mohammadranjbarz I think the preferred solution from Krati's perspective is to automate this process, and I agree with her as well. As I mentioned, the users will have a better liveness experience.

[mhmdksh]

First of all I would appreciate if @mhmdksh give use the number of failed donations by day. After that I think the best way is someonereview the donations of each day and put it somewhere ( in a group, channel, ..) and one of backend devs can execute the query with those data (but as @aminlatifi said with pending status, to our verification service verify that donation). Also I think as we don't have many missed donations we can manually confirm the valueUdd and doesn't need the historical price services at this moment ( good to have it for future, but now we can do it without it)

Hey @mohammadranjbarz I don't think sharing the failed-donations is related on how we want to approach this. You can call the mongodb which I shared with you to have this information through a simple query to the URI.

I think you might already be working on a procedure to automate this instead

[MoeNick]

I can see we have an attached PR, is this supposed to be assigned to @CarlosQ96 or you want to take it @aminlatifi ?

[MoeNick]

@MohammadPCh do you have an idea how we can QA? FYI: @maryjaf @divine-comedian

[mohammadranjbarz]

It's hard to reproduce it, but I explained to Maryam yesterday to check the saved data on mongo backup service and see if they are imported correctly in our DB and also check the status of the donations, and @maryjaf tested it on Staging and told me that all failed donations have been imported correctly

[MoeNick]

Test Scenario: 1- A donation fails to save (triggered by FE) 2- the donation saves in MogoDB 3- After 5 min, it will save in impact-graph 4- It gets verified and it will show up in the project donation UI 5- the saved donation marked as saved to make sure teh job don't save it by duplicate.

The problem is reproducing the first point. Any frontend help would be appreciated

[MohammadPCh]

@MoeNick this is the test tx: https://gnosis.blockscout.com/tx/0xbf91dfc18bd15e90816cabeeb76e8636ec60fcfe3c2f466140b73dbee0722fb9

[MoeNick]

Great @maryjaf it's ready for you now!

[maryjaf]

Great @maryjaf it's ready for you now!

I tested this issue on stg before deploying on production and all scenarios were passed . on prod I have a problem on admin with my vpn connection

[MoeNick]

Cherik yesterday checked that it has been saved on MongoDB. Maybe we can check the UI only @maryjaf @MohammadPCh on which project did you simulate this error?

[maryjaf]

It's recorded correctly