[BUG] command `exec` of compose v2 cant recognize running service

[Agosits]

Description

$ docker compose exec web bash
=> service "web" is not running container #1
$ docker compose ps | grep web
foo-web-1 foo-web "cmd foo" web 21 hours ago Up 6 hours 127.0.0.1:xxxx->80/tcp

But docker-compose-v1 exec web bash works well.
I was work on macOS 13.0.1 (22A400) with chip Apple M1 Pro

Steps To Reproduce

No response

Compose Version

Docker Compose version v2.15.1

Docker Environment

Client:
 Context: default
 Debug Mode: false
 Plugins:
 buildx: Docker Buildx (Docker Inc., v0.10.3)
 compose: Docker Compose (Docker Inc., v2.15.1)
 dev: Docker Dev Environments (Docker Inc., v0.1.0)
 extension: Manages Docker extensions (Docker Inc., v0.2.18)
 sbom: View the packaged-based Software Bill Of Materials (SBOM) for an image (Anchore Inc., 0.6.0)
 scan: Docker Scan (Docker Inc., v0.25.0)
 scout: Command line tool for Docker Scout (Docker Inc., v0.6.0)

Server:
 Containers: 7
 Running: 4
 Paused: 0
 Stopped: 3
 Images: 6
 Server Version: 20.10.23
 Storage Driver: overlay2
 Backing Filesystem: extfs
 Supports d_type: true
 Native Overlay Diff: true
 userxattr: false
 Logging Driver: json-file
 Cgroup Driver: cgroupfs
 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: 2456e983eb9e37e47538f59ea18f2043c9a73640
 runc version: v1.1.4-0-g5fd4c4d
 init version: de40ad0
 Security Options:
 seccomp
 Profile: default
 cgroupns
 Kernel Version: 5.15.49-linuxkit
 Operating System: Docker Desktop
 OSType: linux
 Architecture: aarch64
 CPUs: 5
 Total Memory: 7.667GiB
 Name: docker-desktop
 ID: FQCN:UYJB:BTTZ:3G5V:WCTB:PGV2:BYCF:IT67:JOEH:EFQC:XCSS:3IIR
 Docker Root Dir: /var/lib/docker
 Debug Mode: false
 HTTP Proxy: http.docker.internal:3128
 HTTPS Proxy: http.docker.internal:3128
 No Proxy: hubproxy.docker.internal
 Registry: https://index.docker.io/v1/
 Labels:
 Experimental: false
 Insecure Registries:
 hubproxy.docker.internal:5000
 127.0.0.0/8
 Live Restore Enabled: false

Anything else?

No response

[ndeloof]

please run docker compose inspect foo-web-1 foo-web -f '{{.Config.Labels}}' to check container labels.

[Agosits]

please run docker compose inspect foo-web-1 foo-web -f '{{.Config.Labels}}' to check container labels.

It seems there no command docker compose inspect
Do you mean docker inspect?
Here are the results of docker inspect foo-web-1 foo-web -f '{{.Config.Labels}}'

map[com.docker.compose.config-hash:4ef3ed229dd80dafa13ce60de8ff42c3663bc1645050457611867b3f6585f0fc com.docker.compose.container-number:1 com.docker.compose.depends_on:redis:service_started,mysql:service_started com.docker.compose.image:sha256:35d87234a5e4e34a1cacd766bf2731a437c18bcb8aa206cb3d3aa27971655b10 com.docker.compose.oneoff:False com.docker.compose.project:foo com.docker.compose.project.config_files:/path/to/foo/docker-compose.yml com.docker.compose.project.working_dir:/path/to/dir com.docker.compose.service:web com.docker.compose.version:2.15.1]
map[com.docker.compose.project:foo com.docker.compose.service:web com.docker.compose.version:2.15.1]

[ndeloof]

yes indeed, sorry for the confusion.
I can't see any obvious reason for this bug :'(

[ndeloof]

I'm closing this issue as obsolete, with no activity for > 1 year
If issue is still relevant, please comment or create a follow-up issue