[BUG] [v2.32.*] depends_on ignored when a service extending another service is specified

[buxm]

Description

Starting from v2.32.1, the depends_on service attribute in compose.yaml is ignored by docker compose when a service that extends another service is specified in the command line.

Steps To Reproduce

Given the following compose.yaml:

services:
  redis:
    image: redis:7.4.1

  job-base:
    image: busybox
    depends_on:
      redis:
        condition: service_started
    restart: no

  hello-world-job:
    extends:
      service: job-base
    command: echo Hello world

hello-world-job should get the depends_on attribute from job-base, as follows:

$ docker compose config
name: test-docker-compose-bug
services:
  hello-world-job:
    command:
      - echo
      - Hello
      - world
    image: busybox
    networks:
      default: null
    restart: "no"
  job-base:
    depends_on:
      redis:
        condition: service_started
        required: true
    image: busybox
    networks:
      default: null
    restart: "no"
  redis:
    image: redis:7.4.1
    networks:
      default: null
networks:
  default:
    name: test-docker-compose-bug_default

However, using any version >= 2.32.1, when specifying hello-world-job in the command line the depends_on attribute is ignored:

$ docker compose config hello-world-job
name: test-docker-compose-bug
services:
  hello-world-job:
    command:
      - echo
      - Hello
      - world
    image: busybox
    networks:
      default: null
    restart: "no"
networks:
  default:
    name: test-docker-compose-bug_default

While when using v2.31.0 or earlier, depends_on was not ignored, as follows:

$ docker compose config hello-world-job
name: test-docker-compose-bug
services:
  hello-world-job:
    command:
      - echo
      - Hello
      - world
    depends_on:
      redis:
        condition: service_started
        required: true
    image: busybox
    networks:
      default: null
    restart: "no"
  redis:
    image: redis:7.4.1
    networks:
      default: null
networks:
  default:
    name: test-docker-compose-bug_default

Compose Version

Docker Compose version v2.32.4

Docker Environment

Client: Docker Engine - Community
 Version:    27.5.1
 Context:    default
 Debug Mode: false
 Plugins:
  buildx: Docker Buildx (Docker Inc.)
    Version:  v0.20.0
    Path:     /usr/libexec/docker/cli-plugins/docker-buildx
  compose: Docker Compose (Docker Inc.)
    Version:  v2.32.4
    Path:     /usr/libexec/docker/cli-plugins/docker-compose

Server:
 Containers: 10
  Running: 7
  Paused: 0
  Stopped: 3
 Images: 9
 Server Version: 27.5.1
 Storage Driver: overlay2
  Backing Filesystem: extfs
  Supports d_type: true
  Using metacopy: false
  Native Overlay Diff: true
  userxattr: false
 Logging Driver: journald
 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 splunk syslog
 Swarm: inactive
 Runtimes: io.containerd.runc.v2 runc
 Default Runtime: runc
 Init Binary: docker-init
 containerd version: bcc810d6b9066471b0b6fa75f557a15a1cbf31bb
 runc version: v1.2.4-0-g6c52b3f
 init version: de40ad0
 Security Options:
  apparmor
  seccomp
   Profile: builtin
  cgroupns
 Kernel Version: 6.8.0-52-generic
 Operating System: Ubuntu 24.04.1 LTS
 OSType: linux
 Architecture: x86_64
 CPUs: 2
 Total Memory: 3.73GiB
 Name: e4wardprod01
 ID: d53f5002-90da-41eb-aa40-5e95ebe5d752
 Docker Root Dir: /var/lib/docker
 Debug Mode: false
 Experimental: false
 Insecure Registries:
  127.0.0.0/8
 Live Restore Enabled: true

Anything else?

This behaviour was reported in #12423, #12421 and probably other issues.
A fix was released in v2.32.3, but it didn't fix this specific issue.
From this comment I guess that what the devs are missing is that this bug only shows up when specifying a service on the command line.

[ndeloof]

Already fixed by compose-spec/compose-go#728

[buxm]

I tested docker compose plugin v2.33.0 and I can confirm this issue has now been fixed.
Many thanks.