Re: Got "fact submission failed: first byte timeout", but still report got posted; why?
[email protected] (Doug Bell) Fri, 3 Jul 2026 11:03:10 -0500
| Newsgroups | perl.cpan.testers.discuss |
|---|---|
| Message-ID | <[email protected]> |
--Apple-Mail=_CE2F01C7-F651-4B6C-ABF6-3DF7598708D6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Jun 30, 2026, at 6:53=E2=80=AFAM, James E Keenan = <[email protected]> wrote: >=20 > On 6/28/26 01:50, Slaven Rezic wrote: >> 25. 06. 2026. u 04:01, James Keenan pi=C5=A1e: >>> As stated above, I have always assumed that if I get error output = beginning with "fact submission failed: first byte timeout", the report = for that particular distro did not get transmitted and is utterly lost. = Has the behavior of the metabase changed? Or was my assumption wrong = from the start? >> Hi James, >> yes, I observed this problem, and Andreas also told me about it. What = probably goes wrong: the reverse proxy in front of the system (still = fastly?) has a lower timeout than the processing backends. So while the = backend are still happily trying to write the report to the database = (and eventually might be successful, or not) the reverse proxy gives up = and send the "first byte timeout" response. >> Regards, >> Slaven >=20 > Problem persists today. If you go to = http://fast2-matrix.cpantesters.org/?dist=3DAlgorithm-Heapify-XS;perl=3D5.= 44.0;reports=3D1, you see 2 reports I submitted dated 2026-06-30 11:40, = one from FreeBSD, one from Linux. In my terminal both runs appeared to = fail with "fact submission failed" error messages. >=20 > This is likely to be very confusing to people who only submit = CPANtesters reports infrequently. Is it being tracked in a bug ticket? = If so, where? We are still using Fastly, yes. I've updated the first byte timeout for = the metabase.cpantesters.org <http://metabase.cpantesters.org/> (which = is where all fact submissions currently go) from 15s (the default) to = 60s, which Fastly says is the maximum without doing some additional = configuration that affects cachability (though this is a POST request, = so that's probably not relevant really). The better long-term solution is likely going to be making reporters = submit directly to the collector, which does less and so is faster, but = that's gonna take some effort. Doug Bell [email protected] --Apple-Mail=_CE2F01C7-F651-4B6C-ABF6-3DF7598708D6 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 <html aria-label=3D"message body"><head><meta http-equiv=3D"content-type" = content=3D"text/html; charset=3Dutf-8"></head><body = style=3D"overflow-wrap: break-word; -webkit-nbsp-mode: space; = line-break: after-white-space;"><div><blockquote type=3D"cite"><div>On = Jun 30, 2026, at 6:53=E2=80=AFAM, James E Keenan = <[email protected]> wrote:</div><br = class=3D"Apple-interchange-newline"><div><div>On 6/28/26 01:50, Slaven = Rezic wrote:<br><blockquote type=3D"cite">25. 06. 2026. u 04:01, James = Keenan pi=C5=A1e:<br><blockquote type=3D"cite">As stated above, I have = always assumed that if I get error output beginning with "fact = submission failed: first byte timeout", the report for that particular = distro did not get transmitted and is utterly lost. Has the = behavior of the metabase changed? Or was my assumption wrong from = the start?<br></blockquote>Hi James,<br>yes, I observed this problem, = and Andreas also told me about it. What probably goes wrong: the reverse = proxy in front of the system (still fastly?) has a lower timeout than = the processing backends. So while the backend are still happily trying = to write the report to the database (and eventually might be successful, = or not) the reverse proxy gives up and send the "first byte timeout" = response.<br>Regards,<br> = Slaven<br></blockquote><br>Problem persists today. If you go to = http://fast2-matrix.cpantesters.org/?dist=3DAlgorithm-Heapify-XS;perl=3D5.= 44.0;reports=3D1, you see 2 reports I submitted dated 2026-06-30 11:40, = one from FreeBSD, one from Linux. In my terminal both runs = appeared to fail with "fact submission failed" error = messages.<br><br>This is likely to be very confusing to people who only = submit CPANtesters reports infrequently. Is it being tracked in a = bug ticket? If so, where?</div></div></blockquote><br></div><div>We are = still using Fastly, yes. I've updated the first byte timeout for the <a = href=3D"http://metabase.cpantesters.org">metabase.cpantesters.org</a> = ;(which is where all fact submissions currently go) from 15s (the = default) to 60s, which Fastly says is the maximum without doing some = additional configuration that affects cachability (though this is a POST = request, so that's probably not relevant = really).</div><div><br></div><div>The better long-term solution is = likely going to be making reporters submit directly to the collector, = which does less and so is faster, but that's gonna take some = effort.</div><div><br></div><div><br></div><div><br></div><div><div><div>D= oug Bell<br>[email protected]<br></div></div><div><blockquote = type=3D"cite"></blockquote></div></div></body></html>= --Apple-Mail=_CE2F01C7-F651-4B6C-ABF6-3DF7598708D6--