truecloudlab / frostfs-sdk-go Goto Github PK

We have a bit of a hacks in handleError after #11: split info error should be passed as a status code from FrostFS but returned as a generic error anyway.

Consider making changes in API and storage node to avoid having split info error in transport error layer.
Or consider making handleError function parsing only error type without working with any statuses, so it will be at least consistent.

Pool component might renew token before it is expired. This way we can avoid some retry requests and possible test failures.

Currently we panic in many situations:

1. We forget to set an obligatory parameter.
2. Some attribute has unexpected value ((netmap.NodeInfo).Price() -- we expect to get it with FromV2 where an error is processed).
3. Something else?

While I think (1) is ok, others are not IMO. Also in (1) we could provide obligatory parameters explicitly: hard-to-misuse API is the best. Another option is to have New with obligatory parameters and Set methods on it (private structure with public interface).

@alexvanin @KirillovDenis @carpawell @realloc @acid-ant

handleError func shouldn't consider context canceled as error to protect the view of storage node healthiness from user actions.

Related TrueCloudLab/frostfs-s3-gw#35

It would be nice to know if some node in pool goes down.
Maybe we can log such situations.

/cc @alexvanin

• Add metrics for error counters
• Consider decreasing error counter on some occasions
  • Decrease counter for some % on every successful healthcheck round