Skip to content

GitLab

  • Menu
Projects Groups Snippets
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
  • Trac Trac
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Issues 246
    • Issues 246
    • List
    • Boards
    • Service Desk
    • Milestones
  • Monitor
    • Monitor
    • Metrics
    • Incidents
  • Analytics
    • Analytics
    • Value stream
  • Wiki
    • Wiki
  • Activity
  • Create a new issue
  • Issue Boards
Collapse sidebar
  • Legacy
  • TracTrac
  • Issues
  • #20593
Closed (moved) (moved)
Open
Created Nov 07, 2016 by Nick Mathewson@nickm🐛

Avoid resetting download status on 503

On comment:31:ticket:20499 , Teor notes:

If we really do want every failure to result in a schedule increment, we have to remove the following code:

download_status_increment_failure: {{{ /* only count the failure if it's permanent, or we're a server */ if (status_code != 503 || server) { if (dls->n_download_failures < IMPOSSIBLE_TO_DOWNLOAD-1) ++dls->n_download_failures; } }}}

Because combined with this code in download_status_schedule_get_delay, it causes a reset on every 503: {{{ /* Check if we missed a reset somehow */ if (dls->last_backoff_position > dls_schedule_position) { dls->last_backoff_position = 0; dls->last_delay_used = 0; } }}}

Which is exactly what we don't want when relays are busy - imagine clients doing an automatic reset every time they DoS a relay...

To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Assignee
Assign to
Time tracking