Thanks for the clarification! I did mean the ordering of response delivery compared to when the responses are produced, not when the requests are received. It’s good to know that the ordering isn’t guaranteed. In practice, is there any such scenario except for subnet splitting?
Thanks. Good to know that we are on the same page.
IMHO, there can be other ways to recover from an unresponsive NNS Governance. For example, you can save the neuron ids from the responses, while having a recon task (running much less frequently) to look for neuron ids that you don’t know about. This way the cost is minimized most of the time, while being able to recover from extreme conditions. Of course, this is assuming listing neurons by subaccounts is not available yet.
1 Like
I don’t think so. But I wouldn’t rely on that always being the case. The protocol specification (implicitly) allows the implementation to reorder responses in any way it wants (e.g. for efficiency or fairness purposes). So we may well end up doing that at some point.
Does this mean it might be coming 
What about these cases where a request could fail to be delivered. Do any of these apply to your situation @dfxjesse? 
Simply wrapping all asynchronous calls in try/catch should cover request failures.
1 Like