Calculate ingress_expiry_datetime closer to update call execution #125
Comments
mergify bot
pushed a commit
to dfinity/sdk
that referenced
this issue
Mar 12, 2021
…nister (#1482) Per the [design doc](https://github.com/dfinity/sdk/blob/master/docs/design/asset-canister.adoc): 1. Adds asset canister methods: - create_batch() - create_chunk() - commit_batch() - get() - get_chunk() 2. Reworks the asset installer in `dfx` to use these methods. It can therefore upload assets that exceed the message ingress size. Separate work (which this PR enables) will have to update `agent-js` to download these large assets. Other than allowing the storage and retrieval of large assets, this PR does not address: - multiple content types and content encodings: in this PR `dfx` always uploads with `content-type: application/octet-stream` and `content-encoding: identity` - smart/correct synchronization: in this PR `dfx` always uploads all assets (even those that have not changed), and still does not delete assets that were previously uploaded but no longer exist. - All assets and chunks are uploaded in series. See #1491 and dfinity/agent-rs#125 - The `store()`, `retrieve()`, and `list()` method signatures are unchanged for the time being, for backward compatibility. Later work will remove the `retrieve()` method, change the semantics and parameters of `store()`, and change the parameters and return type of `list()`. ``` Uploading assets to asset canister... large-asset.bin 1/7 (1900000 bytes) large-asset.bin 2/7 (1900000 bytes) large-asset.bin 3/7 (1900000 bytes) large-asset.bin 4/7 (1900000 bytes) large-asset.bin 5/7 (1900000 bytes) large-asset.bin 6/7 (1900000 bytes) large-asset.bin 7/7 (1100000 bytes) index.js 1/1 (1218 bytes) sample-asset.txt 1/1 (24 bytes) index.js.map 1/1 (5625 bytes) ```
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
The
UpdateBuilder::expire_aftermethod setsingress_expiry_datetimeto SystemTime::now() plus a duration offset. https://github.com/dfinity/agent-rs/blob/next/ic-agent/src/agent/mod.rs#L524Typical usage is something like this:
This means there can be some delay in between when the absolute expiry is calculated and when the update is actually executed. This length of this delay would be directly related to the number of futures submitted.
It may be that there is no solution at this level, since there are just more
awaitcalls deeper in the call stack. Or it may be that moving the calculation intoupdate_raw()(to the point where we build the CallRequest) would in practice help in the case where a number ofagent.call_and_wait()futures are awaited all at once.The text was updated successfully, but these errors were encountered: