dev_container: Detect error state when docker ps returns duplicate containers by antont · Pull Request #54068 · zed-industries/zed

antont · 2026-04-16T13:55:57Z

Self-Review Checklist:

I've reviewed my own diff for quality, security, and reliability
Unsafe blocks (if any) have justifying comments — N/A, no unsafe blocks
The content is consistent with the UI/UX checklist
Tests cover the new/changed behavior
Performance impact has been considered and is acceptable — N/A, no performance-sensitive changes

Summary

Per the Dev Containers spec, the identifying labels devcontainer.local_folder + devcontainer.config_file should be unique per project. In practice two tools can end up with containers that share those labels under different Docker Compose projects — e.g. Zed and the reference @devcontainers/cli / VS Code against the same folder, or Zed across impl/version boundaries (the Rust-native impl landed in v0.232.2; older Zed shelled out to the CLI and used its derivation). Root-cause write-up with fixture and captured output: antont#5.

When that happens, docker ps --format={{ json . }} returns newline-delimited JSON — one object per line — and Zed's previous lookup crashed on it. Silently picking the first value would have been worse: it'd connect Zed to an arbitrary one of the stale containers without the user knowing.

What this PR does

Detects the multi-match state and surfaces it as a clear, user-facing error naming the duplicate IDs, instead of either crashing or silently choosing. The fix is scoped to detection only; no attempt here to resolve the duplicate state (see antont/zed#6 for the follow-up that eliminates the root cause and adds graceful recovery).

DevContainerError::MultipleMatchingContainers(Vec<String>) — new variant with a Display that names the IDs and suggests docker stop / docker rm.
find_process_by_filters now parses output through parse_find_process_output:
- 0 rows → Ok(None)
- 1 row → Ok(Some(_))
- ≥2 rows → Err(MultipleMatchingContainers(ids))
The generic evaluate_json_command / deserialize_json_output helper in command_json.rs stays strict (single JSON value per call). NDJSON awareness is confined to find_process_by_filters, so the generic helper can't drift into silently-picking-first behavior elsewhere.
start_dev_container_with_config passes the new error variant through unchanged, so its crafted Display reaches the UI prompt rather than being swallowed by DevContainerUpFailed.

Why detect rather than resolve

Detection alone is defensive: it prevents connecting to the wrong container and tells the user exactly what's in Docker. Resolution (picking a canonical container, migrating namespaces, etc.) is a larger change that depends on fixing the derivation divergence upstream — tracked in the follow-up PR above.

Test plan

cargo test -p dev_container --lib — all tests pass
New unit test parse_find_process_output_returns_multiple_matching_containers exercises the ≥2-rows branch and checks both the variant and the error message
Existing single-match / empty-output cases covered by parse_find_process_output_parses_single_object and the empty-output test
End-to-end with the compose fixture at https://github.com/antont/zed-devcontainer-compose-test: step §5 of its VERIFY.md reproduces the dual-label docker ps that returns two rows — with this PR built, opening the fixture in Zed surfaces the named error instead of crashing or silently connecting

Release Notes:

Fixed dev container start silently connecting to a stale container when multiple containers matched the project's identifying labels; Zed now surfaces a clear error naming the duplicate IDs.

KyleBarton · 2026-04-16T16:56:05Z

@antont can you show an example of how you ended up in that state?

since all containers in the compose project get the same devcontainer.local_folder and devcontainer.config_file labels.

I don't think that's the intended implementation, in Zed or in the reference implementation. The labels should apply only to the "main" service, as defined in the service field of devcontainer.json. It's the same reason why:

find_process_by_filters returns Option (singular) — it only needs one container ID to confirm a container exists. The caller (check_for_existing_container) then passes that ID to docker inspect for full details.

That's because Zed (or VSCode/whatever) needs to know which specific container to connect to. At that point, the broader docker compose infrastructure is opaque to the tool.

antont · 2026-04-16T17:39:02Z

@KyleBarton oh you are right to ask, apparently my container config is a mess!

I did not look as it was working earlier and also now with official Zed 0.227.1

I don't have time to check more now but an agent is telling this at least:

⏺ From the docker ps output, there are two app containers for the same project
folder:

xxx-devcontainer-app-1 — created by VS Code / devcontainer CLI (project name from the folder name)
xxx-app-1 — created by Zed (project name xxx from the devcontainer.json name field)

Both have the same devcontainer.local_folder and devcontainer.config_file labels
pointing to the same project, but they were created by different tools that
generated different compose project names. So the filter matches both.

KyleBarton · 2026-04-17T15:24:55Z

@antont got it - definitely a strange state to be in, but I don't think it's one that we should handle this way. These labels are supposed to be uniquely-identifying. The algorithm basically goes:

Look for a container with these identifying labels
If one is present, use it (start it if it's in a stopped state)
If none are present, create it
If >1 are present, ??? <- we are here

I am all for better error messaging in that last case, so that the user can identify what's going on. But I think it's correctly classed as an error case. Zed doesn't know which container is valid to connect to in this case, and shouldn't proceed by just taking the first one. Do you have interest in transforming this PR into an improvement for error handling in this case? Otherwise, I think we should close

antont · 2026-04-17T15:46:04Z

@KyleBarton

But I think it's correctly classed as an error case. Zed doesn't know which container is valid to connect to in this case, and shouldn't proceed by just taking the first one. Do you have interest in transforming this PR into an improvement for error handling in this case? Otherwise, I think we should close

Yes. I don't know the details of the dev container specs or anything, but based on your explanation I agree.

I am interested in doing that error handling -- it would have been helpful in my case, now I just didn't know that it had happened. It would be a nice exercise for me to make that change, and it would be useful if the same happens later. I don't know when I'll have the time but hopefully in say 3-4 days. If I fail to arrange that, I'll just close. I'll change this to a draft in the meantime.

…ar error Per Dev Containers spec, the identifying labels (devcontainer.local_folder + devcontainer.config_file) should be unique per project. When two tools (e.g. Zed + the reference devcontainer CLI) derive different compose project names from the same folder, both containers end up carrying these labels and `docker ps` returns more than one match. Previously the generic `evaluate_json_command` helper crashed on the resulting newline-delimited JSON. Silently picking the first value would hide the duplicate state and could connect Zed to the wrong container. Instead, keep the generic helper strict (one JSON value per call) and move NDJSON awareness into `find_process_by_filters`: - 0 matches -> Ok(None) - 1 match -> Ok(Some(..)) - >=2 -> Err(MultipleMatchingContainers(ids)) with a Display message that names the duplicate IDs and describes how to resolve. The new error variant is passed through unchanged in `start_dev_container_with_config` so its crafted Display reaches the UI prompt instead of being swallowed by `DevContainerUpFailed`. Release Notes: - Fixed dev container start silently connecting to a stale container when multiple containers matched the project's identifying labels; Zed now surfaces a clear error naming the duplicate IDs. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>

Introduce `pick_canonical_container`, a thin recovery layer above `find_process_by_filters`. When the multi-match detection from zed-industries#54068 trips, inspect each candidate and prefer the one whose `com.docker.compose.project` label equals `self.project_name()`. Zero or ≥2 canonical matches still fall through to the `MultipleMatchingContainers` error, preserving the safety net; only the unambiguous-recovery case is intercepted. This makes the compose-project-name fix from PR #6 a transparent upgrade: users migrating past v0.231.x to v0.232+ on an existing Zed-managed project had one container under the legacy `safe_id_lower(name)` project. After the derivation change new Zed creates one under the canonical `${folder}_devcontainer`. Without the tiebreak, the label-based lookup sees both and errors out; with it, Zed reuses the canonical one and logs the orphan's id so users can clean up on their own schedule. The multi-match detection itself (`parse_find_process_output`, `MultipleMatchingContainers`, its Display impl, the pass-through arm in `start_dev_container_with_config`) stays byte-identical with zed-industries#54068. Updates the pre-existing `check_for_existing_container_errors_when_multiple_match` test to supply non-canonical inspect overrides, so it still exercises the safety-net fall-through now that the path inspects each candidate. running 3 tests test devcontainer_manifest::test::check_for_existing_container_errors_when_multiple_match ... ok test devcontainer_manifest::test::check_for_existing_container_errors_when_none_canonical ... ok test devcontainer_manifest::test::check_for_existing_container_prefers_canonical_compose_project ... ok test result: ok. 78 passed; 0 failed (full crate) Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>

antont · 2026-04-19T10:12:24Z

@KyleBarton

I made a thorough investigation into how this happened for me, reported in #54255 with repro instructions, using fixture repos I put up with docs with evidence from my repro runs.

I also have a fix which I'm using locally in my work build now, I'll submit a PR for consideration soon.

Before the investigation and the fix for the root cause, I also added the error dialog to this PR.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>

Introduce `pick_canonical_container`, a thin recovery layer above `find_process_by_filters`. When the multi-match detection from zed-industries#54068 trips, inspect each candidate and prefer the one whose `com.docker.compose.project` label equals `self.project_name()`. Zero or ≥2 canonical matches still fall through to the `MultipleMatchingContainers` error, preserving the safety net; only the unambiguous-recovery case is intercepted. This makes the compose-project-name fix from PR #6 a transparent upgrade: users migrating past v0.231.x to v0.232+ on an existing Zed-managed project had one container under the legacy `safe_id_lower(name)` project. After the derivation change new Zed creates one under the canonical `${folder}_devcontainer`. Without the tiebreak, the label-based lookup sees both and errors out; with it, Zed reuses the canonical one and logs the orphan's id so users can clean up on their own schedule. The multi-match detection itself (`parse_find_process_output`, `MultipleMatchingContainers`, its Display impl, the pass-through arm in `start_dev_container_with_config`) stays byte-identical with zed-industries#54068. Updates the pre-existing `check_for_existing_container_errors_when_multiple_match` test to supply non-canonical inspect overrides, so it still exercises the safety-net fall-through now that the path inspects each candidate. running 3 tests test devcontainer_manifest::test::check_for_existing_container_errors_when_multiple_match ... ok test devcontainer_manifest::test::check_for_existing_container_errors_when_none_canonical ... ok test devcontainer_manifest::test::check_for_existing_container_prefers_canonical_compose_project ... ok test result: ok. 78 passed; 0 failed (full crate) Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>

antont · 2026-04-20T09:12:05Z

Okie the follow-up is there, with a somewhat crazy amount of things to ensure matching the original dev containers implementation, #54302

Introduce `pick_canonical_container`, a thin recovery layer above `find_process_by_filters`. When the multi-match detection from zed-industries#54068 trips, inspect each candidate and prefer the one whose `com.docker.compose.project` label equals `self.project_name()`. Zero or ≥2 canonical matches still fall through to the `MultipleMatchingContainers` error, preserving the safety net; only the unambiguous-recovery case is intercepted. This makes the compose-project-name fix from PR #6 a transparent upgrade: users migrating past v0.231.x to v0.232+ on an existing Zed-managed project had one container under the legacy `safe_id_lower(name)` project. After the derivation change new Zed creates one under the canonical `${folder}_devcontainer`. Without the tiebreak, the label-based lookup sees both and errors out; with it, Zed reuses the canonical one and logs the orphan's id so users can clean up on their own schedule. The multi-match detection itself (`parse_find_process_output`, `MultipleMatchingContainers`, its Display impl, the pass-through arm in `start_dev_container_with_config`) stays byte-identical with zed-industries#54068. Updates the pre-existing `check_for_existing_container_errors_when_multiple_match` test to supply non-canonical inspect overrides, so it still exercises the safety-net fall-through now that the path inspects each candidate. running 3 tests test devcontainer_manifest::test::check_for_existing_container_errors_when_multiple_match ... ok test devcontainer_manifest::test::check_for_existing_container_errors_when_none_canonical ... ok test devcontainer_manifest::test::check_for_existing_container_prefers_canonical_compose_project ... ok test result: ok. 78 passed; 0 failed (full crate) Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>

antont · 2026-04-22T15:04:36Z

Folded into #54302 per review — closing unmerged. The MultipleMatchingContainers detection functionality lands there.

@KyleBarton

> **Draft / open question for maintainers.** The failure mode this fixes is narrow — a new-Zed-created container exists under the `name`-field project while a CLI-derivation tool (`@devcontainers/cli`, VS Code) operates on the same folder (the container persists in Docker, so the originating Zed session doesn't need to still be open). See issue #54255 failure mode 3 and the fixture's step 6. > > I'd like to pose this as a question rather than a claim: is matching `@devcontainers/cli`'s `getProjectName` precedence something the project wants to take on, given the narrowness of the bug? I wrote this implementation mostly as a way to explore what parity would actually cost — happy to close it if you'd rather leave it as-is, or pare it down (e.g. just rule 4) if a partial match is preferable. > > The broader value beyond this specific bug: devcontainer impls agreeing on the same project name means containers created by Zed, the devcontainer CLI, and VS Code are interchangeable for the same folder, which feels worth it to me — but you know the project's priorities better. > > Folds in #54068 (detection) — closing that PR unmerged; its `MultipleMatchingContainers` error lands here. Self-Review Checklist: - [x] I've reviewed my own diff for quality, security, and reliability - [x] Unsafe blocks (if any) have justifying comments - [x] The content is consistent with the [UI/UX checklist](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist) - [x] Tests cover the new/changed behavior - [x] Performance impact has been considered and is acceptable Closes #54255 ## Summary **Match `@devcontainers/cli`'s full `getProjectName` precedence.** Replaces `safe_id_lower(devcontainer.json's name)` with the five-step chain the reference CLI walks (see [`src/spec-node/dockerCompose.ts` in devcontainers/cli](https://github.com/devcontainers/cli/blob/main/src/spec-node/dockerCompose.ts)): 1. `COMPOSE_PROJECT_NAME` from the local environment. 2. `COMPOSE_PROJECT_NAME=` in the workspace `.env` file. 3. Top-level `name:` on the merged compose config, when at least one fragment declared it explicitly. 4. `${workspaceFolderBasename}_devcontainer` — only when the first compose file's directory is `<workspace>/.devcontainer/`. 5. Otherwise, the plain basename of the first compose file's directory (no suffix). The old Zed implementation diverged at every one of those inputs: any user setting `COMPOSE_PROJECT_NAME`, shipping a `.env` with one, declaring a top-level compose `name:`, or pointing `dockerComposeFile` outside `.devcontainer/` (e.g. `"../docker-compose.yml"`) got a different project namespace than the CLI and VS Code, producing two compose projects for the same folder. Adds a small `sanitize_compose_project_name()` helper implementing the CLI's rules (lowercase + strip `[^-_a-z0-9]`) — notably preserving hyphens, which `safe_id_lower` would have replaced with underscores. Adds two helpers used by the precedence walk: - `parse_dotenv_compose_project_name` — line scan extracting `COMPOSE_PROJECT_NAME=…` from the workspace `.env`, matching the subset the CLI's regex dotenv reader recognizes. - `compose_fragment_declares_name` — parses each compose fragment with `yaml-rust2` (already a transitive workspace dep; slated to become a direct dep via #53922) and checks for a `name` key on the root mapping (block, quoted, or flow style all work), matching the CLI's own `yaml.load`. `docker compose config` always injects `name: devcontainer` into its merged output when no fragment declared one, so rule 3 needs to distinguish the user-provided case from the injected default — this helper supplies that signal. On YAML parse failure it returns "not declared" (rule 4 applies), matching the CLI's fallback. `project_name()` becomes async and fallible (`async fn project_name(&self) -> Result<String, DevContainerError>`) so it can load the `.env` file and each compose fragment via `self.fs.load`. Four call sites now `.await?` the derivation. Real I/O errors on the `.env` read propagate as `FilesystemError` (matching the CLI's narrow `ENOENT`/`EISDIR` swallow); fragment-rescan read errors are logged and skipped (matching the CLI's broader try/catch over its fragment read + parse). The `name` field is still used as the features image-tag prefix (`generate_features_image_tag`); only the compose project namespace is decoupled from it. **Duplicate-container detection (from #54068).** When `check_for_existing_container`'s label-based lookup returns more than one match, propagate `MultipleMatchingContainers(ids)` with instructions to clean up the stale one(s). This covers the mixed-version upgrade edge case where a pre-fix Zed left a container under the legacy project name alongside a CLI-style one — transparent to users in the common case (one tool, one container), explicit error when two legacy siblings need manual cleanup. ## Why Full write-up with verified fixtures and captured output: #54255. Three failure modes from the same root cause, all resolved by this change: 1. **Interop** — opening a folder in both Zed and `devcontainer up` (or Zed and VS Code) creates two compose projects with identical `devcontainer.local_folder` + `devcontainer.config_file` labels, breaking the spec's uniqueness invariant. 2. **Cross-worktree silent db/volume reuse** — if multiple git worktrees share a `devcontainer.json` with the same `name`, Zed uses the same compose project for all of them; Compose reuses stateful siblings (db, cache, localstack) by config-hash, so worktree B silently inherits worktree A's database. Fixture + captured output: [antont/zed-devcontainer-db-share-repro](https://github.com/antont/zed-devcontainer-db-share-repro). 3. **Mixed-version Zed sessions** — the Rust impl landed in stable v0.232.2 (2026-04-15, #52338). Older Zed (≤v0.231.x) shelled out to `@devcontainers/cli` so it used the reference derivation. The collision shows up when a new-Zed-created container exists under the name-field project while a CLI-derivation tool (old Zed, `devcontainer up`, VS Code) operates on the same folder. ## Migration / compatibility Existing Zed-created containers (under the old `safe_id_lower(name)` project) continue to be found via `check_for_existing_container`'s label-based lookup — they're looked up by `devcontainer.local_folder` + `devcontainer.config_file`, not by project name. A user with duplicate legacy containers from a prior Zed session sees `MultipleMatchingContainers` with cleanup instructions. ## Revision — 2026-04-22 Revised per @KyleBarton review on the prior version: - Swapped the YAML parser from `serde_yaml_ng` to `yaml-rust2` (already transitive via `tree-sitter-yaml`; net reduction of one direct workspace dep; also what #53922 will pull in). - Dropped the mixed-version tiebreak (`pick_canonical_container`) and its `com.docker.compose.project` serde label. The edge case it covered is transient enough to address via the explicit `MultipleMatchingContainers` error rather than permanent tiebreaking code. - Folded #54068's detection commit into this PR; #54068 closed unmerged. - Rebased onto `main`. ## Test plan - [x] `cargo test -p dev_container --lib` — 89 passed, including: - `sanitize_compose_project_name_matches_cli_rules` - `--project-name` assertion added to `test_spawns_devcontainer_with_docker_compose` - `check_for_existing_container_errors_when_multiple_match` - `derive_project_name_env_wins_over_everything` - `derive_project_name_dotenv_wins_over_compose_and_fallback` - `derive_project_name_compose_name_wins_over_fallback` - `derive_project_name_skips_compose_name_when_not_explicitly_declared` - `derive_project_name_omits_suffix_when_compose_file_outside_devcontainer_dir` - `derive_project_name_normalizes_compose_path_for_rule_4` - `compose_fragment_declares_name_detects_top_level_name_key` (covers block, quoted-key, and flow-style roots, plus parse failure → not-declared) - `is_missing_file_error_only_accepts_notfound_and_isadirectory` - [x] `cargo fmt --all` — clean - [x] `./script/clippy -p dev_container` — clean - [x] **End-to-end with fixture** [antont/zed-devcontainer-compose-test](https://github.com/antont/zed-devcontainer-compose-test): - Build `zed` from this branch. - Clean slate: `docker ps -a --filter "label=devcontainer.local_folder=$PWD" -q | xargs -r docker rm -f` - `zed --dev-container /path/to/devcontainer-compose-test` → Zed creates container under project `devcontainer-compose-test_devcontainer` (was `compose_duplicate_repro` before the fix). - `devcontainer up --workspace-folder $PWD` → CLI reports the same `containerId` Zed created; no second compose project is introduced. - Captured: `devcontainer-compose-test_devcontainer-app-1`, `composeProjectName: "devcontainer-compose-test_devcontainer"` reported by both tools. Release Notes: - Fixed dev container Docker Compose project name now matches the full `getProjectName` precedence from the reference devcontainer CLI (`COMPOSE_PROJECT_NAME` in the environment, then in the workspace `.env`, then an explicit top-level `name:` on the merged compose config, then the basename of the first compose file's directory — with the `_devcontainer` suffix only when that directory is `<workspace>/.devcontainer`). This prevents duplicate containers when the same folder is opened with both Zed and the devcontainer CLI / VS Code. --------- Co-authored-by: Claude Opus 4.7 <noreply@anthropic.com>

@KyleBarton

…ustries#54302) > **Draft / open question for maintainers.** The failure mode this fixes is narrow — a new-Zed-created container exists under the `name`-field project while a CLI-derivation tool (`@devcontainers/cli`, VS Code) operates on the same folder (the container persists in Docker, so the originating Zed session doesn't need to still be open). See issue zed-industries#54255 failure mode 3 and the fixture's step 6. > > I'd like to pose this as a question rather than a claim: is matching `@devcontainers/cli`'s `getProjectName` precedence something the project wants to take on, given the narrowness of the bug? I wrote this implementation mostly as a way to explore what parity would actually cost — happy to close it if you'd rather leave it as-is, or pare it down (e.g. just rule 4) if a partial match is preferable. > > The broader value beyond this specific bug: devcontainer impls agreeing on the same project name means containers created by Zed, the devcontainer CLI, and VS Code are interchangeable for the same folder, which feels worth it to me — but you know the project's priorities better. > > Folds in zed-industries#54068 (detection) — closing that PR unmerged; its `MultipleMatchingContainers` error lands here. Self-Review Checklist: - [x] I've reviewed my own diff for quality, security, and reliability - [x] Unsafe blocks (if any) have justifying comments - [x] The content is consistent with the [UI/UX checklist](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist) - [x] Tests cover the new/changed behavior - [x] Performance impact has been considered and is acceptable Closes zed-industries#54255 ## Summary **Match `@devcontainers/cli`'s full `getProjectName` precedence.** Replaces `safe_id_lower(devcontainer.json's name)` with the five-step chain the reference CLI walks (see [`src/spec-node/dockerCompose.ts` in devcontainers/cli](https://github.com/devcontainers/cli/blob/main/src/spec-node/dockerCompose.ts)): 1. `COMPOSE_PROJECT_NAME` from the local environment. 2. `COMPOSE_PROJECT_NAME=` in the workspace `.env` file. 3. Top-level `name:` on the merged compose config, when at least one fragment declared it explicitly. 4. `${workspaceFolderBasename}_devcontainer` — only when the first compose file's directory is `<workspace>/.devcontainer/`. 5. Otherwise, the plain basename of the first compose file's directory (no suffix). The old Zed implementation diverged at every one of those inputs: any user setting `COMPOSE_PROJECT_NAME`, shipping a `.env` with one, declaring a top-level compose `name:`, or pointing `dockerComposeFile` outside `.devcontainer/` (e.g. `"../docker-compose.yml"`) got a different project namespace than the CLI and VS Code, producing two compose projects for the same folder. Adds a small `sanitize_compose_project_name()` helper implementing the CLI's rules (lowercase + strip `[^-_a-z0-9]`) — notably preserving hyphens, which `safe_id_lower` would have replaced with underscores. Adds two helpers used by the precedence walk: - `parse_dotenv_compose_project_name` — line scan extracting `COMPOSE_PROJECT_NAME=…` from the workspace `.env`, matching the subset the CLI's regex dotenv reader recognizes. - `compose_fragment_declares_name` — parses each compose fragment with `yaml-rust2` (already a transitive workspace dep; slated to become a direct dep via zed-industries#53922) and checks for a `name` key on the root mapping (block, quoted, or flow style all work), matching the CLI's own `yaml.load`. `docker compose config` always injects `name: devcontainer` into its merged output when no fragment declared one, so rule 3 needs to distinguish the user-provided case from the injected default — this helper supplies that signal. On YAML parse failure it returns "not declared" (rule 4 applies), matching the CLI's fallback. `project_name()` becomes async and fallible (`async fn project_name(&self) -> Result<String, DevContainerError>`) so it can load the `.env` file and each compose fragment via `self.fs.load`. Four call sites now `.await?` the derivation. Real I/O errors on the `.env` read propagate as `FilesystemError` (matching the CLI's narrow `ENOENT`/`EISDIR` swallow); fragment-rescan read errors are logged and skipped (matching the CLI's broader try/catch over its fragment read + parse). The `name` field is still used as the features image-tag prefix (`generate_features_image_tag`); only the compose project namespace is decoupled from it. **Duplicate-container detection (from zed-industries#54068).** When `check_for_existing_container`'s label-based lookup returns more than one match, propagate `MultipleMatchingContainers(ids)` with instructions to clean up the stale one(s). This covers the mixed-version upgrade edge case where a pre-fix Zed left a container under the legacy project name alongside a CLI-style one — transparent to users in the common case (one tool, one container), explicit error when two legacy siblings need manual cleanup. ## Why Full write-up with verified fixtures and captured output: zed-industries#54255. Three failure modes from the same root cause, all resolved by this change: 1. **Interop** — opening a folder in both Zed and `devcontainer up` (or Zed and VS Code) creates two compose projects with identical `devcontainer.local_folder` + `devcontainer.config_file` labels, breaking the spec's uniqueness invariant. 2. **Cross-worktree silent db/volume reuse** — if multiple git worktrees share a `devcontainer.json` with the same `name`, Zed uses the same compose project for all of them; Compose reuses stateful siblings (db, cache, localstack) by config-hash, so worktree B silently inherits worktree A's database. Fixture + captured output: [antont/zed-devcontainer-db-share-repro](https://github.com/antont/zed-devcontainer-db-share-repro). 3. **Mixed-version Zed sessions** — the Rust impl landed in stable v0.232.2 (2026-04-15, zed-industries#52338). Older Zed (≤v0.231.x) shelled out to `@devcontainers/cli` so it used the reference derivation. The collision shows up when a new-Zed-created container exists under the name-field project while a CLI-derivation tool (old Zed, `devcontainer up`, VS Code) operates on the same folder. ## Migration / compatibility Existing Zed-created containers (under the old `safe_id_lower(name)` project) continue to be found via `check_for_existing_container`'s label-based lookup — they're looked up by `devcontainer.local_folder` + `devcontainer.config_file`, not by project name. A user with duplicate legacy containers from a prior Zed session sees `MultipleMatchingContainers` with cleanup instructions. ## Revision — 2026-04-22 Revised per @KyleBarton review on the prior version: - Swapped the YAML parser from `serde_yaml_ng` to `yaml-rust2` (already transitive via `tree-sitter-yaml`; net reduction of one direct workspace dep; also what zed-industries#53922 will pull in). - Dropped the mixed-version tiebreak (`pick_canonical_container`) and its `com.docker.compose.project` serde label. The edge case it covered is transient enough to address via the explicit `MultipleMatchingContainers` error rather than permanent tiebreaking code. - Folded zed-industries#54068's detection commit into this PR; zed-industries#54068 closed unmerged. - Rebased onto `main`. ## Test plan - [x] `cargo test -p dev_container --lib` — 89 passed, including: - `sanitize_compose_project_name_matches_cli_rules` - `--project-name` assertion added to `test_spawns_devcontainer_with_docker_compose` - `check_for_existing_container_errors_when_multiple_match` - `derive_project_name_env_wins_over_everything` - `derive_project_name_dotenv_wins_over_compose_and_fallback` - `derive_project_name_compose_name_wins_over_fallback` - `derive_project_name_skips_compose_name_when_not_explicitly_declared` - `derive_project_name_omits_suffix_when_compose_file_outside_devcontainer_dir` - `derive_project_name_normalizes_compose_path_for_rule_4` - `compose_fragment_declares_name_detects_top_level_name_key` (covers block, quoted-key, and flow-style roots, plus parse failure → not-declared) - `is_missing_file_error_only_accepts_notfound_and_isadirectory` - [x] `cargo fmt --all` — clean - [x] `./script/clippy -p dev_container` — clean - [x] **End-to-end with fixture** [antont/zed-devcontainer-compose-test](https://github.com/antont/zed-devcontainer-compose-test): - Build `zed` from this branch. - Clean slate: `docker ps -a --filter "label=devcontainer.local_folder=$PWD" -q | xargs -r docker rm -f` - `zed --dev-container /path/to/devcontainer-compose-test` → Zed creates container under project `devcontainer-compose-test_devcontainer` (was `compose_duplicate_repro` before the fix). - `devcontainer up --workspace-folder $PWD` → CLI reports the same `containerId` Zed created; no second compose project is introduced. - Captured: `devcontainer-compose-test_devcontainer-app-1`, `composeProjectName: "devcontainer-compose-test_devcontainer"` reported by both tools. Release Notes: - Fixed dev container Docker Compose project name now matches the full `getProjectName` precedence from the reference devcontainer CLI (`COMPOSE_PROJECT_NAME` in the environment, then in the workspace `.env`, then an explicit top-level `name:` on the merged compose config, then the basename of the first compose file's directory — with the `_devcontainer` suffix only when that directory is `<workspace>/.devcontainer`). This prevents duplicate containers when the same folder is opened with both Zed and the devcontainer CLI / VS Code. --------- Co-authored-by: Claude Opus 4.7 <noreply@anthropic.com>

@KyleBarton

…ustries#54302) > **Draft / open question for maintainers.** The failure mode this fixes is narrow — a new-Zed-created container exists under the `name`-field project while a CLI-derivation tool (`@devcontainers/cli`, VS Code) operates on the same folder (the container persists in Docker, so the originating Zed session doesn't need to still be open). See issue zed-industries#54255 failure mode 3 and the fixture's step 6. > > I'd like to pose this as a question rather than a claim: is matching `@devcontainers/cli`'s `getProjectName` precedence something the project wants to take on, given the narrowness of the bug? I wrote this implementation mostly as a way to explore what parity would actually cost — happy to close it if you'd rather leave it as-is, or pare it down (e.g. just rule 4) if a partial match is preferable. > > The broader value beyond this specific bug: devcontainer impls agreeing on the same project name means containers created by Zed, the devcontainer CLI, and VS Code are interchangeable for the same folder, which feels worth it to me — but you know the project's priorities better. > > Folds in zed-industries#54068 (detection) — closing that PR unmerged; its `MultipleMatchingContainers` error lands here. Self-Review Checklist: - [x] I've reviewed my own diff for quality, security, and reliability - [x] Unsafe blocks (if any) have justifying comments - [x] The content is consistent with the [UI/UX checklist](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist) - [x] Tests cover the new/changed behavior - [x] Performance impact has been considered and is acceptable Closes zed-industries#54255 ## Summary **Match `@devcontainers/cli`'s full `getProjectName` precedence.** Replaces `safe_id_lower(devcontainer.json's name)` with the five-step chain the reference CLI walks (see [`src/spec-node/dockerCompose.ts` in devcontainers/cli](https://github.com/devcontainers/cli/blob/main/src/spec-node/dockerCompose.ts)): 1. `COMPOSE_PROJECT_NAME` from the local environment. 2. `COMPOSE_PROJECT_NAME=` in the workspace `.env` file. 3. Top-level `name:` on the merged compose config, when at least one fragment declared it explicitly. 4. `${workspaceFolderBasename}_devcontainer` — only when the first compose file's directory is `<workspace>/.devcontainer/`. 5. Otherwise, the plain basename of the first compose file's directory (no suffix). The old Zed implementation diverged at every one of those inputs: any user setting `COMPOSE_PROJECT_NAME`, shipping a `.env` with one, declaring a top-level compose `name:`, or pointing `dockerComposeFile` outside `.devcontainer/` (e.g. `"../docker-compose.yml"`) got a different project namespace than the CLI and VS Code, producing two compose projects for the same folder. Adds a small `sanitize_compose_project_name()` helper implementing the CLI's rules (lowercase + strip `[^-_a-z0-9]`) — notably preserving hyphens, which `safe_id_lower` would have replaced with underscores. Adds two helpers used by the precedence walk: - `parse_dotenv_compose_project_name` — line scan extracting `COMPOSE_PROJECT_NAME=…` from the workspace `.env`, matching the subset the CLI's regex dotenv reader recognizes. - `compose_fragment_declares_name` — parses each compose fragment with `yaml-rust2` (already a transitive workspace dep; slated to become a direct dep via zed-industries#53922) and checks for a `name` key on the root mapping (block, quoted, or flow style all work), matching the CLI's own `yaml.load`. `docker compose config` always injects `name: devcontainer` into its merged output when no fragment declared one, so rule 3 needs to distinguish the user-provided case from the injected default — this helper supplies that signal. On YAML parse failure it returns "not declared" (rule 4 applies), matching the CLI's fallback. `project_name()` becomes async and fallible (`async fn project_name(&self) -> Result<String, DevContainerError>`) so it can load the `.env` file and each compose fragment via `self.fs.load`. Four call sites now `.await?` the derivation. Real I/O errors on the `.env` read propagate as `FilesystemError` (matching the CLI's narrow `ENOENT`/`EISDIR` swallow); fragment-rescan read errors are logged and skipped (matching the CLI's broader try/catch over its fragment read + parse). The `name` field is still used as the features image-tag prefix (`generate_features_image_tag`); only the compose project namespace is decoupled from it. **Duplicate-container detection (from zed-industries#54068).** When `check_for_existing_container`'s label-based lookup returns more than one match, propagate `MultipleMatchingContainers(ids)` with instructions to clean up the stale one(s). This covers the mixed-version upgrade edge case where a pre-fix Zed left a container under the legacy project name alongside a CLI-style one — transparent to users in the common case (one tool, one container), explicit error when two legacy siblings need manual cleanup. ## Why Full write-up with verified fixtures and captured output: zed-industries#54255. Three failure modes from the same root cause, all resolved by this change: 1. **Interop** — opening a folder in both Zed and `devcontainer up` (or Zed and VS Code) creates two compose projects with identical `devcontainer.local_folder` + `devcontainer.config_file` labels, breaking the spec's uniqueness invariant. 2. **Cross-worktree silent db/volume reuse** — if multiple git worktrees share a `devcontainer.json` with the same `name`, Zed uses the same compose project for all of them; Compose reuses stateful siblings (db, cache, localstack) by config-hash, so worktree B silently inherits worktree A's database. Fixture + captured output: [antont/zed-devcontainer-db-share-repro](https://github.com/antont/zed-devcontainer-db-share-repro). 3. **Mixed-version Zed sessions** — the Rust impl landed in stable v0.232.2 (2026-04-15, zed-industries#52338). Older Zed (≤v0.231.x) shelled out to `@devcontainers/cli` so it used the reference derivation. The collision shows up when a new-Zed-created container exists under the name-field project while a CLI-derivation tool (old Zed, `devcontainer up`, VS Code) operates on the same folder. ## Migration / compatibility Existing Zed-created containers (under the old `safe_id_lower(name)` project) continue to be found via `check_for_existing_container`'s label-based lookup — they're looked up by `devcontainer.local_folder` + `devcontainer.config_file`, not by project name. A user with duplicate legacy containers from a prior Zed session sees `MultipleMatchingContainers` with cleanup instructions. ## Revision — 2026-04-22 Revised per @KyleBarton review on the prior version: - Swapped the YAML parser from `serde_yaml_ng` to `yaml-rust2` (already transitive via `tree-sitter-yaml`; net reduction of one direct workspace dep; also what zed-industries#53922 will pull in). - Dropped the mixed-version tiebreak (`pick_canonical_container`) and its `com.docker.compose.project` serde label. The edge case it covered is transient enough to address via the explicit `MultipleMatchingContainers` error rather than permanent tiebreaking code. - Folded zed-industries#54068's detection commit into this PR; zed-industries#54068 closed unmerged. - Rebased onto `main`. ## Test plan - [x] `cargo test -p dev_container --lib` — 89 passed, including: - `sanitize_compose_project_name_matches_cli_rules` - `--project-name` assertion added to `test_spawns_devcontainer_with_docker_compose` - `check_for_existing_container_errors_when_multiple_match` - `derive_project_name_env_wins_over_everything` - `derive_project_name_dotenv_wins_over_compose_and_fallback` - `derive_project_name_compose_name_wins_over_fallback` - `derive_project_name_skips_compose_name_when_not_explicitly_declared` - `derive_project_name_omits_suffix_when_compose_file_outside_devcontainer_dir` - `derive_project_name_normalizes_compose_path_for_rule_4` - `compose_fragment_declares_name_detects_top_level_name_key` (covers block, quoted-key, and flow-style roots, plus parse failure → not-declared) - `is_missing_file_error_only_accepts_notfound_and_isadirectory` - [x] `cargo fmt --all` — clean - [x] `./script/clippy -p dev_container` — clean - [x] **End-to-end with fixture** [antont/zed-devcontainer-compose-test](https://github.com/antont/zed-devcontainer-compose-test): - Build `zed` from this branch. - Clean slate: `docker ps -a --filter "label=devcontainer.local_folder=$PWD" -q | xargs -r docker rm -f` - `zed --dev-container /path/to/devcontainer-compose-test` → Zed creates container under project `devcontainer-compose-test_devcontainer` (was `compose_duplicate_repro` before the fix). - `devcontainer up --workspace-folder $PWD` → CLI reports the same `containerId` Zed created; no second compose project is introduced. - Captured: `devcontainer-compose-test_devcontainer-app-1`, `composeProjectName: "devcontainer-compose-test_devcontainer"` reported by both tools. Release Notes: - Fixed dev container Docker Compose project name now matches the full `getProjectName` precedence from the reference devcontainer CLI (`COMPOSE_PROJECT_NAME` in the environment, then in the workspace `.env`, then an explicit top-level `name:` on the merged compose config, then the basename of the first compose file's directory — with the `_devcontainer` suffix only when that directory is `<workspace>/.devcontainer`). This prevents duplicate containers when the same folder is opened with both Zed and the devcontainer CLI / VS Code. --------- Co-authored-by: Claude Opus 4.7 <noreply@anthropic.com>

@KyleBarton

…ustries#54302) > **Draft / open question for maintainers.** The failure mode this fixes is narrow — a new-Zed-created container exists under the `name`-field project while a CLI-derivation tool (`@devcontainers/cli`, VS Code) operates on the same folder (the container persists in Docker, so the originating Zed session doesn't need to still be open). See issue zed-industries#54255 failure mode 3 and the fixture's step 6. > > I'd like to pose this as a question rather than a claim: is matching `@devcontainers/cli`'s `getProjectName` precedence something the project wants to take on, given the narrowness of the bug? I wrote this implementation mostly as a way to explore what parity would actually cost — happy to close it if you'd rather leave it as-is, or pare it down (e.g. just rule 4) if a partial match is preferable. > > The broader value beyond this specific bug: devcontainer impls agreeing on the same project name means containers created by Zed, the devcontainer CLI, and VS Code are interchangeable for the same folder, which feels worth it to me — but you know the project's priorities better. > > Folds in zed-industries#54068 (detection) — closing that PR unmerged; its `MultipleMatchingContainers` error lands here. Self-Review Checklist: - [x] I've reviewed my own diff for quality, security, and reliability - [x] Unsafe blocks (if any) have justifying comments - [x] The content is consistent with the [UI/UX checklist](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist) - [x] Tests cover the new/changed behavior - [x] Performance impact has been considered and is acceptable Closes zed-industries#54255 ## Summary **Match `@devcontainers/cli`'s full `getProjectName` precedence.** Replaces `safe_id_lower(devcontainer.json's name)` with the five-step chain the reference CLI walks (see [`src/spec-node/dockerCompose.ts` in devcontainers/cli](https://github.com/devcontainers/cli/blob/main/src/spec-node/dockerCompose.ts)): 1. `COMPOSE_PROJECT_NAME` from the local environment. 2. `COMPOSE_PROJECT_NAME=` in the workspace `.env` file. 3. Top-level `name:` on the merged compose config, when at least one fragment declared it explicitly. 4. `${workspaceFolderBasename}_devcontainer` — only when the first compose file's directory is `<workspace>/.devcontainer/`. 5. Otherwise, the plain basename of the first compose file's directory (no suffix). The old Zed implementation diverged at every one of those inputs: any user setting `COMPOSE_PROJECT_NAME`, shipping a `.env` with one, declaring a top-level compose `name:`, or pointing `dockerComposeFile` outside `.devcontainer/` (e.g. `"../docker-compose.yml"`) got a different project namespace than the CLI and VS Code, producing two compose projects for the same folder. Adds a small `sanitize_compose_project_name()` helper implementing the CLI's rules (lowercase + strip `[^-_a-z0-9]`) — notably preserving hyphens, which `safe_id_lower` would have replaced with underscores. Adds two helpers used by the precedence walk: - `parse_dotenv_compose_project_name` — line scan extracting `COMPOSE_PROJECT_NAME=…` from the workspace `.env`, matching the subset the CLI's regex dotenv reader recognizes. - `compose_fragment_declares_name` — parses each compose fragment with `yaml-rust2` (already a transitive workspace dep; slated to become a direct dep via zed-industries#53922) and checks for a `name` key on the root mapping (block, quoted, or flow style all work), matching the CLI's own `yaml.load`. `docker compose config` always injects `name: devcontainer` into its merged output when no fragment declared one, so rule 3 needs to distinguish the user-provided case from the injected default — this helper supplies that signal. On YAML parse failure it returns "not declared" (rule 4 applies), matching the CLI's fallback. `project_name()` becomes async and fallible (`async fn project_name(&self) -> Result<String, DevContainerError>`) so it can load the `.env` file and each compose fragment via `self.fs.load`. Four call sites now `.await?` the derivation. Real I/O errors on the `.env` read propagate as `FilesystemError` (matching the CLI's narrow `ENOENT`/`EISDIR` swallow); fragment-rescan read errors are logged and skipped (matching the CLI's broader try/catch over its fragment read + parse). The `name` field is still used as the features image-tag prefix (`generate_features_image_tag`); only the compose project namespace is decoupled from it. **Duplicate-container detection (from zed-industries#54068).** When `check_for_existing_container`'s label-based lookup returns more than one match, propagate `MultipleMatchingContainers(ids)` with instructions to clean up the stale one(s). This covers the mixed-version upgrade edge case where a pre-fix Zed left a container under the legacy project name alongside a CLI-style one — transparent to users in the common case (one tool, one container), explicit error when two legacy siblings need manual cleanup. ## Why Full write-up with verified fixtures and captured output: zed-industries#54255. Three failure modes from the same root cause, all resolved by this change: 1. **Interop** — opening a folder in both Zed and `devcontainer up` (or Zed and VS Code) creates two compose projects with identical `devcontainer.local_folder` + `devcontainer.config_file` labels, breaking the spec's uniqueness invariant. 2. **Cross-worktree silent db/volume reuse** — if multiple git worktrees share a `devcontainer.json` with the same `name`, Zed uses the same compose project for all of them; Compose reuses stateful siblings (db, cache, localstack) by config-hash, so worktree B silently inherits worktree A's database. Fixture + captured output: [antont/zed-devcontainer-db-share-repro](https://github.com/antont/zed-devcontainer-db-share-repro). 3. **Mixed-version Zed sessions** — the Rust impl landed in stable v0.232.2 (2026-04-15, zed-industries#52338). Older Zed (≤v0.231.x) shelled out to `@devcontainers/cli` so it used the reference derivation. The collision shows up when a new-Zed-created container exists under the name-field project while a CLI-derivation tool (old Zed, `devcontainer up`, VS Code) operates on the same folder. ## Migration / compatibility Existing Zed-created containers (under the old `safe_id_lower(name)` project) continue to be found via `check_for_existing_container`'s label-based lookup — they're looked up by `devcontainer.local_folder` + `devcontainer.config_file`, not by project name. A user with duplicate legacy containers from a prior Zed session sees `MultipleMatchingContainers` with cleanup instructions. ## Revision — 2026-04-22 Revised per @KyleBarton review on the prior version: - Swapped the YAML parser from `serde_yaml_ng` to `yaml-rust2` (already transitive via `tree-sitter-yaml`; net reduction of one direct workspace dep; also what zed-industries#53922 will pull in). - Dropped the mixed-version tiebreak (`pick_canonical_container`) and its `com.docker.compose.project` serde label. The edge case it covered is transient enough to address via the explicit `MultipleMatchingContainers` error rather than permanent tiebreaking code. - Folded zed-industries#54068's detection commit into this PR; zed-industries#54068 closed unmerged. - Rebased onto `main`. ## Test plan - [x] `cargo test -p dev_container --lib` — 89 passed, including: - `sanitize_compose_project_name_matches_cli_rules` - `--project-name` assertion added to `test_spawns_devcontainer_with_docker_compose` - `check_for_existing_container_errors_when_multiple_match` - `derive_project_name_env_wins_over_everything` - `derive_project_name_dotenv_wins_over_compose_and_fallback` - `derive_project_name_compose_name_wins_over_fallback` - `derive_project_name_skips_compose_name_when_not_explicitly_declared` - `derive_project_name_omits_suffix_when_compose_file_outside_devcontainer_dir` - `derive_project_name_normalizes_compose_path_for_rule_4` - `compose_fragment_declares_name_detects_top_level_name_key` (covers block, quoted-key, and flow-style roots, plus parse failure → not-declared) - `is_missing_file_error_only_accepts_notfound_and_isadirectory` - [x] `cargo fmt --all` — clean - [x] `./script/clippy -p dev_container` — clean - [x] **End-to-end with fixture** [antont/zed-devcontainer-compose-test](https://github.com/antont/zed-devcontainer-compose-test): - Build `zed` from this branch. - Clean slate: `docker ps -a --filter "label=devcontainer.local_folder=$PWD" -q | xargs -r docker rm -f` - `zed --dev-container /path/to/devcontainer-compose-test` → Zed creates container under project `devcontainer-compose-test_devcontainer` (was `compose_duplicate_repro` before the fix). - `devcontainer up --workspace-folder $PWD` → CLI reports the same `containerId` Zed created; no second compose project is introduced. - Captured: `devcontainer-compose-test_devcontainer-app-1`, `composeProjectName: "devcontainer-compose-test_devcontainer"` reported by both tools. Release Notes: - Fixed dev container Docker Compose project name now matches the full `getProjectName` precedence from the reference devcontainer CLI (`COMPOSE_PROJECT_NAME` in the environment, then in the workspace `.env`, then an explicit top-level `name:` on the merged compose config, then the basename of the first compose file's directory — with the `_devcontainer` suffix only when that directory is `<workspace>/.devcontainer`). This prevents duplicate containers when the same folder is opened with both Zed and the devcontainer CLI / VS Code. --------- Co-authored-by: Claude Opus 4.7 <noreply@anthropic.com>

cla-bot Bot added the cla-signed The user has signed the Contributor License Agreement label Apr 16, 2026

zed-codeowner-coordinator Bot requested review from a team, kubkon and reflectronic and removed request for a team April 16, 2026 13:56

zed-codeowner-coordinator Bot assigned kubkon Apr 16, 2026

antont mentioned this pull request Apr 16, 2026

dev_container: Resolve compose dockerfile path relative to build context #53860

Merged

5 tasks

antont marked this pull request as draft April 17, 2026 15:46

reflectronic removed their request for review April 17, 2026 19:12

reflectronic assigned KyleBarton and unassigned kubkon Apr 17, 2026

antont force-pushed the fix-docker-ps-multi-container branch from 8dfcfdf to 07df223 Compare April 18, 2026 11:49

This was referenced Apr 18, 2026

Dev container: compose project name derived from name field diverges from devcontainer CLI / VS Code antont/zed#5

Open

dev_container: Align compose project name with reference CLI and recover from mixed-version duplicates antont/zed#6

Draft

This was referenced Apr 18, 2026

dev_container: Prefer canonical compose project on multi-match antont/zed#7

Merged

Dev container: compose project name derived from name field diverges from devcontainer CLI / VS Code #54255

Closed

antont marked this pull request as ready for review April 19, 2026 10:12

antont changed the title ~~dev_container: Fix docker ps JSON parsing with multi-container compose projects~~ dev_container: Detect error state when docker ps returns duplicate containers Apr 19, 2026

dev_container: Apply cargo fmt

95f3aa6

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>

Merge branch 'main' into fix-docker-ps-multi-container

4d8ca75

antont mentioned this pull request Apr 20, 2026

dev_container: Align compose project name with reference CLI #54302

Merged

9 tasks

antont closed this Apr 22, 2026

Navigation Menu

Uh oh!

Uh oh!

dev_container: Detect error state when docker ps returns duplicate containers - #54068

dev_container: Detect error state when docker ps returns duplicate containers#54068
antont wants to merge 3 commits into
zed-industries:mainfrom
antont:fix-docker-ps-multi-container

antont commented Apr 16, 2026 •

edited

Loading

Uh oh!

KyleBarton commented Apr 16, 2026

Uh oh!

antont commented Apr 16, 2026

Uh oh!

KyleBarton commented Apr 17, 2026

Uh oh!

antont commented Apr 17, 2026 •

edited

Loading

Uh oh!

antont commented Apr 19, 2026

Uh oh!

antont commented Apr 20, 2026

Uh oh!

antont commented Apr 22, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

Uh oh!

Uh oh!

Conversation

antont commented Apr 16, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary

What this PR does

Why detect rather than resolve

Test plan

Uh oh!

KyleBarton commented Apr 16, 2026

Uh oh!

antont commented Apr 16, 2026

Uh oh!

KyleBarton commented Apr 17, 2026

Uh oh!

antont commented Apr 17, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

antont commented Apr 19, 2026

Uh oh!

antont commented Apr 20, 2026

Uh oh!

antont commented Apr 22, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

antont commented Apr 16, 2026 •

edited

Loading

antont commented Apr 17, 2026 •

edited

Loading