-
Notifications
You must be signed in to change notification settings - Fork 72
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
Aggegate bonded - Failure_Core_Future_Deadline #1490
Comments
Some notes:
|
@surekabpm seems like this task was automatically moved to the Issue Backlog after you reopened it. Can you confirm it needs to be reopened? |
This one by mistake I closed it and later have to reopen |
This should be tested after code review. |
@bassemmagdy announcing transaction doesn't work: |
@cryptoBeliever please provide some steps to reproduce. |
@bassemmagdy Create multisig account with 2 co-signors and initiate transaction from multisig account. |
Previous error I'm not able reproduce but now I can see errors with Timestamp too far in the future after a few tries of sending: |
@bassemmagdy looks like the number of API calls to the /time endpoint is too big. Please check video: Maybe wallet should have only time synchronization periodically called like once per minute? |
As we discussed on the daily meeting there will be a change regarding time synchronization with a node. To avoid frequently ask /time endpoint. |
Allow to calculate "server" deadlines without calling /time endpoint each time. We should probably also refresh server time each X minutes (like 5) and when user switch node. |
All issues fixed 👍 |
@bassemmagdy please merge into dev. |
Steps:
Result: Announcing hash lock failes with error "Failure_Core_Future_Deadline":
Questions:
Why Hash lock transaction deadline is set to 6 hours? Hash lock is confirmed immediately. Why it has 6h instead of 2h like a normal transaction?
When the user operating system clock is ahead 1minute (or node clock 1minute behind) the user gets an error as above. I assume here that the max deadline for the hash lock is 6h but it seems correct assumption.
Wouldn't better to use node time (/node/time) instead of local user time?
The text was updated successfully, but these errors were encountered: