Please note that some commits may be excluded from this release if they’re not relevant, or not modifying the GuestOS image. Additionally, descriptions of some changes might have been slightly modified to fit the release notes format.
To see a full list of commits added since last release, compare the revisions on GitHub.
The two SHA256 sums printed above from a) the downloaded CDN image and b) the locally built image, must be identical, and must match the SHA256 from the payload of the NNS proposal.
Please note that some commits may be excluded from this release if they’re not relevant, or not modifying the GuestOS image. Additionally, descriptions of some changes might have been slightly modified to fit the release notes format.
To see a full list of commits added since last release, compare the revisions on GitHub.
The two SHA256 sums printed above from a) the downloaded CDN image and b) the locally built image, must be identical, and must match the SHA256 from the payload of the NNS proposal.
Hi @Lorimer,
Thank you for analyzing the code changes in the proposal!
Indeed, the fix should be backwards compatible. If a snapshot happened to work before just because it did not mutate globals, then it will still work. Otherwise, the snapshot was already broken and should not be restored. This PR solves this issue, however, only for new snapshots taken after the fix.
A good way to analyze whether a snaphot was affected is to look at the Wasm binary code and check for the presence of global.set.
Please note that some commits may be excluded from this release if they’re not relevant, or not modifying the GuestOS image. Additionally, descriptions of some changes might have been slightly modified to fit the release notes format.
To see a full list of commits added since last release, compare the revisions on GitHub.
Other changes:
3318f7461 Interface,Networking: fix: revert the old error string when outcall response is bigger than the limit
The two SHA256 sums printed above from a) the downloaded CDN image and b) the locally built image, must be identical, and must match the SHA256 from the payload of the NNS proposal.
Please note that some commits may be excluded from this release if they’re not relevant, or not modifying the GuestOS image. Additionally, descriptions of some changes might have been slightly modified to fit the release notes format.
To see a full list of commits added since last release, compare the revisions on GitHub.
Other changes:
290fd2ae9 Interface,Networking: fix: revert the old error string when outcall response is bigger than the limit
The two SHA256 sums printed above from a) the downloaded CDN image and b) the locally built image, must be identical, and must match the SHA256 from the payload of the NNS proposal.
There’s very little information provided with this ‘hotfix’,
What’s the issue?
How does this hotfix fix it?
Which commit does this revert? The commit message is ‘revert’ (that’s it )
fix: revert the old error string when outcall response is bigger than the limit’
The commit summary ^ in the release notes indicates that the fix is to change the error string… There’s a dependency on the exact contents of this string somewhere? Really?
This commit has numerous other changes such as changing dependency versions
@DRE-Team Please could someone from DFINITY provide some clarity? Thanks.
In the meantime, the only information I have is:
The HTTP outcalls after this particular commit started returning a different error message (as a string), in case the canister-provided message limit is too small for the actually returned data. Some canisters, including ckETH were relying on the actual string value of the error message to understand that the provided message limit is too small, and then they would bump up the response message size limit and retry. Ugly hack around the API to keep the costs of http outcalls small. The http outcalls price goes up a lot if they immediately provide the max message size limit, so they opt for this iterative approach, even though it’s an ugly hack.
The issue is that this breaks conversions for ckETH, EVM RPC and likely multiple community projects. So the safest thing is to roll back the change.
Thanks @sat and @tim1 for the quick responses. Sorry for my delay, I’m just catching up on this over my lunch break.
All makes sense, thanks for elaborating. It would be good if commit messages (particularly for important commits like this) could be more descriptive in the future.
As a side note, this sounds like a bug in various canisters, as opposed to a bug in the recent IC OS releases (but I understand the need for a quick resolution). Are there going to be steps taken to address this type of issue, so that error messages can be safely adjusted in the future without fear of breaking systems that have taken a hacky dependency?
It would be good if commit messages could be more descriptive in the future.
I agree we need to improve this!
This sounds like a bug in various canisters
Yes relying on error strings, that are intended for humans, is very fragile. But the fact that people rely on this points to an issue in the current HTTPS outcalls API, specifically that the current API makes it very hard to pay only for what you use (you need to specify the expected response size in advance with max_response_bytes). As a follow-up, we will revisit the API and see how to improve it so that people don’t need to do hacky workarounds anymore.
)