Highlights:
Deduplication of getProgramAccounts requests. When gPA request is made, cacherpc will "remember" it as being in progress. If the same gPA request is made again before the first one had a chance to complete, the second one (and all those that come after) will wait for the original to finish, after this event they will respond from cache. getProgramAccounts request is defined by three values: public key, commitment level and set of filters, and other parameters like encoding and dataSlice are ignored. All subsequent requests will wait a limited amount of time before returning timeout error to the user, this timeout parameter can be separately configured via in_progress_request_wait: u64 field of [rpc.timeouts] sections of configuration file. In case if error occurs during the execution of original request, no waiters will be notified, the cacherpc will "forget" the request as being in progress, all current waiters will eventually abort with timeout, single new request will be forwarded to validator. Not all gPA requests can be subjected to this new logic, specifically if the gPA is not cacheable, then cacherpc will not remember it as being in progress, cacheability is satisfied if: encoding is not jsonParsed, no dataSlice is requested, cacherpc has active websocket connection.
What's Changed
- feat: wait for exectuting gpa requests, instead of making new ones by @bobs4462 in #261
Full Changelog: 0.2.16...0.2.17