Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Schedule rewards show zero #476

Open
bajtos opened this issue May 22, 2024 · 3 comments
Open

Schedule rewards show zero #476

bajtos opened this issue May 22, 2024 · 3 comments
Labels
bug Something isn't working

Comments

@bajtos
Copy link
Member

bajtos commented May 22, 2024

I upgraded my Station Desktop instance to v1.7.0 and it started to show 0 scheduled rewards. Downgrading to 1.6.1 did not fix the problem. After downgrading to 1.6.0 I can see my scheduled rewards again.

How to reproduce the problem:

FIL_WALLET_ADDRESS=0xE5975d52558Dc1B4c5249dB5434b585a0Ed69E79 npm start 2>/dev/null

^^^ That does not work, because npm start hard-coded FIL_WALLET_ADDRESS to 0x0...dEaD.

Here is the corrected command:

FIL_WALLET_ADDRESS=0xE5975d52558Dc1B4c5249dB5434b585a0Ed69E79 STATE_ROOT=.state CACHE_ROOT=.cache node ./bin/station.js 2>/dev/null
@bajtos bajtos added the bug Something isn't working label May 22, 2024
@bajtos
Copy link
Member Author

bajtos commented May 22, 2024

I think the problem is caused by the fact that we wait for 10 minutes before we run getContractsWithRetry for the first time after startup.

Do you remember why we implemented it this way? I suspect that we wanted to avoid DDoSing w3name in case Station Core instances frequently restart. Or more precisely, if we frequently restart the main zinnia loop. Now that we moved contract updater outside of the main zinnia loop, I think we can change this behaviour.

A few more alternatives that come to my mind:

  • We can hard-code a seed list of contracts into Station Core source code.
  • Station Core can persist the list of contract addresses in a state file, so that we have a relative up-to-date list after restart.

@juliangruber
Copy link
Member

I think the problem is caused by the fact that we wait for 10 minutes before we run getContractsWithRetry for the first time after startup.

This was so that when Voyager crashes, we don't fetch new contracts. Now that they are decoupled, and we would only fetch contracts when Core restarts, let's move the wait afterwards again. Will PR

@juliangruber
Copy link
Member

#477

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants