Issues with Light Client verification for relayer v0 MVP

[ancazamfir]

Crate

relayer

Summary of Bug

There are a few issues to solve after #363

• (fixed in Minimal implementation of backward verification for IBC relayer tendermint-rs#709)
  Multiple on-chain clients may be at different heights, let's say h1 and h2, h1 < h2. Assume the relayer local client is at h2. Currently, if we want to update the on-chain client that is at h1, we call verify_to_target(h1) and this returns an error as h1 is smaller than the latest trusted height (h2).

• (Cannot run relayer commands concurrently #501) If light clients are configured to use the same store path, running two relayer processes concurrently to create clients on different chains will fail with:
  error: client create failed: tx error: Light client error: IO error: could not acquire lock on "data/DEEB0AB3F2D7BEC0B8C9FF1532715635314F54D5/db": Os { code: 35, kind: WouldBlock, message: "Resource temporarily unavailable" }

• (fixed in Fix formatting of tendermint::Time values tendermint-rs#775)
  Once in a while on update client and other clis:

  The application panicked (crashed).
  Message:  called `Result::unwrap()` on an `Err` value: Error(Context { kind: LightClient, source: Some(Error(Context { kind: NoWitnesses, source: None, backtrace: Some(   0: backtrace::backtrace::libunwind::trace
              at /Users/ancaz/.cargo/registry/src/git.luolix.top-1ecc6299db9ec823/backtrace-0.3.55/src/backtrace/libunwind.rs:90:5
  

  Most of the times the command will succeed the second time.

• (fixed in Specify proposer when constructing validator set in light client tendermint-rs#706) LightBlock's ValidatorSet must have the proposer and voting power set. This is temp fixed in cosmos.rs:fix_validator_set().

• (Allow overriding peer_id, height and hash in light add command #428, Add option to light rm command to remove all peers #431) It difficult do manage the client section in the configuration file. It is more now during development as we restart the chains often and the config file keeps around the old configuration (unless we manually clean it up) that may sometimes be in conflict with the new one. In addition we need to add witnesses manually.

• There seems to be leaking between global rpc_addr and address in client sections, with some queries using the client address.

---

For Admin Use

• Not duplicate issue
• Appropriate labels applied
• Appropriate milestone (priority) applied
• Appropriate contributors tagged
• Contributor assigned/self-assigned

[ancazamfir]

All items have been closed