Skip to content

Conversation

@devbugging
Copy link
Collaborator

Implementation of callback scheduler contract following the FLIP onflow/flips#331

@devbugging devbugging marked this pull request as ready for review June 25, 2025 18:20
@devbugging devbugging requested a review from joshuahannan as a code owner June 25, 2025 18:20
Copy link
Member

@joshuahannan joshuahannan left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I haven't really started looking at the SharedScheduler resource yet, but I figured I'd leave these comments now so you can start looking at them while I'm reviewing that part and you can start answering my questions

}

let amount = self.fees.balance * multiplier
return <- self.fees.withdraw(amount: amount) as! @FlowToken.Vault
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

what happens to fees that aren't withdrawn? Are they just burnt?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good question, not sure what is the pattern for that on the service accounts, should we just destroy the vault?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this is probably something that should be brought up with the governance/tokenomics people. I would imagine that the right call would just be to destroy them, but anything that has to do with minting/destroying FLOW by the protocol should be a bigger discussion that we get more approvals on. Can you add a section to the FLIP about this? I think we should propose to destroy the leftover FLOW

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Will add a section. They are destroyed now.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If it's easy, we should put them into the fee pool, if that's hard, we can just burn them.

Copy link
Member

@turbolent turbolent left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Great work! Mostly looked at the PR from a Cadence code perspective, didn't review the logic

Copy link
Member

@joshuahannan joshuahannan left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm just leaving my comments here as notes for myself for when I make my changes in my PR. I am updating the target branch to the feature branch and merging it into that and not into master so I can more easily work on it

Comment on lines +198 to +200
// minimum execution effort is the minimum effort that can be
// used for any priority
access(self) var minimumExecutionEffort: UInt64
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this cumulative or per callback?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@devbugging Just flagging this for you to answer. I'll update the comment once I get an answer from you

// priority fee multipliers are values we use to calculate the added
// processing fee for each priority
access(self) var priorityFeeMultipliers: {Priority: UFix64}
// refund multiplier is the portion of the fees that are refunded when a callback is cancelled
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
// refund multiplier is the portion of the fees that are refunded when a callback is cancelled
// refund multiplier is the portion of the fees that are refunded when a callback is cancelled. Must be between zero and one

Is this true?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@devbugging flagging this one too

@joshuahannan joshuahannan changed the base branch from master to feature/callback-scheduling July 2, 2025 16:01
@joshuahannan joshuahannan merged commit 8fc371f into onflow:feature/callback-scheduling Jul 2, 2025
1 check failed
@turbolent
Copy link
Member

turbolent commented Jul 3, 2025

Was the merge an accident? All the feedback was just marked as resolved but there are no commits?

@joshuahannan joshuahannan mentioned this pull request Jul 3, 2025
@joshuahannan
Copy link
Member

I'm taking over a lot of this work from Gregor, so I merged this into a feature branch on this repo so I could make the changes myself here instead of Gregor's fork. The open PR is here: #486

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

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants