unable to resolve type URL /osmosis.gamm.v1beta1.MsgCreatePool

[danbryan]

I got this error

6:25PM ERR Failed to process block 2695938 after 5 attempts. Will add to failed blocks table
6:25PM ERR Error getting transactions by block height. Will reattempt error="rpc error: code = InvalidArgument desc = unable to resolve type URL /osmosis.gamm.v1beta1.MsgCreatePool: tx parse error: invalid request"

with this compose file.

version: "3.9"
x-logging: &logging
  logging:
    driver: json-file
    options:
      max-size: 100m
      max-file: "3"
      tag: '{{.ImageName}}|{{.Name}}|{{.ImageFullID}}|{{.FullID}}'

services:
  postgres:
    restart: "unless-stopped"
    image: postgres:15-alpine
    stop_grace_period: 1m
    volumes:
      - /etc/localtime:/etc/localtime:ro
      # - postgres:/var/lib/postgresql/data
    environment:
      - POSTGRES_USER=taxuser
      - POSTGRES_PASSWORD=password
    ports:
      - 5432:5432/tcp
    healthcheck:
      test: ["CMD", "nc", "-z", "-v", "localhost", "5432"]
      interval: 5s
      timeout: 5s
      retries: 5
    networks:
      default:
        aliases:
          - defiant
    <<: *logging
  indexer:
    restart: "no"
    image: ghcr.io/defiantlabs/cosmos-tax-cli-private:sha-766a0e6
    user: defiant
    stop_grace_period: 1m
    volumes:
      # - indexer:/var/lib/cosmos-tax-cli-private-index
      - /etc/localtime:/etc/localtime:ro
    depends_on:
      postgres:
        condition: service_healthy
    links:
      - postgres
    networks:
      default:
        aliases:
          - defiant
    <<: *logging
    command:
    - /bin/sh
    - -c
    - |
      cosmos-tax-cli-private index \
      --log.pretty = true \
      --log.level = debug \
      --base.startBlock 2695938 \
      --base.endBlock 2695938 \
      --base.index true \
      --base.throttling 1.9 \
      --base.api https://api.osmosis.strange.love:443 \
      --lens.rpc http://104.196.107.57:26657 \
      --lens.accountPrefix osmo \
      --lens.keyringBackend test \
      --lens.chainID osmosis-1 \
      --lens.chainName osmosis \
      --db.host postgres \
      --db.database postgres \
      --db.user taxuser \
      --db.password password

[davidkonigsberg]

Looks like we are missing a few Gamm msg types. Will add them in based on this doc:
https://docs.osmosis.zone/osmosis-core/modules/gamm#messages

[davidkonigsberg]

Ok, we were only missing 1 msg from the doc above, and it wasn't "/osmosis.gamm.v1beta1.MsgCreatePool"

I wil add "/osmosis.gamm.v1beta1.MsgCreatePool" as well, and I believe it is an older version of the "MsgCreateBalancerPool" msg that now exists.

[davidkonigsberg]

Here is the block we are having issues with: https://www.mintscan.io/osmosis/blocks/id/2697048

[davidkonigsberg]

So it looks like the transaction in question just fails.... https://www.mintscan.io/osmosis/txs/F007D9DB5DE0EC7D6F71ED97925349ED1A5B2355628320AD51BDDCC2C32ED1E2

[davidkonigsberg]

Ok, so this error is actually coming from Lens.... It seem like this msg type isn't even valid... not sure how that is possible though... Wondering if we need to make changes to lens so it can fail safer?

In other words, if lens encounters a msg it doesn't know how to parse, rather than error out, just log and continue... or something... @KyleMoser might need a hand with this when you have time.

[KyleMoser]

@davidkonigsberg Sorry, I didn't even see this notification. I'm on a lot of GH repos (will clean up now that I noticed I'm buried with Cosmos repos I don't care about).

The only reason I know of that lens would say a message type is invalid, is because the codec for the type isn't registered with lens. If you do a search for ModuleBasics in lens, that is where all of the message types should be registered.

BTW, moving this issue to high priority

[danbryan]

@davidkonigsberg @KyleMoser is this still blocked

[davidkonigsberg]

@danbryan I havne't had a chance to dig into this more since @KyleMoser responded. I think I already checked to make sure lens had the module registered, but I will need to look again.

I will move this ticket from blocked to TODO and will work on it once the other CSV parsers are completed.

[davidkonigsberg]

@KyleMoser I am finally looking at this again, and I don't think the issue is as simple as a missing module (although I may be wrong). To me, it looks like an incompatibility between the version of osmosis that created this block, and the version of osmosis that lens is using to decode the message.... although I'm really not sure. Would you have some time to pair on this?

[davidkonigsberg]

Looks like others have run into this issue: osmosis-labs/osmosis#1017

[davidkonigsberg]

Looks like they closed it because of this PR: osmosis-labs/osmosis#1066 but that PR doesn’t actually fix it….

I feel like this is just broken…. not sure what we can do here unless we really hack together an alternate version that uses the old code and fails over to that if this doesn’t work…. to me that sounds like go import hell though, and I’m not even sure how I would go about doing it…

Changing this ticket backed to blocked....

[danbryan]

Curious, do we care about failed transactions outside of the fees?

[davidkonigsberg]

I don't think so... @KyleMoser ?

[danbryan]

If not, the next question would be, have we encoutered any /osmosis.gamm.v1beta1.MsgCreatePool that have succeeded. Could be a non / low priority issue if thats the case

[davidkonigsberg]

Good question, not sure, I will see if I can find one.

[pharr117]

I have some experience with this one. If you follow the link here that David pointed out above, you will see that the Osmosis devs have changed the name from MsgCreatePool -> MsgCreateBalancerPool.

What this does is break the chain's ability to decode old message types since type names are used in the process of decoding backend state to generate the proper message type.

Essentially, since Osmosis deprecated the old type, the current version of Osmosis will never be able to properly decode its own state to return to us. Since we use the current version of Osmosis in Lens to decode the messages, this breaks.

Either Osmosis will need to come to a conclusion to resolve this issue, or we will need to explore alternative methods of getting the message into the proper type.

[danbryan]

Can we import a map of osmosis versions to block-heights and make sure we are using the version that was used to create the block?

[KyleMoser]

In lens we just need to make a folder and put the old type in the folder. Then register the type the same way all other types get registered (look at ModuleBasics in lens to follow the flow)

…

On Mon, Feb 27, 2023, 9:31 PM pharr117 ***@***.***> wrote: I have some experience with this one. If you follow the link here <osmosis-labs/osmosis#1017> that David pointed out above, you will see that the Osmosis devs have changed the name from MsgCreatePool -> MsgCreateBalancerPool. What this does is break the chain's ability to decode old message types since type names are used in the process of decoding backend state to generate the proper message type. Essentially, since Osmosis deprecated the old type, the current version of Osmosis will never be able to properly decode its own state to return to us. Since we use the current version of Osmosis in Lens to decode the messages, this breaks. Either Osmosis will need to come to a conclusion to resolve this issue, or we will need to explore alternative methods of getting the message into the proper type. — Reply to this email directly, view it on GitHub <#202 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABMM5HMXKAKHNIE2BXSNPC3WZVPP3ANCNFSM6AAAAAATNJVJWY> . You are receiving this because you were assigned.Message ID: ***@***.***>

[danbryan]

Chatted about this in the 3/8/23 sprint, has not been resumed yet

[danbryan]

march 15th,

@KyleMoser said

I'm still figuring out if I implemented #202 correctly (trying to get csvs with it). Gotta compare the csv to Join pool ones I think

[KyleMoser]

The indexer is implemented correctly (I believe), but the CSV parser needs work still.

[danbryan]

@pharr117 mind checking if this one can be closed out?

[pharr117]

Just reran the indexer on this block and it succeeds, closing.