Recording library runtime for bug analysis by developers
Maintainers usually reply within 1 day
@HagarMeir is already working on this.
Since Jan 20, 2022.
Assessment
This issue has not been assessed yet.
Description
Background: While the consensus library is well tested, rare bugs must still exist and manifest in user environments.
Although running with logging at debug level greatly helps troubleshooting and helps the developers of the library understand what went wrong, it might still not be enough to analyze an occurrence of some bugs.
The reason is that the complexity of the library makes it difficult to keep track of the state changes of its internal components from just reading the logs.
A straightforward way for the library developer to reproduce a bug of a user of the library is to have the user give the developer access to its environment or even ship a snapshot of the environment itself to the developer.
Clearly, both options are often not viable in case of a production environment, as it is imperative that the customer data that is part of the environment remains confidential.
Goal: The goal of this issue is to describe a mechanism that on the one hand allows a user of the library to easily convey to the developer how to reproduce a bug it is experiencing with the library, but on the other hand, does not leak any customer data to the developer.
Proposed idea: I propose to augment the library with the ability to record its runtime in a manner that later allows to run an instance of the library from the recording, so that bugs are reproduced. More specifically, the library shall record the initial state, the messages received, and even (indications of) messages sent into a file, so later on that file could be used to instantiate the library in a development environment from the initial state, and replay the messages and reproduce the bug.
Proposed implementation technique: The Consensus object contains all interactions of the library's internal components with the outside world. All that is required is to intercept and record messages received, messages sent, and record the initial state. Then, the recording can be read iteratively and the events described in it (message reception, synchronization, etc.) can be returned to the library instead of using the real interface implementation of the dependency.
By making interaction between the recording implementation and the rest of the library reside in the consensus object (instead of the internal BFT implementation) we minimize code change impact and bugs.
Confidentiality and data sanitation: Every object will be sanitized to remove sensitive fields prior to recording. The format of the recording shall be in human friendly format (JSON), so that a user may inspect the recording and see that it indeed doesn't contain sensitive data before passing it to a library developer.
A simple demonstration of how the recording and playback capability can be applied is available here. The only dependency that is implemented there so far is the synchronization dependency.
As seen from the implementation, when running in recording mode, the result from the sync is written to the file. Then, when the library is run in a mode that reads the aforementioned recording transcript, it retrieves it from the file and returns the result instead of calling the real synchronization dependency.
- Dominant language
- Go
- Stars
- 110
- Forks
- 40
- Avg merge
- 1d 6h
- Merged PRs (30d)
- 14
Getting set up
This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.
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.
More from hyperledger/SmartBFT
-
Difficulty 4/5 3-5 days Newbie friendliness 35/100
hyperledger/SmartBFT#714 ·
Maintainers usually reply within 1 day
-
Set up a pr projectOpen
Difficulty 4/5 3-5 days Newbie friendliness 25/100
hyperledger/SmartBFT#666 · 4 comments ·
Maintainers usually reply within 1 day
-
Difficulty 4/5 3-5 days Newbie friendliness 35/100
hyperledger/SmartBFT#628 · 12 comments ·
Maintainers usually reply within 1 day
-
enhancement
Difficulty 5/5 Over a week Newbie friendliness 15/100
hyperledger/SmartBFT#439 ·
Maintainers usually reply within 1 day
-
enhancement
Difficulty 5/5 Over a week Newbie friendliness 35/100
hyperledger/SmartBFT#420 ·
Maintainers usually reply within 1 day
All issues in hyperledger/SmartBFT
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
blinklabs-io/dingo#5368 ·
Maintainers usually reply within 1 day
-
difficulty: easy enhancement frontend good first issue help wanted priority: P2
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
rafaelsilvabr/pdfHandler#18 ·
-
Difficulty 2/5 1-2 days Newbie friendliness 78/100
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 83/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 85/100
Maintainers usually reply within 1 day