Thanks for the detailed breakdown and reproductive steps!

The TLDR here is that the dns server shits its pants

Likely because the container for exposing the port is being created outside of the docker-compose setup

Seemingly it doesnt full crash, so doesnt restart.

Doing mw docker dc restart dps with the expose no longer running would restore DNS

I can change this behaviour across the board

Services will include something like this in their YML

ports:
  - "${MYSQL_PORT:-3306}${MYSQL_PORT:+:3306}"

So it the port is not defined, this results in an ephemeral port exposure https://docs.docker.com/get-started/docker-concepts/running-containers/publishing-ports/#publishing-to-ephemeral-ports

So out of the box this could do

mwcli-mwdd-default-mysql-1           mariadb:10.11                                                "/mwdd-custom/entryp…"    mysql           4 minutes ago    Up 4 minutes    0.0.0.0:32768->3306/tcp, [::]:32768->3306/tcp

If you did mw dev env set MYSQL_PORT 3306, and ran create again

You'd get

mwcli-mwdd-default-mysql-1           mariadb:10.11                                                "/mwdd-custom/entryp…"    mysql           19 seconds ago   Up 5 seconds    0.0.0.0:3306->3306/tcp, :::3306->3306/tcp

With this solution I dont see a way I can nicely / easily get rid of the services being exposed by default on some port.

With this solution, I would also deprecate the current expose command

addshore opened https://gitlab.wikimedia.org/repos/releng/cli/-/merge_requests/603

Added new exposure mode to some services

addshore merged https://gitlab.wikimedia.org/repos/releng/cli/-/merge_requests/603

Added new exposure mode to some services

eep, this seemed to have fudged up sitelinks and api testing for me.

$ mw dev mw exec -- curl --request GET --url 'http://default.mediawiki.mwdd.localhost:8080/w/rest.php/wikibase/v1/entities/items/Q1' --header 'Cookie: XDEBUG_SESSION=start' --header 'User-Agent: whatever' -vv
Note: Unnecessary use of -X or --request, GET is already inferred.
*   Trying 127.0.0.1:8080...
* connect to 127.0.0.1 port 8080 failed: Connection refused
*   Trying [::1]:8080...
* connect to ::1 port 8080 failed: Connection refused
* Failed to connect to default.mediawiki.mwdd.localhost port 8080 after 0 ms: Couldn't connect to server
* Closing connection 0
curl: (7) Failed to connect to default.mediawiki.mwdd.localhost port 8080 after 0 ms: Couldn't connect to server

Recreating and restarting the container(s) didn't work. However, rolling back to v0.26.1 did.

I can reproduce Itamar's issue as well.
I notice that the MediaWiki container image has changed to docker-registry.wikimedia.org/dev/bookworm-php83-fpm:1.0.0 in v0.27.1.
Using the previous MediaWiki image solves the issue mw dev env set MEDIAWIKI_IMAGE docker-registry.wikimedia.org/dev/buster-php81-fpm:1.0.1-s2.

I also notice that using default.mediawiki.mwdd instead of default.mediawiki.mwdd.localhost also works:

$ mw dev mw exec -- curl --request GET --url 'http://default.mediawiki.mwdd:8080/w/rest.php/wikibase/v1/entities/items/Q1' --header 'Cookie: XDEBUG_SESSION=start' --header 'User-Agent: whatever'; echo;
{"type":"item","labels":{},"descriptions":{},"aliases":{"en":["first english alias","next english alias","en alias 1","en alias 2","en alias 3"],"fr":["first french alias","fr-alias"],"de":["first new alias","second new alias"]},"statements":{},"sitelinks":{},"id":"Q1"}

I wonder if it is related to this change in curl that landed in 7.85.0: https://github.com/curl/curl/issues/11104.
The version of curl has changed from 7.64.0 in buster-php81-fpm:1.0.1-s2 to 7.88.1 in bookworm-php83-fpm:1.0.0.

Right, might be worth rolling back to the 81 image by default then until the issue is figured out in more detail.
And would be great to come up with one or more test cases for the CI for these situations too :) (basically for the DNS resolution in different cases)

Looks like the more up-to-date ticket there is https://github.com/curl/curl/issues/15628

Looks like curl/libcurl won't fix it, despite it being a massive change in compatibility for many users (including us).

mwcli and mwdd used to use a different suffix for hosts, but .localhost was chosen due to the simplicity of working both inside and outside the containers
https://github.com/addshore/mediawiki-docker-dev/commit/f5819fa24e0b27d1e46e8dae78f57fd552afe84b
TLDR; a user doesnt need to setup any DNS to resolve the stuff, and it also works out of the box with no internet connection for most browsers.

The first change was https://github.com/addshore/mediawiki-docker-dev/issues/5 "Multiple wikis with wildcard domains #5"
The second change was https://github.com/addshore/mediawiki-docker-dev/issues/17 "Switch from wmftest.net to *.localhost #17"
CCing @Krinkle as they were involved in some of the thinking back then :)

So, in summary

• This is an issue with the curl CLI tool and libcurl (and maybe others depending on how they read the spec) using *.localhost to resolve to non loopback ips
• Having to use different hosts for different tools / inside and outside containers is annoying
• Having to configure custom DNS on the host machine of mwcli is also annoying

Happy to hear ideas for the best longer term path forward. :)

As this issue is unrelated to the expose sub-command, and this ticket is resolved, I've created T388411: libcurl 7.85+ breaks DNS in mwcli