~~During spec writing, I realised one issue.
If the Request is canceled, then the hosts are allowed to call freeSlot only when the Slot's state is Canceled which happens only after the client calls withdrawFunds().
Is that a problem? While yes, the client is motivated to get its money back, it could be that for some reason he either does not do it at all (some sort of attack) or does it late, in both cases the hosts collateral (and partial payout, which won't be the main problem though) is locked up and opportunities are lost. WDYT?~~
~~During spec writing, I realised one issue. If the Request is canceled, then the hosts are allowed to call
freeSlotonly when the Slot's state is Canceled which happens only after the client callswithdrawFunds(). Is that a problem? While yes, the client is motivated to get its money back, it could be that for some reason he either does not do it at all (some sort of attack) or does it late, in both cases the hosts collateral (and partial payout, which won't be the main problem though) is locked up and opportunities are lost. WDYT?~~Edit: I notice that actually the
requestState()function actually returns Cancelled dynamically based on the timestamp comparison withexpiry, so the above is not an issue. But I am wondering if it does make sense to store theCancelledstate here: https://github.com/codex-storage/codex-contracts-eth/blob/576fefe46e9d5a27bbba10bd257bd9957f504ddc/contracts/Marketplace.sol#L348 ?Edit2: Aaah makes sense - it is needed in order not to allow withdraw the funds twice. Nevermind I am closing the issue ;-)