There's at least one bug here:
Imagine a case where a deposit app is proposed, but then the install fails for some reason (e.g. user offline).
If this happens, an evt timeout will be thrown from the requestDepositRights fn in deposit.service.ts. Then, we'll execute the cleanUpDepositRights() fn in the catch block. All good so far.
cleanUpDepositRights(), however, does the following:
const cleanUpDepositRights = async () => {
if (appIdentityHash) {
this.log.info(
`Releasing deposit rights on chain ${channel.chainId} for ${channel.multisigAddress}`,
);
await this.rescindDepositRights(appIdentityHash, channel.multisigAddress);
this.log.info(
`Released deposit rights on chain ${channel.chainId} for ${channel.multisigAddress}`,
);
}
};
where appIdentityHash = await this.requestDepositRights(channel, assetId);
If appIdentityHash is undefined (e.g. because the requestDepositRights function itself failed), we wont do anything to cleanUpDepositRights() here. Because the user is also offline, they won't be around to rejectInstall as per the try/catch in handleAppProposal in the client.
Not sure where this leaves the client but we should definitely handle this case better.
There's at least one bug here:
Imagine a case where a deposit app is proposed, but then the install fails for some reason (e.g. user offline).
If this happens, an
evt timeoutwill be thrown from therequestDepositRightsfn indeposit.service.ts. Then, we'll execute thecleanUpDepositRights()fn in the catch block. All good so far.cleanUpDepositRights(), however, does the following:where
appIdentityHash = await this.requestDepositRights(channel, assetId);If
appIdentityHashis undefined (e.g. because therequestDepositRightsfunction itself failed), we wont do anything tocleanUpDepositRights()here. Because the user is also offline, they won't be around torejectInstallas per the try/catch inhandleAppProposalin the client.Not sure where this leaves the client but we should definitely handle this case better.