nspcc-dev / nspcc-dev/neofs-node

Add a possibility to add error injections to the code from system tests

Open
#2,948 11 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

feature I4 S1 U4
Dominant language
Go
Stars
38
Forks
51
Avg merge
1d 20h
Merged PRs (30d)
38

Description

For tests like these - https://github.com/nspcc-dev/neofs-testcases/issues/794 we need a way to put the system under the test to certain conditions that can't be easily and reliably reproduced under regular circumstances, but we can encounter them running the production code.

The most convenient thing from the test perspective would be the possibility to add error injections to some code places. E.g. if we want to get an unfinished object and want to validate how it is cleaned, it would be nice to inject an error during the object creation operation and got such an unfinished object.

Same feature could be also applied to verify more unusual scenarios and different states of the system. To ensure the robust recovery from other possible faulty situations.

I would expect it to be implemented either via env variables/config files before service starts, or, more conveniently via some internal cli commands - like ./neofs-cli inject-error ERROR_LOCATION ERROR_TYPE, where ERROR_LOCATION is a specific place in the code and ERROR_TYPE is either a panic, or a sleep with different number of seconds, or a bool value that somehow is used in the code. E.g.
./neofs-cli inject-error OBJECT_CREATION_POST_PARTS_CREATE RETURN_FALSE

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 reviewing the linked neofs-testcases issue and the existing neofs-cli command entry points. Define the supported injection locations and behaviors before choosing configuration or CLI control; done means system tests can reliably trigger the requested failure states and validate recovery.

Written by the indexing model from the issue text.

Assessment

Tech stack
go
Domain
distributed-systems, testing
Issue type
Feature
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.