Stopping container with dependencies leads to no such service: dependent-service (2.3.1 regression)

[nocive]

Description

Attempting to stop a running container with dependencies leads to a no such service: dependent-service error.
Repeating the same will yield back different dependent service names.

This broke in 2.3.1 and worked fine before.

Steps to reproduce the issue:

1. docker compose stop some-container

Describe the results you received:
no such service: dependent-service

Describe the results you expected:
Stopping the container successfully.

Additional information you deem important (e.g. issue happens only occasionally):

Output of docker compose version:

Docker Compose version v2.3.1

Output of docker info:

Client:
 Context:    default
 Debug Mode: false
 Plugins:
  buildx: Build with BuildKit (Docker Inc., v0.6.1-docker)
  compose: Docker Compose (Docker Inc., v2.2.3)

Server:
 Containers: 82
  Running: 48
  Paused: 0
  Stopped: 34
 Images: 181
 Server Version: 20.10.11
 Storage Driver: overlay2
  Backing Filesystem: extfs
  Supports d_type: true
  Native Overlay Diff: false
  userxattr: false
 Logging Driver: json-file
 Cgroup Driver: systemd
 Cgroup Version: 2
 Plugins:
  Volume: local
  Network: bridge host ipvlan macvlan null overlay
  Log: awslogs fluentd gcplogs gelf journald json-file local logentries splunk syslog
 Swarm: inactive
 Runtimes: io.containerd.runc.v2 io.containerd.runtime.v1.linux runc
 Default Runtime: runc
 Init Binary: docker-init
 containerd version: 1e5ef943eb76627a6d3b6de8cd1ef6537f393a71.m
 runc version: v1.0.3-0-gf46b6ba2
 init version: de40ad0
 Security Options:
  seccomp
   Profile: default
  cgroupns
 Kernel Version: 5.15.7-arch1-1
 Operating System: Antergos Linux
 OSType: linux
 Architecture: x86_64
 CPUs: 4
 Total Memory: 15.49GiB
 Name: jps-x1
 ID: TX6D:ALDF:OGX5:HVBY:YJNY:FLH2:GRJI:I52W:V3K3:L6ZT:S2YY:23UM
 Docker Root Dir: /var/lib/docker
 Debug Mode: false
 Username: nocive
 Registry: https://index.docker.io/v1/
 Labels:
 Experimental: true
 Insecure Registries:
  127.0.0.0/8
 Live Restore Enabled: false

Additional environment details:

[jerryen]

Unfortunately this doesn’t seem to be fixed on 2.3.2 and also happens on 2.3.0.

Output of docker info:

Client:
 Context:    default
 Debug Mode: false
 Plugins:
  buildx: Docker Buildx (Docker Inc., v0.7.1-docker)
  compose: Docker Compose (Docker Inc., 2.3.2)

Server:
 Containers: 12
  Running: 12
  Paused: 0
  Stopped: 0
 Images: 53
 Server Version: 20.10.12
 Storage Driver: overlay2
  Backing Filesystem: xfs
  Supports d_type: true
  Native Overlay Diff: false
  userxattr: false
 Logging Driver: json-file
 Cgroup Driver: systemd
 Cgroup Version: 2
 Plugins:
  Volume: local
  Network: bridge host ipvlan macvlan null overlay
  Log: awslogs fluentd gcplogs gelf journald json-file local logentries splunk syslog
 Swarm: inactive
 Runtimes: runc io.containerd.runc.v2 io.containerd.runtime.v1.linux
 Default Runtime: runc
 Init Binary: docker-init
 containerd version: 10f428dac7cec44c864e1b830a4623af27a9fc70.m
 runc version: v1.1.0-0-g067aaf85
 init version: de40ad0
 Security Options:
  seccomp
   Profile: default
  cgroupns
 Kernel Version: 5.16.13-arch1-1
 Operating System: Arch Linux
 OSType: linux
 Architecture: x86_64
 CPUs: 12
 Total Memory: 62.63GiB
 Name: arch
 ID: PVN4:JYSW:NCJD:XHRZ:CNVH:KXRH:N7XL:WFSV:NCAQ:IRSJ:JGU5:3CQC
 Docker Root Dir: /home/docker
 Debug Mode: false
 Registry: https://index.docker.io/v1/
 Labels:
 Experimental: false
 Insecure Registries:
  127.0.0.0/8
 Live Restore Enabled: false

[ndeloof]

Oh f***. I forgot to push a commit on my PR :'(
cc @glours

[nocive]

Behavior still changed when compared to previous versions.
Attempting to rm a container that is not running gives back an error where previously that was not the case.