HTTP PUT /api/save returns success when no configuration file is saved

[robotlearning123]

Bug description

In Open Ephys GUI v1.1.0, PUT /api/save does not provide a reliable machine-readable indication that a configuration file was actually written.

The v1.1.0 handler has two problematic paths:

• If the requested target already exists, it returns HTTP 200 with an informational JSON message instead of a conflict/error status.
• For a new target, XmlElement::writeTo() computes success or failure, but that result message is discarded. Both write success and write failure return HTTP 200 with the serialized configuration XML in info.

Source: OpenEphysHttpServer.h at v1.1.0.

This means an HTTP client cannot distinguish "configuration saved" from "nothing was written" without separately inspecting the GUI host filesystem.

Reproduction

With Open Ephys GUI v1.1.0 running:

1. Send PUT /api/save with JSON such as {"filepath":"C:/path/to/existing.xml"} where the target already exists.
2. Observe that the response status is HTTP 200 even though the file is not overwritten.
3. Send the same request with a new path that cannot be written (for example, an unavailable/unwritable parent).
4. The handler again returns HTTP 200 with configuration XML, even when writeTo() returns false.

I identified this through source-level audit; I have not yet performed the reproduction on the lab acquisition hardware. The behavior is independent of a Neuropixels device, but I want to state that verification boundary explicitly.

Expected behavior

Only an actual successful write should return HTTP 200. Existing-target and write-failure cases should return distinct non-2xx statuses with a machine-readable JSON error. The current no-overwrite policy should remain unchanged.

For compatibility, a successful response could retain the existing info XML while also returning an explicit success value and the resolved filepath. Exact response names/statuses should follow maintainer preference.

Environment

• Open Ephys GUI: v1.1.0 source/tag
• OS for planned reproduction and fix verification: Windows 11
• Plugin-specific behavior: none

Contribution intent

If this direction is acceptable, we can submit a focused test-first fix against development, without adding agent/MCP functionality to the upstream PR. The proposed implementation would separate request/result handling for unit tests and avoid the current asynchronous stack-reference captures in this route.