Allow `GetAccount` endpoint to return all storage map entries

[JereSalo]

co-authored by @TomasArrachea

Currently, the GetAccountRequest takes a StorageMapDetailRequest parameter that lets the client declare which storage maps they want to request. The problem with this is that we cannot request the whole storage map entries at once, so the client currently needs two requests in total to get them: the first one to discover the storage map slots, and the second one to get the contents. Ideally we'd perform only one request to get all data at once in case of small accounts (for large accounts we'd still need a second request in case a storage map has "too many entries").

We could add a new boolean parameter (e.g. include_all_maps or all_maps) to the request so all the storage map entries are included in the response. It would not need to return the inclusion proof. If any of the maps return too_many_entries, the client would then follow up with the sync_storage_maps flow for slots that exceed the limit.

There are many alternatives for the implementation but we think that the best one may be to make it impossible for the user to set both all_maps flag and the existing storage_maps at the same time, so we make the intent clear.

[bobbinth]

I think this is a good idea, and I guess the way it could look like is something like this:

Instead of repeated StorageMapDetailRequest storage_maps = 3, we'd have something like:

message AccountDetailRequest {
    optional primitives.Digest code_commitment = 1;
    optional primitives.Digest asset_vault_commitment = 2;
    oneof slot_data {
        bool all_storage_maps = 3;
        repeated StorageMapDetailRequest storage_maps = 4;
    }
}

One thing we should make sure is that we don't go over the response size limit. I believe the current limits are that each map response could contain up to 1000 entries, and since we could in theory have up to 256 maps in an account, just this part would be close to 16 MB. One option to limit the maximum number of storage maps in an account to under 64 (which may be a good idea regardless - cc @PhilippGackstatter).

Another related idea is that maybe instead of returning just the too_many_entries boolean value, we should be returning the number of entries in a given map (and this would apply to the asset vault as well).

cc @Mirko-von-Leipzig as this change would be a breaking API change.

[Dev-Solace]

Hi, I’d like to take this if it is still available.

My understanding is that GetAccount currently forces clients to first discover storage map slots, then make a second request to fetch the entries. I’d keep the first PR focused on the request/response path: add a mutually exclusive “all storage maps” mode, most likely using the oneof slot_data shape suggested above, update validation so callers cannot request both explicit maps and all maps, and keep the response bounded by the existing entry/payload limits.

Before opening a PR, I’d like to confirm the intended limit behavior: should this first pass only add the all_storage_maps request mode using the current per-map too_many_entries handling, or should it also include the related entry-count / max-map-limit change?

If that scope sounds right, could I be assigned?