bringing back indexer-processor

[Primata]

Summary

• RFCs: Link to RFC, Link to RFC, or $\emptyset$.
• Categories: any of protocol-units, networks, scripts, util, cicd, or misc.

Readding modifications made by @l-monninger
#124

nix develop

just suzuka-full-node native build.setup.eth-local.celestia-local.test --keep-tui

Changelog

Testing

Outstanding issues

[l-monninger]

This can be deleted.

[l-monninger]

It would be nice to test the indexer-processor prior to proceeding. But, I think that's going to be difficult.

[l-monninger]

I think you should update this to the latest rather than the commit on my branch.

[Primata]

Notes on how things currently stand:

1. Despite changing the processor type, suzuka-indexer-processor runs default_processor every time. Have tried with a few different names. Is it possible that because indexer-processor is being pulled remotely, configuration is ignored?

Because Aptos informs us that aptos-indexer-processor SHOULD run a TSS and the Indexer API is essentially configed by what @l-monninger provided, I went down the rabbit hole of checking if the API is actually provided or not.
2. Tested a few different endpoints to check if suzuka-indexer-processor would be serving the graphql api, none worked:
http://localhost:30734/graphql
http://localhost:30731/graphql
localhost:30730/graphql
localhost:30734/graphql
localhost:30731/graphql
localhost:30730/graphql
http://0.0.0.0:30734/graphql
http://0.0.0.0:30731/graphql
http://0.0.0.0:30730/graphql
http://0.0.0.0:30734/graphql
http://0.0.0.0:30731/graphql
http://0.0.0.0:30730/graphql
http://localhost:30734
http://localhost:30731
localhost:30730
localhost:30734
localhost:30731
localhost:30730
http://0.0.0.0:30734
http://0.0.0.0:30731
http://0.0.0.0:30730
http://0.0.0.0:30734
http://0.0.0.0:30731
http://0.0.0.0:30730
https://cloud.hasura.io/public/graphiql?endpoint=https://api.devnet.aptoslabs.com/v1/graphql custom endpoints are also not returning anything

3. curl http://localhost:30734 (and curl localhost:30734?auth_token=notrealnotneeded too) gives us curl: (1) Received HTTP/0.9 when not allowed -> curl: (56) Recv failure: Connection reset by peer.

4. Going back to implementing the two next requirements: relational db and the API. Checking if the relational db is being served. I can see that we are not providing a Redis db. That should be the relational db, so I ended up here: https://github.com/aptos-labs/aptos-core/tree/f2a427f3f4c1b883c2a9588a1c39db515637de0d/ecosystem/indexer-grpc. Which matches, notes provided in notion. A bit unsure on how to proceed here, provided some notes.

5. Started configing services pointed out in our Notion file.

[l-monninger]

@0xPrimata

Tested a few different endpoints to check if suzuka-indexer-processor would be serving the graphql api, none worked:

The endpoints you are testing serve the gRPC full node data stream. The role of the indexer processor is to take that data and put it in a postgres database. You can then use Hasura with the schemes from the upstream to serve that database behind a GraphQL endpoint.

On the otherhand, what's being served on :30734 is the gRPC full node data stream service. You can see how to consume it by consulting the tests: https://github.com/movementlabsxyz/movement/blob/primata/implement-indexer-processor/networks/suzuka/suzuka-client/src/tests/indexer_stream.rs

curl http://localhost:30734 (and curl localhost:30734?auth_token=notrealnotneeded too) gives us curl: (1) Received HTTP/0.9 when not allowed -> curl: (56) Recv failure: Connection reset by peer.

You cannot curl request a gRPC endpoint. For exploring, using grpcurl or grpcui (both included in the nix flake).