Intermittent BadStatusLine('Hello world!HTTP/1.1 200 OK\r\n') when executing test-suite

Bug #2053154 reported by Olivier Gayot
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
python-requests-unixsocket (Ubuntu)
Fix Released
Undecided
Dan Bungert

Bug Description

When executing the test suite, sometimes the following exception gets raised:

E requests.exceptions.ConnectionError: ('Connection aborted.', BadStatusLine('Hello world!HTTP/1.1 200 OK\r\n'))

This looks bad. According to the test definition, the string "Hello world!" is supposed to be the body of the HTTP response. And somehow it appears before the status line.

We noticed this issue after uploading 0.3.0-3ubuntu1 because the package FTBFS [1] (three times out three). So Launchpad builders seem very good at reproducing the issue (that said my PPA build was green). That being said, the issue seems unrelated to the patch included in 0.3.0-3ubuntu1.

I've been able to reproduce the exception without the patch, and also on a mantic system.

Steps to reproduce:

$ git ubuntu clone python-requests-unixsocket
$ cd python-requests-unixsocket
$ while python3 -m pytest requests_unixsocket/tests; do true; done

It can take many iterations until the issue occurs. At this point I don't know yet if the issue is specific to requests-unixsocket or if it is a src:requests bug instead (or maybe something else like python-waitress?).

[1] https://launchpadlibrarian.net/714333527/buildlog_ubuntu-noble-amd64.python-requests-unixsocket_0.3.0-3ubuntu1_BUILDING.txt.gz

Olivier Gayot (ogayot)
description: updated
tags: added: update-excuse
Revision history for this message
Dan Bungert (dbungert) wrote :
Revision history for this message
Dan Bungert (dbungert) wrote :

After debugging a bit, I speculate that what is happening the test send several requests to one socket, the HEAD request may not read the body (why would it?), then unread bytes (why does it return a body from a HEAD request?) look like an out-of-order write.

Revision history for this message
Olivier Gayot (ogayot) wrote (last edit ):

Great job finding out the root cause! I think your theory is right.

If the client picks up all the data (i.e., headers + body) in a single call to recv(2), I think the excess data is simply ignored by the library. On the other hand, if the call to recv only returns the headers, then the next call to recv will have the excess data prepended. It's SOCK_STREAM based so anything can happen depending on timing I guess :)

Note that this is also based on speculation.

Revision history for this message
Dan Bungert (dbungert) wrote :

Ok, I feel good enough about this to upload.

Changed in python-requests-unixsocket (Ubuntu):
assignee: nobody → Dan Bungert (dbungert)
status: New → In Progress
Dan Bungert (dbungert)
Changed in python-requests-unixsocket (Ubuntu):
status: In Progress → Fix Committed
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package python-requests-unixsocket - 0.3.0-3ubuntu2

---------------
python-requests-unixsocket (0.3.0-3ubuntu2) noble; urgency=medium

  * Fix test flakiness due to unread data (LP: #2053154)
    - d/p/0002-fix-HEAD-method-tests.patch

 -- Dan Bungert <email address hidden> Thu, 15 Feb 2024 00:53:56 -0700

Changed in python-requests-unixsocket (Ubuntu):
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.