GitLab

Currently download status scheduled as generic (DL_SCHED_GENERIC = 0);

/** Download status for the current consensus networkstatus. */
static download_status_t consensus_dl_status[N_CONSENSUS_FLAVORS];

Before implementing of consensus for md it was DL_SCHED_CONSENSUS:

static download_status_t consensus_dl_status = { 0, 0, DL_SCHED_CONSENSUS };

That means unfriendly schedule for client with fragile network connection.

/** Schedule for when clients should download things in general. */
static const int client_dl_schedule[] = {
  0, 0, 60, 60*5, 60*10, INT_MAX
};

vs.

/** Schedule for when clients should download consensuses. */
static const int client_consensus_dl_schedule[] = {
  0, 0, 60, 60*5, 60*10, 60*30, 60*60, 60*60, 60*60, 60*60*3, 60*60*6, 60*60*12
};

Tor will reset download status by networkstatus_reset_download_failures once a hour so client will have a chance to retry, so no unresolved state actually.

Is it worth to initialize download status for consensus schedule? Or to rename schedule if planned to use it for certs only?