Chain compatibility #3345
Chain compatibility #3345
Conversation
- no need to calculate the free balance, now we have the pure free field without the reserved balance. - rename locked field with reserved. - in profile manager added the free to the reserved to show total balance
add yarn before running gereratedefses and meta types
| @@ -13,6 +14,8 @@ import { formatErrorMessage } from "../../helpers"; | |||
| import { ContractStates } from "../../modules"; | |||
| import { Graphql } from "../graphql/client"; | |||
|
|
|||
| const ONE_HOUR = 1000 * 60 * 60; | |||
There was a problem hiding this comment.
In what unit exactly? Please change the variable name to a more descriptive one.
An ideal name for a variable that holds the number of milliseconds in one hour could be MILLISECONDS_PER_HOUR, which is descriptive and clearly convey the purpose of the variable.
| async calculateContractOverDue(options: CalculateOverdueOptions) { | ||
| const { lastUpdatedSeconds, standardOverdraft, additionalOverdraft } = options.paymentState; | ||
| const contractCost = await this.getConsumption({ id: options.id, graphqlURL: options.graphqlURL }); | ||
| const elapsedSeconds = new Decimal(Date.now()).minus(lastUpdatedSeconds).div(1000); |
There was a problem hiding this comment.
Given that ContractPaymentState.lastUpdatedSecond is already a timestamp in seconds, you need to convert the current timestamp from milliseconds to seconds before performing the subtraction, right?
The corrected code would be
const elapsedSeconds = new Decimal(Date.now()).div(1000).minus(lastUpdatedSeconds);
Date.now() returns the current timestamp in milliseconds, then .div(1000) converts the current time from milliseconds to seconds by dividing by 1000. finally .minus(lastUpdatedSeconds) subtracts lastUpdatedSeconds (which is already in seconds) from the current time in seconds.
| const { lastUpdatedSeconds, standardOverdraft, additionalOverdraft } = options.paymentState; | ||
| const contractCost = await this.getConsumption({ id: options.id, graphqlURL: options.graphqlURL }); | ||
| const elapsedSeconds = new Decimal(Date.now()).minus(lastUpdatedSeconds).div(1000); | ||
| const overdue = standardOverdraft |
There was a problem hiding this comment.
Can you please explain how the overdue is calculated, add a comment, and possibly simplify it by calculating it progressively using descriptive intermediary variable names?
| const elapsedSeconds = new Decimal(Date.now()).minus(lastUpdatedSeconds).div(1000); | ||
| const overdue = standardOverdraft | ||
| .plus(additionalOverdraft) | ||
| .times(elapsedSeconds.plus(ONE_HOUR).times((contractCost / 60) * 60)); |
There was a problem hiding this comment.
Units are not consistent here.
From what I see elapsedSeconds is in seconds, while ONE_HOUR is in milliseconds.
Perhaps you intended to set ONE_HOUR to 3600 (seconds) instead of 3600000 (milliseconds)?
Also, I'm trying to understand why we divide by 60 and then multiply by 60.
| .plus(additionalOverdraft) | ||
| .times(elapsedSeconds.plus(ONE_HOUR).times((contractCost / 60) * 60)); | ||
|
|
||
| return Number(overdue.div(10 ** 7)); |
There was a problem hiding this comment.
Again, add a comment to explain the division here, and/or first assign the result to a descriptive variable name like overdueTFT for better reliability, then return it. you can refer to the raw amount (before division) as overdueMicroTFT
| */ | ||
| async calculateContractOverDue(options: CalculateOverdueOptions) { | ||
| const { lastUpdatedSeconds, standardOverdraft, additionalOverdraft } = options.paymentState; | ||
| const contractCost = await this.getConsumption({ id: options.id, graphqlURL: options.graphqlURL }); |
There was a problem hiding this comment.
This is just an estimate, as some contracts might have public IP addresses, and the cost will depend on the amount of bandwidth used, which is likely to vary.
The cost calculation should simulate the billing process on tfchain (dry run) to provide a more accurate estimate. This involves checking the pricing policy, NU, and other resource consumption to determine the actual cost of the contract. Then, account for the time between the calculation and the submission of the transaction.
We still need to estimate the cost of this extra time, but it shouldn't be a problem. Since the cost changes dynamically, we should also update the cost accordingly. It's unlikely that we will receive a new NU report, especially if we refresh the cost at short intervals, such as every 10~20 seconds.
|
changes on #3387 |
Description
Describe the changes introduced by this PR and what does it affect
Changes
#3340
Related Issues
List of related issues
Documentation PR
For UI changes, Please provide the Documetation PR on info_grid
Checklist