[Feature] Test Handling Incoming Events #22

New Issue

2022-04-27T14:06:12Z

abdulrabbani00 commented

2022-04-27 14:06:12 +00:00

(Migrated from github.com)

Overview
- Request
Potential Solution
- Alternative Solutions
Additional Context

Table of contents generated with markdown-toc

Overview

Requester: @abdulrabbani00
Epic Link: https://github.com/vulcanize/ipld-ethcl-indexer/issues/19

Request

We need to ensure that we are properly handling all incoming events. This test needs to be robust since we are handling new incoming requests.
We will want to use integration testing, unit testing, and probably a combination of both.

Potential Solution

Integration
Ensure we can adequately process a single head event.
Unit Test
- Set up a process to stream head and reorgs events to the BeaconClient.
  - We will need many different scenarios to be streamed. So we have to create processes to stream the events in a specific order to mimic the following cases.
    - Happy path
    - Conflicts
    - Edge Cases
    - Bad Data
    - Good Data
    - We need to create a process to mimic the response from the beacon chain for head and reorg_chain events. This process should allow us to create an arbitrary number of events and should be easily changed depending on API changes by the lighthouse client. The events should be created based on a template in an automated fashion.

Alternative Solutions

None yet

Additional Context

- [Overview](#overview) - [Request](#request) - [Potential Solution](#potential-solution) - [Alternative Solutions](#alternative-solutions) - [Additional Context](#additional-context) <small><i><a href='http://ecotrust-canada.github.io/markdown-toc/'>Table of contents generated with markdown-toc</a></i></small> # Overview - **Requester**: @abdulrabbani00 - **Epic Link**: https://github.com/vulcanize/ipld-ethcl-indexer/issues/19 ## Request  * We need to ensure that we are properly handling all incoming events. This test needs to be robust since we are handling new incoming requests. * We will want to use integration testing, unit testing, and probably a combination of both. # Potential Solution  - Integration Ensure we can adequately process a single `head` event. - Unit Test - Set up a process to stream `head` and `reorgs` events to the `BeaconClient`. - We will need many different scenarios to be streamed. So we have to create processes to stream the events in a specific order to mimic the following cases. - Happy path - Conflicts - Edge Cases - Bad Data - Good Data - We need to create a process to mimic the response from the beacon chain for `head` and `reorg_chain` events. This process should allow us to create an arbitrary number of events and should be easily changed depending on API changes by the lighthouse client. The events should be created based on a template in an automated fashion. ## Alternative Solutions  None yet # Additional Context

abdulrabbani00 commented

2022-05-06 15:10:27 +00:00

(Migrated from github.com)

Testing Overview

@ashwinphatak and @i-norden (@AFDudley, @ABastionOfSanity , @erikdies, feel free to chime in as well): I wanted to get your opinion regarding unit testing server streamed events (SSE) sent from the beacon node. A few notes:

The beacon node sends server streamed events to the ethcl application. We subscribe to a given endpoint and ingest these messages.
When we receive a message, we turn it into a struct and then we process it.

Potential Solution

The question I have is about creating a testing "framework." Should I:

Create a "server" within the test environment that will stream the raw events to mimic the behavior of the beacon node?
- This allows us to test that we can properly handle SSE events.
- This helps us test that the unmarshaling is being done correctly.
- This helps us test the processing behavior is going as expected.
On the other hand, if I want to simplify it, I can send []byte to the channel that receives the raw SSE messages.
- This helps us test that the unmarshaling is being done correctly.
- This helps us test the processing behavior is going as expected.
- This does not allow us to test that we can properly handle SSE events.
- Quicker and easier than setting up a server. But we miss testing the external libraries’ capabilities to handle streamed messages.

Current Thought

Personally, I have not done much work around streaming data using the HTTP library in Go so I am not sure how much more work it will be.

I do like the idea of mimicking the beacon node instead of bypassing the "handling of the SSE messages."
The actual logic of "sending/playing messages" should be the same regardless of the approach. The only question is, do we send the messages to a channel, or through a server?

Let me know what you guys think. For the time being, I will send messages directly to the channel. I personally want to use the server but I won't make the investment into the integration if we, as a team, don't see the value.

Thank you

# Testing Overview @ashwinphatak and @i-norden (@AFDudley, @ABastionOfSanity , @erikdies, feel free to chime in as well): I wanted to get your opinion regarding unit testing server streamed events (SSE) sent from the beacon node. A few notes: * The beacon node sends server streamed events to the ethcl application. We subscribe to a given endpoint and ingest these messages. * When we receive a message, we turn it into a struct and then we process it. # Potential Solution The question I have is about creating a testing "framework." Should I: * Create a "server" within the test environment that will stream the raw events to mimic the behavior of the beacon node? * This allows us to test that we can properly handle SSE events. * This helps us test that the unmarshaling is being done correctly. * This helps us test the processing behavior is going as expected. * On the other hand, if I want to simplify it, I can send `[]byte` to the channel that receives the raw SSE messages. * This helps us test that the unmarshaling is being done correctly. * This helps us test the processing behavior is going as expected. * This **does not** allow us to test that we can properly handle SSE events. * Quicker and easier than setting up a server. But we miss testing the external libraries’ capabilities to handle streamed messages. # Current Thought Personally, I have not done much work around streaming data using the HTTP library in Go so I am not sure how much more work it will be. * I do like the idea of mimicking the beacon node instead of bypassing the "handling of the SSE messages." * The actual logic of "sending/playing messages" should be the same regardless of the approach. The only question is, do we send the messages to a channel, or through a server? Let me know what you guys think. For the time being, I will send messages directly to the channel. I personally want to use the server but I won't make the investment into the integration if we, as a team, don't see the value. Thank you

abdulrabbani00 commented

2022-05-06 19:12:40 +00:00

(Migrated from github.com)

After further review, I am going to use the server approach instead of using the channels. I think it might end up being more work to bypass the server, while also lowering test quality.

abdulrabbani00 commented

2022-05-06 21:33:29 +00:00

(Migrated from github.com)

I am strongly considering a mixed solution:

I will send messages to the channel instead of sending SSE events to the BeaconClient.
Once messages come into the channel, they will be processed.
The BeaconClient will query a dummy server mimicking the beacon node to get the BeaconState and SignedBeaconBlock.

In this solution:

We mimic the behavior of the beacon node when we query it, adding this behavior is relatively easy.
We don't stream messages via SSE, instead we send the raw messages directly to a channel.
- The application gets these messages and put them into a channel for us.
- We are bypassing this feature because the implementation has proved to be a bit tricky.
- The value we gain from not bypassing this step is that we ensure that the SSE library we are using is working properly. Which might not be worth all the effort.

I am open to discussing this solution and hoping to run it by someone to get an external opinion on Monday.

I am strongly considering a mixed solution: 1. I will send messages to the channel instead of sending SSE events to the BeaconClient. 2. Once messages come into the channel, they will be processed. 3. The BeaconClient will query a dummy server mimicking the beacon node to get the `BeaconState` and `SignedBeaconBlock`. In this solution: * We mimic the behavior of the beacon node when we query it, adding this behavior is relatively easy. * We don't stream messages via SSE, instead we send the raw messages directly to a channel. * The application gets these messages and put them into a channel for us. * We are bypassing this feature because the implementation has proved to be a bit tricky. * The value we gain from not bypassing this step is that we ensure that the SSE library we are using is working properly. Which might not be worth all the effort. I am open to discussing this solution and hoping to run it by someone to get an external opinion on Monday.

abdulrabbani00 commented

2022-05-09 18:39:26 +00:00

(Migrated from github.com)

Find internal document here: https://www.notion.so/Testing-Head-Tracking-792c0bbaea7c4d15924580066effc708

Sign in to join this conversation.

No Milestone

No project

No Assignees

1 Participants

Notifications

Due Date

The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: cerc-io/ipld-eth-beacon-indexer#22