[tor-dev] DirAuth usage and 503 try again later

[James]

Good day.

Is there any chance that torpy (https://github.com/torpyorg/torpy) was 
triggered this issue 
https://gitlab.torproject.org/tpo/core/tor/-/issues/33018 ?

Some wary facts:
- Torpy using old fashion consensus (not mircodesc)
- When consensus not present in cache (first time usage) it downloads 
consensus from random directory authorities only.
- Before August 2020 it was using plain HTTP requests to DirAuths. Now 
it creates "CREATE_FAST" circuits to DirAuths (is that right way by the 
way?)

 From other side:
- Torpy store consensus on disk (so whenever client restart it must not 
download full consensus again)
- It will try download consensus after time which sets by valid_time 
field from consensus which more than 1 hour (so it's not so often)
- Torpy try get consensus by "diff" feature (so it's minimize traffic)

Still may be some of this features not working well in some conditions. 
Which could cause a lot of consensus downloads in Jan 2020... Or may be 
you know more info about this situation?



Do you have some recommendations for tor client implementation?
Can you explain in several paragraphs what behavior of original tor 
client is? As far as I understand when first time original tor starts it 
tries download consensus from fallback dirs not from DA? Is this key point?

There is one more issue 
https://gitlab.torproject.org/tpo/core/tor/-/issues/40239
which I'm not understand correctly. Let's imagine it's first run of tor 
client and that time coincidentally coincided with DA voting. That means 
client will not be able to download consensus? That is strange decision. 
Or do you mean clients must download consensus from fallback dirs which 
never in "voting" process?