debusine.worker problems if hostname for api-url can be resolved using ipv6 but server is only available on ipv4

Situation: Debusine server (via nginx or runserver) binds (or reachable) on ipv4 only, but the api-url hostname on debusine.worker can be resolved using ipv4 and ipv6.

This is the case on my development machine:

carles@pinux:~$ grep -i localhost /etc/hosts
127.0.0.1	localhost pinux
::1     localhost ip6-localhost ip6-loopback

ping 127.0.0.1 and ping ::1 work as expected.

Using the "manage.py runserver", by default, binds only ipv4 but not ipv6.

When using debusine.worker there is a mixture of systems used for the HTTP communication. Some are from requests library (e.g. uploading artifacts), some come from asyncio/aiohttp (via debusine_async_http_client.py).

What I'm seeing if using debusine.worker with log-level = DEBUG:

2023-08-30 15:55:00,433 Using selector: EpollSelector
2023-08-30 15:55:00,543 Connected to http://localhost:8011/api
2023-08-30 15:55:00,589 Received from the server: '{'type': 'websocket.send', 'text': 'request_dynamic_metadata'}'
2023-08-30 15:55:00,597 HTTP PUT to the server: URL: http://localhost:8011/api/1.0/worker/dynamic-metadata/ args: () kwargs: {'json': {'system:cpu_count': 4, 'system:total_physical_memory': 12218363904, 'noop:version': 1, 'sbuild:version': 1, 'sbuild:chroots': ['stable-amd64', 'unstable-amd64'], 'sbuild:host_architecture': 'amd64'}}
2023-08-30 15:55:00,661 Sent dynamic_metadata (response: 204) Dynamic metadata: {'system:cpu_count': 4, 'system:total_physical_memory': 12218363904, 'noop:version': 1, 'sbuild:version': 1, 'sbuild:chroots': ['stable-amd64', 'unstable-amd64'], 'sbuild:host_architecture': 'amd64'}
2023-08-30 15:55:00,661 Received from the server: '{'type': 'websocket.send', 'text': 'work_request_available'}'
2023-08-30 15:55:00,662 HTTP GET to the server: URL: http://localhost:8011/api/1.0/work-request/get-next-for-worker/ args: () kwargs: {}
2023-08-30 15:55:00,756 Executing: sbuild --no-clean --arch-any --arch-all --no-source --dist=stable --arch=amd64 http://deb.debian.org/debian/pool/main/h/hello-traditional/hello-traditional_2.10-6.dsc
2023-08-30 15:55:27,121 Starting new HTTP connection (1): localhost:8011
2023-08-30 15:55:27,220 http://localhost:8011 "POST /api/1.0/artifact/ HTTP/1.1" 201 524
2023-08-30 15:55:27,375 Starting new HTTP connection (1): localhost:8011
2023-08-30 15:55:27,413 http://localhost:8011 "PUT /api/1.0/artifact/213/files/hello-traditional_2.10-6_amd64-2023-08-30T13%3A55%3A02Z.build/ HTTP/1.1" 206 0
2023-08-30 15:55:27,424 Starting new HTTP connection (1): localhost:8011
2023-08-30 15:55:27,493 http://localhost:8011 "PUT /api/1.0/artifact/213/files/hello-traditional_2.10-6_amd64-2023-08-30T13%3A55%3A02Z.build/ HTTP/1.1" 201 0
2023-08-30 15:55:27,558 http://localhost:8011 "POST /api/1.0/artifact/ HTTP/1.1" 201 512
2023-08-30 15:55:27,658 http://localhost:8011 "POST /api/1.0/artifact/ HTTP/1.1" 201 2488
2023-08-30 15:55:27,664 Starting new HTTP connection (1): localhost:8011
2023-08-30 15:55:27,703 http://localhost:8011 "PUT /api/1.0/artifact/215/files/hello-traditional_2.10-6_amd64.buildinfo/ HTTP/1.1" 206 0
2023-08-30 15:55:27,710 Starting new HTTP connection (1): localhost:8011
2023-08-30 15:55:27,789 http://localhost:8011 "PUT /api/1.0/artifact/215/files/hello-traditional_2.10-6_amd64.buildinfo/ HTTP/1.1" 201 0
2023-08-30 15:55:27,798 Starting new HTTP connection (1): localhost:8011
2023-08-30 15:55:27,833 http://localhost:8011 "PUT /api/1.0/artifact/215/files/hello-traditional_2.10-6_amd64.changes/ HTTP/1.1" 206 0
2023-08-30 15:55:27,840 Starting new HTTP connection (1): localhost:8011
2023-08-30 15:55:27,909 http://localhost:8011 "PUT /api/1.0/artifact/215/files/hello-traditional_2.10-6_amd64.changes/ HTTP/1.1" 201 0
2023-08-30 15:55:27,953 http://localhost:8011 "POST /api/1.0/artifact-relation/ HTTP/1.1" 201 58
2023-08-30 15:55:27,990 http://localhost:8011 "POST /api/1.0/artifact-relation/ HTTP/1.1" 201 55
2023-08-30 15:55:28,026 http://localhost:8011 "POST /api/1.0/artifact-relation/ HTTP/1.1" 201 58
2023-08-30 15:55:28,088 http://localhost:8011 "POST /api/1.0/artifact/ HTTP/1.1" 201 395
2023-08-30 15:55:28,093 Starting new HTTP connection (1): localhost:8011
2023-08-30 15:55:28,127 http://localhost:8011 "PUT /api/1.0/artifact/216/files/cmd-output.log/ HTTP/1.1" 206 0
2023-08-30 15:55:28,134 Starting new HTTP connection (1): localhost:8011
2023-08-30 15:55:28,198 http://localhost:8011 "PUT /api/1.0/artifact/216/files/cmd-output.log/ HTTP/1.1" 201 0
2023-08-30 15:55:28,200 HTTP PUT to the server: URL: http://localhost:8011/api/1.0/work-request/8/completed/ args: () kwargs: {'json': {'result': 'success'}}
2023-08-30 15:55:28,203 Future exception was never retrieved
future: <Future finished exception=OSError(9, 'Bad file descriptor')>
Traceback (most recent call last):
  File "/usr/lib/python3.11/asyncio/selector_events.py", line 671, in _sock_connect_cb
    err = sock.getsockopt(socket.SOL_SOCKET, socket.SO_ERROR)
          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
OSError: [Errno 9] Bad file descriptor

The interesting part is the last exception. The "HTTP PUT to the server: URL: http://localhost:8011/api/1.0/work-request/8/completed/ args: () kwargs: {'json': {'result': 'success'}}" does not hit the server. debusine.worker fails before it.

The "OSError: Bad file descriptor" seems to be happening because, in this request, it's trying to connect to "localhost" using ipv6 (seen ::1 in aiohttp internals).

Editing /etc/hosts and removing ::1 localhost ip6-localhost ip6-loopback fixes the problem (forcing it to use ipv4). Using api-url = 127.0.0.1 (instead of localhost) in config.ini also fixes the problem.

This issue is so that be aware of the problem and perhaps improve the reporting of the problem, or as another issue says: stop using debusine_async_http_client for GET/PUT/POST and just use requests (but the same could still happen for the aiohttp.ClientSession.ws_connect).

Why is only this request failing and not the previous "GET" or the connect: I haven't investigated it yet.