nspcc-dev / nspcc-dev/neofs-node

Node's get service refactor

Open
#2,579 2 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

enhancement I4 neofs-storage S2 U4
Dominant language
Go
Stars
38
Forks
51
Avg merge
1d 20h
Merged PRs (30d)
38

Description

Is your feature request related to a problem? Please describe.

I'm always frustrated when I need to read and change the get object service in the Storage Node. IMO it has not been refactored for a too long time: some features were added and some hotfixes have been applied so now it always scares me when I need to add/change something in this service.

Describe the solution you'd like

Try to see which parts are in use, and which are outdated, to remove totally unused code. Rework forwarding mechanism (also think it may lead to some new thoughts about our access logic). Make it more clear what requests can spawn (and should they?) another requests (e.g. it is/was OK to make GETRANGE if the original request is GETRANGEHAS, the same was applied to GET if GETRANGE was declined). There are also some parasit small private structs and a lot of callback logic in the service (e.g. forwarding is a huge kludge IMO).

Describe alternatives you've considered

Keep it as is until some bug fix leads to another bug, or until some dev is not available to understand the service from scratch.

Additional context

#2557 could look better.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by reading the Storage Node get object service, especially pkg/services/object/get/v2/util.go and its forwarding logic. Review which request types can spawn other requests, identify unused code and private structs, and compare the alternative in issue #2557. Done means the service has a clearer forwarding/access flow with obsolete code and callback complexity removed.

Written by the indexing model from the issue text.

Assessment

Tech stack
go
Domain
distributed-systems
Issue type
Refactor
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.