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

Print more activity info #1123

Open
bajtos opened this issue Nov 20, 2023 · 4 comments
Open

Print more activity info #1123

bajtos opened this issue Nov 20, 2023 · 4 comments
Labels
enhancement New feature or request

Comments

@bajtos
Copy link
Member

bajtos commented Nov 20, 2023

At the moment, the activity log typically shows a bunch of fail and restart messages, which looks a bit strange after a while. But it's pretty much the only log Station produces now. If we remove it, then the activity log will become empty.

Also: People are getting confused why their Stations do more or less jobs than other people, adding more data sounds useful.

Let's add more activities, for example:

  • When SPARK schedules rewards for the previous round, we can log an activity, something along the lines of “0.0025 FIL was added to your scheduled rewards”
  • Whenever Station completes 100 jobs, it can log another activity - “You completed another 100 jobs. Well done!”
  • SPARK can measure retrieval bandwidth consumed and log an activity every X MB, e.g “You contributed 100MB of your network bandwidth to improve Filecoin retrievals. Thank you!”
  • periodic updates (which could eventually ben numbers in the header) like "x retrievals tested in the last 10 minutes"
@bajtos bajtos added the enhancement New feature or request label Nov 20, 2023
@patrickwoodhead
Copy link
Collaborator

patrickwoodhead commented Nov 20, 2023

I think if an operator gets an error, we should move it from the logs into a banner or modal, and prompt the operator to check their connection and/or hard refresh station

@juliangruber
Copy link
Member

For any error? Station wants to stay in the background at all times - if there's a way it can recover by simply retrying the operation, I don't think there should be any user interaction. So far we are not aware of errors that users can fix themselves, or are there some?

@bajtos
Copy link
Member Author

bajtos commented Nov 20, 2023

Station wants to stay in the background at all times - if there's a way it can recover by simply retrying the operation, I don't think there should be any user interaction.

+1

@patrickwoodhead
Copy link
Collaborator

For any error? Station wants to stay in the background at all times - if there's a way it can recover by simply retrying the operation, I don't think there should be any user interaction. So far we are not aware of errors that users can fix themselves, or are there some?

Yeah - agreed we should definitely retry in the background to see if we can get things going again. I'm thinking if there are any other edge cases which might require a hard refresh or a restart initiated by the user. If no such edge cases exists, then let's do it all automatically behind the scenes.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
Status: 🗃 backlog
Development

No branches or pull requests

3 participants