Stopping mutagen compose with Ctrl+C leaves the sidecar container and sync session running

[paneq]

Which version of Mutagen are you using (mutagen version)?

0.12.0-beta2

Which operating system (platform/version/architecture) are you using?

MacOS

What is the issue that you're experiencing?

When stopping mutagen compose with Ctrl+C, the sidecar container continues running and the file sync session remains operational.

What are the steps to reproduce the issue?

• mutagen compose up
• press Ctrl+C
• docker ps

~/d/t/tf-devx-docker-code-sync (mutagen|✚4…) $ mutagen compose -f docker-compose.yml -f docker-compose-mutagen.yml up
Starting tf-devx-docker-code-sync_mutagen_1 ... done
Resuming existing forwarding sessions
Resuming existing synchronization sessions                                      
WARNING: Found orphan containers (tf-devx-docker-code-sync_bg-sync_1) for this project. If you removed or renamed this service in your compose file, you can run this command with the --remove-orphans flag to clean it up.
Starting tf-devx-docker-code-sync_web_1 ... done
Attaching to tf-devx-docker-code-sync_web_1
web_1      | yarn run v1.22.0
web_1      | $ react-scripts start
web_1      | ℹ ｢wds｣: Project is running at http://172.26.0.3/
web_1      | ℹ ｢wds｣: webpack output is served from 
web_1      | ℹ ｢wds｣: Content not from webpack is served from /usr/src/app/public
web_1      | ℹ ｢wds｣: 404s will fallback to /
web_1      | Starting the development server...
web_1      | 
web_1      | Browserslist: caniuse-lite is outdated. Please run next command `yarn upgrade`
web_1      | Compiled successfully!
web_1      | 
web_1      | You can now view tf-devx-docker-code-sync in the browser.
web_1      | 
web_1      |   Local:            http://localhost:3000
web_1      |   On Your Network:  http://172.26.0.3:3000
web_1      | 
web_1      | Note that the development build is not optimized.
web_1      | To create a production build, use yarn build.
web_1      | 
^CGracefully stopping... (press Ctrl+C again to force)
Stopping tf-devx-docker-code-sync_web_1 ... done

~/d/t/tf-devx-docker-code-sync (mutagen|✚4…) $ docker ps
CONTAINER ID        IMAGE                      COMMAND                  CREATED             STATUS              PORTS               NAMES
ccf3a7e4f009        mutagenio/sidecar:latest   "/usr/bin/mutagen-si…"   24 minutes ago      Up About a minute                       tf-devx-docker-code-sync_mutagen_1

~/d/t/tf-devx-docker-code-sync (mutagen|✚4…) $ mutagen sync list
--------------------------------------------------------------------------------
Name: code
Identifier: sync_lR20X3mNQrJpf0wlTxYL1z1cHzti6yShMR7zmsrwGfX
Labels:
    io.mutagen.compose.daemon.identifier: TPIF_KYYQ_SDFB_WVEE_GG3P_XKJW_CR5F_DNZR_OC3M_QUTI_SG5V_U6Q4
    io.mutagen.compose.project.name: tf-devx-docker-code-sync
Alpha:
    URL: /Users/rupert/develop/toptal/tf-devx-docker-code-sync
    Connection state: Connected
Beta:
    URL: docker://tf-devx-docker-code-sync_mutagen_1/volumes/tf-devx-code
    Connection state: Connected
Status: Watching for changes

What is the expected result of these steps in the absence of the issue?

The sidecar container to be stopped and the sync session terminated.

What is the actual result?

The container and sync session are alive.

Is there any other information that might be helpful?

Using mutagen compose stop or mutagen compose down helps, but in my opinion it should not be necessary.

~/d/t/tf-devx-docker-code-sync (mutagen|✚4…) $ mutagen compose -f docker-compose.yml -f docker-compose-mutagen.yml stop
Pausing forwarding sessions
Pausing synchronization sessions                                                
Stopping tf-devx-docker-code-sync_mutagen_1 ... done

~/d/t/tf-devx-docker-code-sync (mutagen|✚4…) $ docker ps
CONTAINER ID        IMAGE               COMMAND             CREATED             STATUS              PORTS               NAMES

~/d/t/tf-devx-docker-code-sync (mutagen|✚4…) $ mutagen sync list
--------------------------------------------------------------------------------
Name: code
Identifier: sync_lR20X3mNQrJpf0wlTxYL1z1cHzti6yShMR7zmsrwGfX
Labels:
    io.mutagen.compose.daemon.identifier: TPIF_KYYQ_SDFB_WVEE_GG3P_XKJW_CR5F_DNZR_OC3M_QUTI_SG5V_U6Q4
    io.mutagen.compose.project.name: tf-devx-docker-code-sync
Alpha:
    URL: /Users/rupert/develop/toptal/tf-devx-docker-code-sync
    Connection state: Disconnected
Beta:
    URL: docker://tf-devx-docker-code-sync_mutagen_1/volumes/tf-devx-code
    Connection state: Disconnected
Status: [Paused]

Maybe this is related to splitting the config into two files?

# docker-compose.yml
version: '3.4'

services:
  web:
    build:
      context: .
    stdin_open: true
    environment:
      NODE_ENV: development
    ports:
      - 3000:3000
      - 9229:9229
    command: ["yarn", "start"]

# docker-compose-mutagen.yml
version: '3.4'

volumes:
  tf-devx-code:

services:
  web:
    volumes:
      - tf-devx-code:/usr/src/app

x-mutagen:
  sync:
    defaults:
      mode: two-way-resolved
      ignore:
        paths:
          - /node_modules
          - /docker-compose.yml
          - /Dockerfile
          - /mutagen.yml
          - .gitignore
          - /.dockerignore
          - /README.md
          - /.idea
        vcs: true
    code:
      alpha: "./"
      beta: "volume://tf-devx-code"
      mode: "two-way-resolved"

[xenoscopic]

Thanks for bringing this up. This was actually by design, though I don't remember why to be honest... The Compose integration went through quite a few iterations and this may just be a vestigial behavior.

I also think it would make more sense to have the sessions and sidecar container halt on a CTRL-C rather than just mutagen compose down. I'll try to implement that and see if I remember why it was the other way. It might be that the underlying reason is no longer relevant. Either way I'll get back to you on this ASAP.

[paneq]

Thank you for such a positive response. Have a great day and upcoming weekend 💛

[ByScripts]

Is there any way to clear all residual syncs at once, based on the docker-compose.yml file?

My Docker crashed. Now I have dozen of mutagen syncs still running.

Then, if I docker-compose up, all syncs are now created a second time (they then appear twice un mutagen sync list).

If I docker-compose down, only newly created syncs are removed... but older one are still there (in error: Last error: beta polling error: unable to receive poll response: unable to read message length: unexpected EOF)

Thanks.

[xenoscopic]

@ByScripts The best way at the moment is probably to use a label filter with mutagen sync terminate, e.g.

mutagen sync terminate --label-selector=io.mutagen.compose.project.name=<theprojectname>

You can see the corresponding labels/values using mutagen sync list -l.

I know it's not super elegant, but I think this issue will be fixed with some upcoming changes.