refactor: drop Desktop beta-settings check; gate hint on LogsTab flag

[glours]

What I did
Docker Desktop is removing the "Enable Logs view" beta setting, so drop the /app/settings check and rely on /features alone. With the setting gate gone, the compose hook subprocess would print the Logs view hint regardless of LogsTab; add a flag check in handleHook. Consolidate engine-label discovery and feature-flag evaluation into internal/desktop.

Related issue

(not mandatory) A picture of a cute animal, if possible in relation to what you did

[docker-agent]

Assessment: 🟢 APPROVE

This is a clean, well-structured refactor. The changes correctly:

• Move engine-label discovery from pkg/compose/desktop.go into internal/desktop.EndpointFromEngine (good consolidation)
• Drop the now-removed /app/settings beta check and rely solely on /features via IsFeatureActive
• Add IsFeatureActiveStandalone for the hook subprocess which has no existing API client
• Gate all hint emission on the LogsTab flag in handleHook before encoding any response
• Stub logsTabEnabled via TestMain so existing tests aren't affected, and add a dedicated TestHandleHook_FeatureFlagDisabledSuppressesHint test for the new gate

No bugs found in the changed code.

[Copilot]

Pull request overview

Refactors Docker Desktop integration gating to rely solely on Desktop feature flags (dropping the removed /app/settings beta setting check), and ensures the compose hook subprocess only emits the Logs view hint when the LogsTab feature flag is enabled.

Changes:

• Centralized Docker Desktop engine-label endpoint discovery and feature-flag evaluation in internal/desktop.
• Updated Compose Desktop integration checks to use the new centralized helpers.
• Gated hook hint emission on the LogsTab feature flag and added coverage to suppress hints when disabled.

Reviewed changes

Copilot reviewed 5 out of 5 changed files in this pull request and generated 2 comments.

Show a summary per file

File	Description
pkg/compose/desktop.go	Switched Desktop endpoint/feature checks to centralized internal/desktop helpers.
internal/desktop/client.go	Removed settings-based gating; added engine-label discovery and feature-flag gating helpers (including standalone mode).
internal/desktop/client_test.go	Removed backend-socket derivation test (function removed); retains integration ping test.
cmd/compose/hooks.go	Added LogsTab feature-flag gating before emitting Logs view hints from hook handler.
cmd/compose/hooks_test.go	Updated tests for new handleHook signature and added test ensuring hints are suppressed when feature flag is disabled.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[glours]

/review

[docker-agent]

Assessment: 🟡 NEEDS ATTENTION

2 medium-severity findings in newly added code. Both concern the lack of a timeout on the logsTabEnabled network call in the hook subprocess — a pattern already established by the adjacent resolveAppID 250 ms guard. No high-severity or correctness bugs found.

[docker-agent]

[MEDIUM] Missing timeout on logsTabEnabled call — hook subprocess may stall

logsTabEnabled calls IsFeatureActiveStandalone, which initializes a full Docker CLI and makes two sequential network calls: apiClient.Info(ctx) (to detect the Desktop engine label) and an HTTP request to the Desktop socket (/features). Neither the http.Client nor any wrapping context has an explicit short deadline.

The context passed in is cmd.Context(), which is a signal-cancellable context with no deadline. By contrast, the adjacent resolveAppID call is already guarded with a 250ms timeout (projectNameResolveTimeout), showing the authors recognized this pattern for latency-sensitive hook paths.

If the Desktop socket is present but slow (e.g., Desktop is starting up), both calls can block for an OS-level socket timeout — potentially several minutes — stalling the hook subprocess and delaying every docker compose up invocation.

Suggested fix: wrap the logsTabEnabled call in the same timeout pattern used for resolveAppID:

tabCtx, cancel := context.WithTimeout(ctx, 250*time.Millisecond)
defer cancel()
if !logsTabEnabled(tabCtx) {
    return nil
}

[docker-agent]

[MEDIUM] IsFeatureActiveStandalone performs blocking Docker CLI init with no context deadline

dockerCli.Initialize(cliflags.NewClientOptions()) does not accept a context, so the CLI initialization phase (config file reads, context resolution) is not cancellable. Subsequent calls (apiClient.Info(ctx) and the HTTP request to the Desktop /features endpoint) do respect the provided ctx, but the http.Client created in NewClient has no Timeout field — it relies entirely on context cancellation.

In the hook subprocess, ctx is cmd.Context() with no deadline, so a connected-but-unresponsive Desktop process can cause the HTTP call to block indefinitely. This is the deeper root cause of the timeout gap flagged at the handleHook call site.

Consider adding a short timeout at the call site (see cmd/compose/hooks.go), or add a defensive http.Client.Timeout to NewClient.