Implement RequestedShutdown Event for Task Persistence and Reputation System

[cryptobench]

Feature Request: Implement RequestedShutdown Event for Task Persistence and Reputation System

Feature Description

This feature request addresses the need for improved data persistence in volatile environments within the Golem Network. It focuses on the implementation of a requestedShutdown event for providers and the integration of a reputation system.

Provider Needs

• Providers require a graceful task shutdown mechanism to ensure that their work is not lost and they are fairly compensated.
• Suggestion: Implement a requestedShutdown event that requestors can act upon.

Requestor Needs

• The requestedShutdown event should enable the SDK to allow user-defined actions, such as:
  • Storing results in memory and provisioning to a new provider.
  • Allowing the requestor to define if the task is non-critical.

Reputation System Integration

• Reward: Good behavior, like adhering to shutdown protocols, should improve a provider's reputation.
• Punish: Abrupt disconnections without warning should negatively affect reputation.

Expected Outcome

The implementation is expected to enhance task execution reliability and create a robust ecosystem for Golem Network users.

Additional Context

This feature is crucial for maintaining data persistence in unstable environments, ensuring the Golem Network's sustainability and user satisfaction.

[Atlas16A]

The event should also act as a notice to any other requestor on the network to not try to negotiate a task with the provider till a new offering message is broadcast.

[cryptobench]

Great point @Atlas16A !

[intel80]

This would be incredibly helpful as described, or even a simple "golemsp stop-when-current-job-completes"

[Atlas16A]

That's too many words for a single command but yea

[RoyKas]

I think both options would make sense:

• option to complete current activity and not accept any new agreements or activities.
• option to message the requestor(s) that the provider node needs to shutdown, allowing requestors to take appropriate action to prevent loosing work.
  Both option to ensure all payment interactions can be completed, and also that provider reputation is not affected (except uptime).

[AlexFihman]

How about graceful-stop

[Suvaktaa]

For a scenario where provider is rebooting machine for installation of security patch or kernel upgrades which will not take more than 2 minutes. requestor need not to necessarily look for another provider rather can wait for the node to come up. Obviously this holds true for nodes where multiple requestor are running tasks continuously for days.
For other scenarios lke maintenance from Service Provider or Utility provider would take more than an hour than requestors must look for new providers.