我们昨晚在主网上升级 JoyID 合约，JoyID 合约本身包括了 4 个 lib，所以是 depGroup 形式的 cellDep.
我们使用的是 ckb-cli 内置的合约升级命令：
deploy gen-txs
deploy sign-txs
deploy apply-txs整个升级流程我们之前在主网也走了很多遍，但是昨晚遇到了一个新情况，导致合约升级的两笔交易只有一笔上链了，depGroup 交易失败了，现象如下：
CKB> deploy apply-txs \
--migration-dir /home/dylan/temp/migrations \
--info-file /home/dylan/temp/info.json
> [send cell transaction]: 0x8a605a4402cadda69fa64fd25cbbd74058e3eb86a7a72aee3d25df278564d31b
> [send dep group transaction]: 0xdcbf65dd83c817748a60dbef85c222aebd0da471ac574daa38dc9d479193a699
Send transaction error: jsonrpc error: `Server error: TransactionFailedToResolve: Resolve failed Unknown(OutPoint(0x8a605a4402cadda69fa64fd25cbbd74058e3eb86a7a72aee3d25df278564d31b05000000))`检查两笔交易结构后，我发现第二笔交易提供 tx fee 的 input 来自第一笔交易的输出，看起来这是一个链式交易，可能昨晚的网络也不稳定，导致第二笔交易失败了。
再次尝试执行发送交易命令，会有如下报错：
CKB> deploy apply-txs \
--migration-dir /home/dylan/temp/migrations \
--info-file /home/dylan/temp/info.json
Invalid cell status: unknown, out_point: OutPoint { tx_hash: Byte32(0xbdc3153fcb7c256d007be758c0b50c8da60b5ac0e44ae9e11d3dcc5b73d2b347), index: Uint32(0x00000000) }之后就一直失败，此时的现象就是第一笔交易已经上链，第二笔交易用现有的 deploy apply-txs 命令已经无法正常上链了。
最后我尝试用 ckb-cli 的命令手动拼装第二笔交易，命令如下：
CKB> tx add-multisig-config --sighash-address \
ckb1qyqfu4qsfz6nxmy7jdtsmg9euszyjxxehzaqx9agdp \
ckb1qyqt755qgpae8geggyj6ghnk92lssf5hkkqqjuge8f \
ckb1qyqde75dumsc8g9v4f7nuusa57v8w5e2v3nqlcukx8 \
ckb1qyq0mpgkgasqskx8sgsuewyqy5kprqfmxkas49888k \
ckb1qyqwn4c0ke5teq8jqsvtppxq7m8zk77cq95s9ztdu8 \
--require-first-n 0 --threshold 3 --multisig-code-hash 0x5c5069eb0857efc65e1bca0c07df34c31663b3622fd3876c876320fc9634e2a8 --tx-file /home/dylan/tx/tx.json
CKB> tx add-input --tx-hash 0xf05188e5f3a6767fc4687faf45ba5f1a6e25d3ada6129dae8722cb282f262493 --index 0 --tx-file /home/dyla
n/tx/tx.json
status: success
CKB> tx add-input --tx-hash 0x8a605a4402cadda69fa64fd25cbbd74058e3eb86a7a72aee3d25df278564d31b --index 5 --tx-file /home/dylan/tx/tx.json
status: success交易的 outputs 部分用 tx add-output 会报错，可能是多签地址没适配好？最后我尝试在 tx.json 中手动补充完整的 outputs 和 outputsData，然后进行3轮的依次签名，最终交易顺利上链了。
CKB> tx sign-inputs --from-account 0x9e541048b5336c9e93570da0b9e4044918d9b8ba --tx-file /home/dylan/tx/tx.json --add-signatures
Password:
- lock-arg: 0xd1dbde9214a1cb1e377c9b643ae5c680de0cb95c
signature: 0x4a64363f956dce94da3204886cf4f0e423a830c7563e0c03659d55c3e76afba528baf392c6840c262321594fbe107ae9d3a20aca09167cdbc6d8c8369f70397800
CKB> tx send --tx-file /home/dylan/tx/tx.json
0xdcbf65dd83c817748a60dbef85c222aebd0da471ac574daa38dc9d479193a699本次升级完合约，我们测试期间发现了一个问题，有一个参数测试网和主网是不同的，主网的合约误用了测试网的参数，于是我们又升级了一次合约。
鉴于第一次遇到的问题，我在使用 deploy gen-txs 生成 info.json 后手动修改了 info.json 中第二笔 depGroup 提供 tx fee 的 input，将其从原来的依赖第一笔交易的 output 换成了该 lock 的其他 empty cell，然后依次进行三轮签名，结果就很顺利，没有再遇到上述问题。过程如下：
CKB> deploy gen-txs \
--deployment-config /home/dylan/temp/deployment.toml \
--migration-dir /home/dylan/temp/migrations \
--from-address ckb1qyq0mpgkgasqskx8sgsuewyqy5kprqfmxkas49888k \
--sign-now \
--info-file /home/dylan/temp/info.json
==== Cell transaction ====
[cell] Changed , name: joyid-lock, old-capacity: 100462.0, new-capacity: 100438.0
[cell] Unchanged, name: secp256r1-lib, old-capacity: 66718.0, new-capacity: 66718.0
[cell] Unchanged, name: ckb_smt, old-capacity: 21646.0, new-capacity: 21646.0
[cell] Unchanged, name: secp256k1-lib, old-capacity: 70830.0, new-capacity: 70830.0
[cell] Unchanged, name: rsa, old-capacity: 71054.0, new-capacity: 71054.0
[cell] Reference, name: secp256k1_data, old-capacity: 0.0, new-capacity: 0.0
> old total capacity: 330710.0 (CKB) (removed items not included)
> new total capacity: 330686.0 (CKB)
[transaction fee]: 0.00101269
==== DepGroup transaction ====
[dep_group] Changed , name: dep_group, old-capacity: 281.0, new-capacity: 281.0
> old total capacity: 281.0 (CKB) (removed items not included)
> new total capacity: 281.0 (CKB)
[transaction fee]: 0.00001092
Password:
status: success
# 手动修改 info.json 中 depGroup 交易的 inputs[1]，将其替换为该 lock 的其他 emtpy cell
cell_tx_signatures:
0x07a21dc2d33dca6604c5056d54c6f8ce429d68ca: 0x8d452c7e2d0f4e29945ec7aeb3c6d94168caa5abdb30954b685ab60d7cae65390082a905075a225d3d4c926d625d4f6219b93f0e4138d24ea9e8509f104120ef01
0xfd851647600858c78221ccb880252c11813b35bb: 0x5036c09a0778401adb046f9882051d6bc7efd85ef14399d694c2583c57a9a85506965e5e783e02c69f587b26ac39acf4f285043cc0210f784a553dc427c266c000
dep_group_tx_signatures:
0x07a21dc2d33dca6604c5056d54c6f8ce429d68ca: 0x11c832cf0722b16514f3db9d9045be109a33548289fbc3b3213fb7a30e3b6d9b2df59a86251842ea21c39aaa376252a333c33344b9a1ff069299a67dc13521fe01
0xfd851647600858c78221ccb880252c11813b35bb: 0x6b4667086cb820d924879e016d1756d0e9b11c799a0ece47522e3a1a5018d3cf327f06208d7309433fc48a5b009d2f1cf1151ed1fbfbf05596d2a2e3b391eb4c00
CKB> deploy apply-txs \
--migration-dir /home/dylan/temp/migrations \
--info-file /home/dylan/temp/info.json
> [send cell transaction]: 0x4f5d09d1af01e97b53526a4c01bf7d482adc5e634a3d43d6081bfa6d013682c0
> [send dep group transaction]: 0xaac4f0e31adda9ac98e4c446063e2725f9e98a01d1aa94ef34077c7c6a1d6b9f
cell_tx: 0x4f5d09d1af01e97b53526a4c01bf7d482adc5e634a3d43d6081bfa6d013682c0
dep_group_tx: 0xaac4f0e31adda9ac98e4c446063e2725f9e98a01d1aa94ef34077c7c6a1d6b9f
CKB>
整个过程下来我们发现在进行 depGroup 合约部署时，两笔交易存在链式交易依赖，因为网络或者其他原因，可能会导致第二笔交易上链失败，第二次升级我们手动改了第二笔 depGroup 交易的 inputs，避免第二笔交易依赖第一笔交易的 outputs。
ckb-cli 团队可以评估这是否是一个潜在的问题，以上供参考，如有什么信息，缺失，可以随时告知。
Hi @duanyytop
ckb-cli 使用的 API_URL 环境变量的值是多少？ 是不是 https://mainnet.ckbapp.dev/ ?
TransactionFailedToResolve 出现的原因是： 测试网节点有很多个，运维同事做了负载均衡， 通过 API_URL=https://mainnet.ckbapp.dev/ 发送交易时，
send cell transaction被分流到了 节点A,send dep group trnasaction被 分流到了节点 B, 在 节点B 的交易池中没有来得及看到 发送到节点A 的交易。你试试用 API_URL=https://mainnet.ckb.dev/ ，这个好像没有负载均衡。