key manager: Is transition between GetStatuses and subscription to status atomic?

[pro-wh]

in the tendermint keymanager backend, we have a subscription with an initialization callback that reads all current statuses before starting a susbscription to change events. are these two phases, the one that reads current statuses and the one that relays status change events, done atomically so that they can't miss an update or duplicate an update?

Details

encountered in go/keymanager/tendermint/tendermint.go

from internal key manager audit

Acceptance Criteria

• either we know it's atomic already or we make it atomic. or we determine that it's not a concern

[Yawning]

It's not, but missing/duplicated updates are harmless enough that this isn't an issue.

If an update is missed, the only thing that happens is the client needs to wait for the next status to be able to use the key manager.

[pro-wh]

ok kool