nspcc-dev / nspcc-dev/neofs-node
Should a node validate objects it won't store?
Nobody has claimed this yet.
- Dominant language
- Go
- Stars
- 38
- Forks
- 51
- Avg merge
- 1d 20h
- Merged PRs (30d)
- 38
Description
Now any SN tries to validate and check eACL rules on every request (even if it does not store/will not store an object). Should it do it? Sometimes it cannot even validate smth it does not have access to: https://github.com/nspcc-dev/neofs-node/pull/2792.
Possible Solution
If a node is just a middleware in the chain b/w a client and a server, just do what this node should do (split objects, forward requests, etc) and do not try to act like a target node.
Context
Object content validation is here, while placement creation logic (that can say where to put (mb this node is not part of a container at all)) is in the iteratePlacement function.
Your Environment
5c10c503ce7a9be8f25d53972ace416541c80f75
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Read pkg/services/object/put/distributed.go, focusing on the content validation at the referenced lines and the iteratePlacement function. Trace how a node determines whether it stores an object or only forwards and splits requests. Done means intermediary nodes avoid target-only validation while target nodes retain the required validation and placement behavior.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- go
- Domain
- distributed-systems
- Issue type
- Refactor
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 25/100