[☂️ Tooling, Migration] Umbrella ticket for cosmos-sdk v0.50 migration

[bryanchriswhite]

Objective

Captures tasks related to the v0.50 migration that may not otherwise have a place to go yet.

See: v0.50 migration guide.
NOTE: there's a broken link in the BaseApp section; see: cosmos/cosmos-sdk#19155.

Origin Document

Rollkit

The Rollkit team is maintaining two branches (v0.4x and v0.5) until everyone is fully off of the prior version. We can stick on v0.4x for as long as this is supported, but ideally migrate sooner after MVP business logic is complete.

Source Code

Goals

• Capture/accumulate outstanding tasks associated with cosmos-sdk v0.50 migration as they're identified to mitigate loosing track of things.
• Coordinate changes to binaries, ignite, techdebt, rollkit and cosmos during the migration

Deliverables

Comprehensive migration instructions and notes notion doc

Specific TODOs

• Update links to cosmos-sdk documentation:
  • EventsQueryClient and EventsReplayClient markdown docs, links to cosmos-sdk docs.

Migration strategy

Options:

1. “In-place” migration

   Steps:

   1. Update rollkit/cosmos-sdk version in go.mod and resolve all resulting import issues:

      1. Replace imports for cosmos-sdk objects that have moved:

         1. Fairly straightforward for doing this In our code using find-and-replace.
         2. When the need for this arises in a dependency (i.e. replaced import is a nested dependency), it must be updated in the go.mod

         We did not see any indication that we were approaching completion of this step in the time that we spent moving in this direction.

         (Perhaps deleting the go.sum could assist in automating this part; not tested.)

   2. Follow the official cosmos-sdk migration guide to manually re-wire our existing appchain components.

   3. Discover and correct for any rollkit-specific integration hang-ups. We should expect few to none exist depending on how many times this has been attempted by other rollkit (possibly vanilla as well) cosmos-sdk chains which are actively running networks.

2. “Re-scaffold” migration

   1. Outlined in [Cosmos-SDK v0.50.1 Migration](https://www.notion.so/Cosmos-SDK-v0-50-1-Migration-2d757ec3f88c4251a6712bcb5f3b4e97?pvs=21) (bottom)

Merge procedure:

gitGraph
commit
branch migration_base
commit id:  "delete on-chain code"
commit id: "temp devops changes"
commit id: "re-scaffold chain"
branch migration_gateway
commit id: "re-scaffold gateway module"
commit id: "re-scaffold gateway store"
commit id: "re-scaffold gateway messages"
commit id: "port gateway tests"
commit id: "port gateway types"
commit id: "port gateway logic"
checkout migration_base
branch migration_service
commit id: "re-scaffold service module"
commit id: "re-scaffold service store"
commit id: "re-scaffold service messages"
commit id: "port service tests"
commit id: "port service types"
commit id: "port service logic"
checkout migration_base
merge migration_gateway
merge migration_service
checkout main
merge migration_base

Loading

Review strategy

Reorganize diff, for review purposes only, such that module code in each migration_<module> branch can be compared to their respective main counterpart code:

git checkout main
git branch migration_review_gateway
git cherry-pick migration_base..migration_gateway

gitGraph
commit
branch migration_base
commit id:  "delete on-chain code"
commit id: "temp devops changes"
commit id: "re-scaffold chain"
branch migration_gateway
commit id: "re-scaffold gateway module"
commit id: "re-scaffold gateway store"
commit id: "re-scaffold gateway messages"
commit id: "port gateway tests"
commit id: "port gateway types"
commit id: "port gateway logic"
checkout main
branch migration_review_gateway
cherry-pick id: "re-scaffold gateway module"
cherry-pick id: "re-scaffold gateway store"
cherry-pick id: "re-scaffold gateway messages"
cherry-pick id: "port gateway tests"
cherry-pick id: "port gateway types"
cherry-pick id: "port gateway logic"
checkout main
merge migration_review_gateway type: REVERSE

Loading

• Review branch cherry-pick script:

  #!/bin/bash
  
  # The branch you want to cherry-pick onto
  TARGET_BRANCH=$1
  
  # Range of commits to cherry-pick
  COMMIT_RANGE=$2
  
  # Checkout the target branch
  echo "Checking out to $TARGET_BRANCH"
  git checkout $TARGET_BRANCH
  
  # Function to handle removing files deleted in the migration base branch
  rm_moved_files() {
      local commit_hash=$1
      echo "Checking for file movements in commit $commit_hash..."
  
      # Get a list of new files in 'proto/poktroll'
      NEW_FILES=$(git diff --name-only --diff-filter=A $commit_hash^..$commit_hash -- proto/poktroll/)
  
      for NEW_FILE in $NEW_FILES; do
          # Construct the corresponding file path in 'proto/pocket'
          OLD_FILE=$(echo $NEW_FILE | sed 's/proto\/poktroll/proto\/pocket/')
  
          # Check if the corresponding file exists in 'proto/pocket'
          if [ -f $OLD_FILE ]; then
            git rm $OLD_FILE
            git amend --no-edit
          else
              echo "No corresponding file in 'proto/pocket' for $NEW_FILE"
          fi
      done
  }
  
  # Loop through each commit in the range
  for COMMIT_HASH in $(git rev-list --reverse $COMMIT_RANGE); do
      echo "Cherry-picking commit $COMMIT_HASH"
      # Attempt to cherry-pick the commit
      if ! git cherry-pick $COMMIT_HASH > /dev/null 2>&1; then
          echo "Conflict detected in $COMMIT_HASH, resolving..."
  
          # Resolve conflicts by accepting "theirs"
          git checkout --theirs .
          git add .
  
          echo "Continuing cherry-pick of $COMMIT_HASH"
          # Continue the cherry-pick
          git cherry-pick --no-edit --continue
      else
          echo "Cherry-picked $COMMIT_HASH successfully"
      fi
  
      # Remove protobuf files whith were moved (at each commit)
      rm_moved_files $COMMIT_HASH
  done
  
  echo "Cherry-pick range and file movements completed."

NOTE: It doesn’t seem possible to rely on git mv to consistently produce a “move diff” in the github UI due the separation of concerns between tracking and representing the diff (i.e. we would have to change how github does the diff part). I experimented for an hour or so with mixed / inconsistent results.

• See this excerpt from a conversation I had with chatGPT about it:

  

An alternative would be to manually run something like git diff -M0% explicitly on files that we know were moved; e.g. proto/pocket/* ⇒ proto/poktroll/*.

---

Creator: @bryanchriswhite
Co-Owners: @Olshansk @okdas

[Olshansk]

@bryanchriswhite I literally create a draft for this so ty for taking the charge. Going to make some edits in-place.

[okdas]

New ignite cli version seems to add support for 0.50: https://github.com/ignite/cli/releases/tag/v28.0.0

[Olshansk]

@bryanchriswhite I've been looking at [1], and there seem to be a lot of changes we'll need to manage. I'm holding myself back from applying them, but I believe we should try and prioritize (behind business logic) it in the next iteration (2 weeks from now).

[1] https://docs.cosmos.network/main/build/migrations/upgrading#v050x

[Olshansk]

Wanted to bump this and reiterate its priority in the next iteration.

It'll block us from a variety of things such as:

• Working with RaaS providers
• Metrics Integration
• Keeping upstream
• Etc...

Let's start thinking/planning for potentially put other work on hold to make sure this is accounted for.

cc @okdas

[h5law]

Going to sync with @bryanchriswhite on monday (2024/01/22) and we'll get this migration going! Exciting times 🚀

[h5law]

Both #319 and #347 will be tackled in part/full during the migration. We will also address #328 (comment) where appropriate - and update tests that depend on error.Is or error.As accordingly.