bug: ONFT721MsgCodec ignores sender offset when decoding composed messages.

[jvaleskadevs]

EDIT !!

• I just realized that it may not be a bug but desired functionality. Tho, it is very confusing and the addition of the SENDER_OFFSET and two new functions composeMsgFrom and composeMsgPayload may help future developers and contributors. I am currently working on a pull request including these additions.

Describe the bug

The file packages/onft-evm/contracts/onft721/libs/ONFT721MsgCodec.sol is trying to decode composed messages ignoring the SENDER offset (96).

This same library is encoding the messages in two different ways depending whether there is a composed message or not.

When there is a composed a message, the encode function is concatenating the SENDER address as bytes32 and the composed message composeMsg as bytes on the trail of the sendTo address as bytes 32 and tokenId as uint256 but ignoring the SENDER offset when decoding the composed message.

This is working fine when there is no composed message but transactions are reverting on destination chain when there is a composed message and the library tries to decode it.

To Reproduce
Steps to reproduce the behavior:

1. Deploy a mesh including any ONFT from the examples including the packages/onft-evm/contracts/onft721/libs/ONFT721MsgCodec.sol library.
   tested with:
   • NFT(baseSepolia)-ADAPTER(baseSepolia)-ONFT(arbitrumSepolia))

  {
        msgType: 2,
        optionType: ExecutorOptionType.LZ_RECEIVE,
        gas: 666_666,
        value: 0,
      },

2. Send an ONFT through the mesh including a composed message of type 2 (with no composer contracts, it may skip the call to lzCompose, vertical composability!!). (tested with a string representing the tokenURI in base64 format)
3. Transaction will success in origin but will revert in the destination chain. Leaving the ONFT stuck or burnt forever?!. I think it may be caused of there is no horizontal composability and no call to lzCompose. The composed message is not forwarded?!. It was the initial intention, I wanted to decode the tokenURI and use it to set tokenURI atomically with the NFT transfer.

---

example of a failed transaction where a composed message is included but the composability is vertical and there is no lzcompose execution: https://testnet.layerzeroscan.com/tx/0xdda48f50a82882cbbc42b7e2abb7efad4139d193554e9330ab30f19645ae9e6b

• NFT gets locked forever in origin chain and it is never minted in destination chain, with no retry option?!

Expected behavior

• The transaction to success on origin and destination chains
• To lock or burn the ONFT on origin chain and receive it on destination chain.

To Fix

Screenshots

added a PR #1880