test(medusa): disputer properties #58
Conversation
| assertEq(_ghost_disputes[_requestId].length, 0, 'property 6: new dispute duplicate'); | ||
|
|
||
| // add to ghost disputes | ||
| _ghost_disputes[_responseId].push(_disputeId); |
There was a problem hiding this comment.
Is _ghost_disputes key the request ID or the response ID? 😵💫
There was a problem hiding this comment.
hmm, it's request id everywhere (should be here) but I'm wondering if it shouldn't be the response actually (ie all disputes for a response, and it should always be 1 as subsequent are going to the resolution/arbitrator, right?)
There was a problem hiding this comment.
Each response may have only one dispute at maximum—I'd stick to request ID being the key, as Oracle::disputeOf already tracks the response to which each dispute is tied to.
and it should always be 1 as subsequent are going to the resolution/arbitrator, right?
That reasoning was correct though, if you meant to track bond-escalated disputes and resolution-escalated disputes separately.
| try bondEscalationModule.pledgeForDispute(_requestData, _disputeData) { | ||
| assertTrue(_ghost_escalatedDisputes[_disputeId], 'property 8a: pledging for a dispute not escalated'); |
There was a problem hiding this comment.
Beware there are two types of escalation processes: the bond escalation – only initiated for the first dispute of a request, by default – and the resolution escalation – started by default for subsequent disputes of the request, and available for the first one.
Pledging can only be performed for or against the first dispute of a request during the bond escalation process.
There was a problem hiding this comment.
hmm, I think there is indeed an issue with the ghost tracking "escalated" disputes, which doesn't really make a difference (ie some escalated aren't accounted as escalated).
Double checking, this is correct?
graph TD
request[request]
responseA[responseA]
responseB[responseB]
dispute3A[dispute3A]
dispute2A[dispute2A]
dispute1A[dispute1A]
dispute3B[dispute3B]
dispute2B[dispute2B]
dispute1B[dispute1B]
bondEscalation[bondEscalation]
arbitrator[arbitrator]
request --> responseA
request --> responseB
responseA --> dispute2A
responseA --> dispute3A
responseA --> dispute1A
responseB --> dispute1B
responseB --> dispute2B
responseB --> dispute3B
dispute1A & dispute1B --> bondEscalation
bondEscalation --> arbitrator
dispute2A & dispute2B --> arbitrator
dispute3A & dispute3B --> arbitrator
There was a problem hiding this comment.
The diagram is not correct in the following:
dispute1Bcannot go through bond escalation, as only the first dispute of the request – not of each response – can (previous comment of mine edited to further clarify this).dispute2A,dispute3A,dispute2Banddispute3Bcannot be created, as each response may have a maximum of one dispute.
There was a problem hiding this comment.
ok, got it, misunderstood the "Technically, every subsequent disputer escalates their own dispute upon creation, automatically.", this is for other responses
graph TD
request[request]
responseA[responseA]
responseB[responseB]
disputeA[disputeA]
disputeB[disputeB]
bondEscalation[bondEscalation]
arbitrator[arbitrator]
request --> responseA
request --> responseB
responseA --> disputeA
responseB --> disputeB
disputeA --> bondEscalation
bondEscalation --> arbitrator
disputeB --> arbitrator
| /// @custom:property-id 7 | ||
| /// @custom:property A disputer can only escalate the first disputed response | ||
| function prop_disputerEscalateFirstDisputedResponse( |
There was a problem hiding this comment.
Technically, every subsequent disputer escalates their own dispute upon creation, automatically. 🤔
# 🤖 Linear Closes GRT-XXX --------- Co-authored-by: drgorillamd <83670532+drgorillamd@users.noreply.github.com>
simon-something
merged commit 3730d59
into
test/property-ebo-request-creator
🤖 Linear
Closes GRT-XXX