A server that accepts and never answers holds a scan for 30 s #230
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
matthew-garrett (mjg59.dreamwidth.org) has failed all 42 tries in 7 days, timeouts and 504s; its server takes the connection and sends nothing, so each fetch runs the full 30 s FEED_TIMEOUT and most of the scans it is in last 30-40 s instead of 5 (e.g. 326c4db4818e396c6d2e252765996eec). No successful fetch has taken over 8 s since body sizes were recorded. A limit on silence (no byte for 15 s) would give up sooner without cutting off a slow feed that is still sending. The directory's client has no connect timeout either.
Fixed in
8d7a30d, deployed (ipx and ipx-directory 1.1.1-dev). Both feed clients give up after 15 s of silence (feed::FEED_SILENCE, reqwest read_timeout); FEED_TIMEOUT stays 30 s for a feed still sending. The directory's client also has ipx's 10 s connect timeout.