Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Hydra node cannot handle time conversion once 2k blocks have passed #487

Closed
abailly-iohk opened this issue Sep 13, 2022 · 3 comments · Fixed by #523
Closed

Hydra node cannot handle time conversion once 2k blocks have passed #487

abailly-iohk opened this issue Sep 13, 2022 · 3 comments · Fixed by #523
Assignees
Labels
bug 🐛 Something isn't working
Milestone

Comments

@abailly-iohk
Copy link
Contributor

Context & versions

This is a follow-up issue that surfaced as we worked on cleaning up contestation deadline in #483

Steps to reproduce

Note these are all very abstract, we know there is a bug but I did not actually observed it

  1. spin up a hydra-node
  2. open a head
  3. wait for 2k blocks to pass on-chain
  4. try to compute contestation period by closing the head

Actual behavior

Node fails to compute contestation deadline (and crashes?)

Expected behavior

Node should correctly compute contestation deadline.

@abailly-iohk abailly-iohk added the bug 🐛 Something isn't working label Sep 13, 2022
@abailly-iohk abailly-iohk added this to the 0.8.0 milestone Sep 13, 2022
@abailly-iohk
Copy link
Contributor Author

This is a follow-up to #483.

Solutions envisioned:

  • Short-term: Do not allow heads to live longer than 2k
  • Assume no upper-bound on current Era's time parameters
  • Requery EraHistory upon every time computation

@ch1bo
Copy link
Collaborator

ch1bo commented Sep 19, 2022

This is because the time handle queried here becomes to old and we should have addressed this comment: #483 (comment).

@ch1bo
Copy link
Collaborator

ch1bo commented Sep 20, 2022

We discussed the two approaches and decided to:

  • Do the morally right thing first by querying the time handle on each block rolled forward using a MonadTimeHandle type class to abstract over IO/IOSim.
  • If this is too expensive or not possible, we draw the line there and fall back to use unsafeExtendSafeZone, possibly updating the TimeHandle to fetch once and deliver current time/slot continuously instead.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment