chore(canister_logging): update charging cycles tests#9785
chore(canister_logging): update charging cycles tests#9785
Conversation
maksymar
changed the title
| // Memory at install time (~12_510 bytes with log, ~222 bytes without): | ||
| // 134 bytes canister history | ||
| // + 12_288 bytes log memory store (4 KiB header + 4 KiB index + 4 KiB data) | ||
| // + 88 bytes other system state overhead |
There was a problem hiding this comment.
Out of curiosity: do you know what an empty canister has beyond canister history and logs?
There was a problem hiding this comment.
I suppose that should be it.
There was a problem hiding this comment.
but then what are these 88 bytes?
| migrated_canister, | ||
| if LOG_MEMORY_STORE_FEATURE_ENABLED { | ||
| 9_200_000 | ||
| 11_200_000 |
There was a problem hiding this comment.
How was this derived? Just experimentally?
There was a problem hiding this comment.
yes, just experimentally
There was a problem hiding this comment.
Maybe we could use the same "trick" as I suggested before (raise the freezing threshold) so that we don't need to compute the number of cycles so precisely. But that's beyond the scope of this PR so I don't insist on doing it right now.
Co-authored-by: mraszyk <31483726+mraszyk@users.noreply.github.com>
| // the test. It needs to be _just_ enough to allow for the canister | ||
| // to be installed (the canister is created with the provisional | ||
| // create canister api that doesn't require additional cycles). | ||
| // The amount of cycles must be just enough for `install_code` to |
There was a problem hiding this comment.
Why "just enough"? It seems like this test only cares about the canister being frozen which can be achieved by setting the freezing threshold to a very high value (u64::MAX / 2 or whatever the system still allows) without computing the initial cycles balance so precisely.
2 participants
This PR updates charging cycles tests due to the recent change in pricing.
#9752