You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I got some weird behavior with deal-tracker
Deal state changed {"dealID": xxx, "oldState": "proposal_expired", "newState": "published"}
marked 3 deal as proposal_expired
updated 3 deals and inserted 0 deals
How could a deal move from expired to published?
Happens each round, with the same message, so guess no real update is being done
Steps to Reproduce
A couple IDs I have at the moment:
2023-09-20T09:32:43.957+0200 INFO dealtracker dealtracker/dealtracker.go:468 Deal state changed {"dealID": 54464983, "oldState": "proposal_expired", "newState": "published"}
2023-09-20T09:32:44.307+0200 INFO dealtracker dealtracker/dealtracker.go:468 Deal state changed {"dealID": 54486432, "oldState": "proposal_expired", "newState": "published"}
Version
singularity v0.4.1-a1977e5
Operating System
Linux
Database Backend
SQLite
Additional context
No response
The text was updated successfully, but these errors were encountered:
The root cause identified. When determing new state, there is 1 day of buffer time to consider when the deal proposal has expired to take into account the potential latency of lotus API / state market deals. After updating the state, the deal is updated back to expiration based on the actual delay of lotus API. Those two time mismatched, causing the deal to be updated back and force between expired and published within that 24 hours window
resovles #336
Previously, we are making a 24 hour buffer time to account for potential
latency of StateMarketDeals call. However, that leads to some deal state
to change between expired and published during 24 hour window as the
buffer time for marking a deal expired comes from the last updated time
inside StateMarketDeal payload.
This change fixes most of the problem by first calling Lotus ChainHead
to determine the current lotus latency first. Edges cases are handled
below
* If the StateMarketDeals response is based on an earlier epoch than
ChainHead response, then it's likely some deals are in expired state
based on ChainHead latency but is not expired in StateMarketDeals
response, the state of the deal will be updated in the next run when
StateMarketDeals response is based on a later epoch
* If the StateMarketDeals response is based on a latter epoch than
ChainHead response, then those deals that are in non_expired state based
on ChainHead latency will be marked as expired
Description
Steps to Reproduce
A couple IDs I have at the moment:
2023-09-20T09:32:43.957+0200 INFO dealtracker dealtracker/dealtracker.go:468 Deal state changed {"dealID": 54464983, "oldState": "proposal_expired", "newState": "published"}
2023-09-20T09:32:44.307+0200 INFO dealtracker dealtracker/dealtracker.go:468 Deal state changed {"dealID": 54486432, "oldState": "proposal_expired", "newState": "published"}
Version
singularity v0.4.1-a1977e5
Operating System
Linux
Database Backend
SQLite
Additional context
No response
The text was updated successfully, but these errors were encountered: