fix: time travels & onchain clock #327
Conversation
| /// # Returns | ||
| /// A `TransactionResult` indicating success or failure. | ||
| pub fn airdrop(&mut self, pubkey: &Pubkey, lamports: u64) -> TransactionResult { | ||
| self.updated_at = Utc::now().timestamp_millis() as u64; |
There was a problem hiding this comment.
Originally this updated_at field was used to track an "idle" surfnet for the MCP server. This field was update whenever a user action was taken (getting an account, updating an account, etc). What is the purpose of the field now? Are we breaking things with the MCP by removing these calls? Can we remove the updated_at field altogether now?
There was a problem hiding this comment.
I don't think it's going to break the MCP. blocks are still produced in the background, updating this value?
There was a problem hiding this comment.
This was meant to track user interaction, not block production. Again, to determine if a network is "idle", as in a user isn't using it. At least, that's my understanding of what you and Arthur implemented for this. We needed to know if a network was being used by the user so you could kill it after 15m if not. If that's the use case, block production updating this value would keep the network online indefinitely.
If the MCP doesn't need this field, I guess I'm questioning what "updated_at" means/represents, and if the field can be removed or renamed
There was a problem hiding this comment.
Interesting I thought that field was always there.
We're currently producing blocks every 400ms, and being able to track the clock at the ms scale is better for time travel precision (maybe not mission critical).
To your point, I don't think we were ever able to convince ourselves that the 15m timeout was working as expected, and this field being updated every time a block is being confirmed would definitely prevent the auto-termination.
updated_at feels like the right name to me for what is being done here.
We could introduce a last_used_at (sec instead of milliseconds) to fix the auto-termination?
There was a problem hiding this comment.
Okay cool, I can reset my understanding of that field. This is where we introduced that field btw: f3e7e7a#diff-3c2b6db2274e8aa434e77af36810870fb9e07b4fa4419a913ccc835784b6589cR136-R138
There was a problem hiding this comment.
Gotcha, I remember now yeah.
No description provided.