Giters

golemfactory / golem-electron

Graphical user interface for Golem Project

Home Page:https://golem.network

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Actual time taken and timeout shown in transaction history

Dekker3D opened this issue · comments

commented

Rationale

I would like to see the actual time your pc took to complete a task, as well as the requestor's timeout, on each transaction in the transaction history. It's already possible to find the actual time taken in golem.log, but it takes time to match it up with tasks. I don't know if timeout data is available to providers.

This feature would allow providers to get a better sense of the GNT/h paid by the market, as well as letting them see how much time their computer has actually spent working. In this context, it might also be nice to show the total time spent working in the past 24 hours somewhere below the transaction list.

(Adding a note here: your issue-submission process is very technically-oriented and might be intimidating for non-technical people submitting an issue)

Description

Functional specification

  • What are the components of the required feature?
    Time taken for a task/subtask is already available in golem.log. Task timeout might have to be transmitted to providers along with the actual task; I don't know if this is already done (probably) nor desirable.
  • What are the failure modes and how are they supposed to be handled?
    Simply don't show any piece of this information that's not available at time time.

User Interface

Are user-facing changes required for this functionality?

  • Description of user-facing behavior
    Display timeout and total time taken for each task/subtask on the transaction matching that task/subtask in the transaction list.
    Possibly add a total of task computing time at the bottom of the transaction list, maybe including a total of the timeouts and a percentage of task time / timeouts.
  • Changes to existing user interaction?
    None
  • Screenshots?
    Too lazy, suggestion seems obvious enough.

Technical specification

If required/possible, provide the detailed description of the required changes in the application

  • Required changes to app's internal structures? Model updates? Model additions?
  • Which application modules will be updated?
  • Modification of e.g. message handlers?
  • Replacement of modules?
  • Refactoring?

Dependencies

Enumerate other issues the completion of which is critical for this feature to be finished - or which block this feature from progressing with implementation

Sub-components

Define and add links to sub-components

  • ?
  • ?

Blockers

For any issues that block this issue, add links

  • ?
  • ?

Additional tests

Enumerate any additional unit and/or integration tests that need to be added for this feature to be covered

  • additional unit tests?
  • additional integration tests?

QA

Description of the QA process for the feature

Test scenarios:

Base test process

specify one of: ( if unsure, consult @ZmijaWA or @ederenn )
** QA limited to the single feature (in case of very trivial changes)
** Smoke Test (the limited set of tests designed to ensure that most critical functionality doesn't experience regressions)
** Full Test (full set of tests for the whole application - in case of more extensive application updates, refactoring etc)

New feature tests

Add test scenarios for the new feature

Positive Scenario 1

  • Step 1
  • Step 2
  • ...
  • Expected results

Positive Scenario 2

  • ...

Negative Scenario 1

  • Step 1
  • Step 2
  • ...
  • Some expected problem
  • Expected problem handling

Possible regressions

  • is there any functionality that is likely to experience regressions?
  • are there any existing application components that should be tested more thoroughly?

Progress

Development

  • Feature implemented
  • Feature unit/integration tests implemented

Dev QA

  • Basic tests by the developer pass
  • Unit tests pass
  • Golem integration tests pass
  • Concent integration tests pass
  • Concent acceptance tests pass

Please choose the priority label for QA. It is set to the lowest by default. To setup higher priority please change the label
P0 label is set for Severity-Critical/Effort-easy
P1 label is set for Severity-Critical/Effort-hard
P2 label is set for Severity-Low/ Effort-easy
P3 label is set for Severity-Low/Effort-hard

QA team

  • Base scenario passes
  • Additional test 1 passes...
  • ...

Issues encountered during QA

When adding an issue here, please update testing scenarios and QA progress above

  • link to issue...
  • ...
commented

Hey @Dekker3D, thank you for your request. You're absolutely right about issue template, maybe I should add an info for non-tech people. So they can remove technical parts if not needed. The sections are not mandatory but good to have :)

About the request; It's a nice idea, I will forward this to the team and let you know what we can do about it.