feat: add total reward for epoch for each user

[neocybereth]

No description provided.

[Fraccaman]

this looks nice! thanks for the PR. You are missing a migration to add the epoch field to the rewards table. You can check it here https://diesel.rs/guides/getting-started#setup-diesel-for-your-project

[Fraccaman]

Ehi! you are still missing the migration, you need to add a folder here https://github.com/anoma/namada-indexer/tree/main/orm/migrations (you can follow the guide https://diesel.rs/guides/getting-started#setup-diesel-for-your-project to auto generate the folder for you). The migration is needed to modify the rewards table schema and add the epoch field

[neocybereth]

Oof! Sorry about that, coming right up!

I think this should do it:

[Fraccaman]

you might also want to update the webserver? I mean, update/create a new endpoint

[joel-u410]

While testing this, I ran into a problem where the pos_rewards table didn't have an updated UNIQUE constraint which incorporates the epoch column.

I pushed a commit that fixes that: 725f9c9

Feel free to add it to your branch also.

[neocybereth]

Updated that here:

1244bab

[joel-u410]

Note - this is assigning to raw_amount the decimal value of nam (i.e. 12.34567 not 1234567 unam) -- which is different than the previous behavior of the rewards crawler. I noticed it in my testing because the raw_amount column has type numeric(78,0) which only stores integer values, and the reward amounts were being truncated.

[neocybereth]

0957a4a

Fixed here with:

            raw_amount: BigDecimal::from_str(&reward.amount.to_string()).unwrap(),

[neocybereth]

you might also want to update the webserver? I mean, update/create a new endpoint

fae5e1f all the webserver endpoints are in.

basically it takes a delegator address, validator address and epoch and gives back the rewards. The validator address is used to find a validator id to look up the reward. Again, my rust sucks so let me know if there's anything off.

[brentstone]

Does this PR depend on anoma/namada#4196?

[neocybereth]

Does this PR depend on anoma/namada#4196?

I'm 99% sure yes, but I'm also a noob to this codebase so @joel-u410 or @Fraccaman could confirm for sure.

[joel-u410]

Does this PR depend on anoma/namada#4196?

Hi @brentstone @neocybereth -- no, currently it does not, but after anoma/namada#4196 is merged I would like this one to be updated to take advantage of it.

Right now, in this branch, it only queries "current epoch" rewards, and just assigns the current epoch number to their records -- after anoma/namada#4196 is merged I would want to change this to use the epoch argument to be more precise about which epoch is being requested when rewards are indexed.

(I have a Draft commit where I've started working on that, including adding support for --backfill-from to rewards -- see #193 for context on the --backfill-from feature)

[joel-u410]

Just realized something here ... delete_claimed_rewards is now going to delete things it shouldn't.

Instead of deleting, it should probably insert rows with raw_amount = 0 to indicate they've been claimed.

Which will need to be distinguished somehow from the pos_rewards entry in the same epoch.

We'll probably need to add a column -- either block_height perhaps (to indicate the block where claim occurred) or maybe just a boolean claimed column would work.

[joel-u410]

@neocybereth I'm looking at the existing /pos/reward/:address endpoint and it also needs to be updated to return only the latest reward -- right now it's returning every reward from every epoch in a giant list 😁

[neocybereth]

@joel-u410 epic, tahnk you for the heads up! What's your go to testing methodology here? I'm just shooting in the dark and YOLO-ing atm and surely there's gotta be a better way :D

[neocybereth]

something is messed up in here :S

Yeaaaaa it was my rebase. I'm going to have to go through and piece the PR back together.

[sug0]

do you still have the old tip of your branch in your git reflog? it would be easier to take that as a starting point

[neocybereth]

do you still have the old tip of your branch in your git reflog? it would be easier to take that as a starting point

omg you're a lifesaver!

[neocybereth]

@Fraccaman okay, we're back to clean. Everythings up-to-date against main.

Anything else I need to do before getting approval? Shall I attempt another (hopefully successful :D) rebase against 1.0.0-maint from here?

[Fraccaman]

@neocybereth can you take a look at. theci failures?

[neocybereth]

@Fraccaman sorry I've been busy with other work! I've fixed up all the CI issues.

[neocybereth]

Fixed those up @sug0

[neocybereth]

@Fraccaman @sug0 just checking back in to see if these are good to merge?