Envio Requests

[stas]

A couple of todos to review/discuss

• DRY config.yaml -- our config file is ~500 sloc, a good chunk of it is repetitive or could use templates. A simple QOL improvement would be the ability to split the file into includes with overwrites
• Simplify testing -- we need a little guidance but also probably an upstream best practices guide on how to write and maintain event handlers, particularly
  • Switch to realistic fixtures (ideally via a VCR-like setup like https://github.com/Netflix/pollyjs or https://github.com/ijpiantanida/talkback)
  • Decouple handlers into isolated functions we can unit test, currently we're forced to write integration tests using DB mocking
  • DRY handlers to allow reuse of the logic where necessary

[stas]

fyi @moose-code if you guys are aware of these or have seen others approaching the dev the same way

cc @WooSungD

[moose-code]

Thanks Stas!! Will look to discuss this with @DZakh to five best guidance 👍

[DZakh]

Hi 🫡

Dry config

We're going to turn config.yaml to envio.config.ts, which will be much easier to configure as code. However, this is likely to occur within approximately 2-3 months. Currently, as a workaround, I can suggest abusing the Env Vars embeding feature, since it should allow embeding any block of config: https://docs.envio.dev/docs/HyperIndex/configuration-file#environment-variables

Also, I know Sablier has a separate build step in CI, where they build config in their own way, and then create a commit in a branch which automatically deploys to the Hosted Service.

Testing

Regarding testing most people usually write simple handler tests with our test utilities, where they manually run a handler with some event data and verify db state afterwards. This is good, but it's more on the unit tests side.

As for integration tests, there's a way for us to improve, but here's a message from the Contango builder, where he shares his workaround:

Code Structure

It's possible to have isolated and reusable functions, but usually, code is quite tightly coupled to the context object, and it's admittedly much easier to pass it to every function. I'd recommend writing unit tests per handler using the HyperIndex test utils, instead of testing pure internal implementation, in case you untangle it from context. In my opinion, the tests will be more maintainable and reliable.

[stas]

Dry config

Got it. We'll have to wait then. Our config file should be a good example of the pain points to tackle.

Testing

I'm looking at this
https://docs.envio.dev/docs/HyperIndex/testing

And I don't see any particular tooling/utils. Could you pls point me to some examples.

I think it's important to mention that the lack of realistic fixtures in tests is what I'm trying to "fix".
I'm looking for tools that would allow us to fetch relevant transactions and cache/generate fixtures based on the tx events.

Consider this eg.

import { EventFixtures } from "../generated/fixtures/ContractName_EventName.json"; 
const eventMock = ContractName.EventName.createMockEvent(EventFixtures[0]);

If there's an example a test suite you'd recommend reviewing I'd appreciate any input.

If the context is a hard dependency, the perfect alternative would be to run some handlers against a a specific block number and really just assert that the indexed data is the expected data.

---

Here's an example test that showcases what we'd like to avoid:
https://github.com/velodrome-finance/indexer/blob/main/test/PriceOracle.test.ts

[DZakh]

These are good feature requests I'm keen on implementing. However, I'll have a two-week vacation, which will slow down the progress a little bit.

Contango team, I mentioned above, also requested something similar. As a workaround, they currently fetch the events for a specific block using viem client, manually create Envio mocks from them, and process them in a batch.

For this I just created a PR for them, which is also the first step in implementing the feature you asked enviodev/hyperindex#611

[moose-code]

Just dropping in that enviodev/hyperindex#611 is merged and we've also release v2.24.0 https://github.com/enviodev/hyperindex/releases/tag/v2.24.0