fix(desktop): conversation title edit hits nonexistent endpoint, never saves

[the-scott-davis]

Problem

Editing a conversation title in the macOS desktop app silently fails and the title never persists. The same edit on mobile works.

Root cause

APIClient.updateConversationTitle sent PATCH /v1/conversations/{id} with the title in a JSON body. The Python backend has no such route. The only title route is PATCH /v1/conversations/{id}/title with the title as a query param (backend/routers/conversations.py:177), which the Flutter app already calls (app/lib/backend/http/api/conversations.dart:146). The desktop request 404s, the guard throws APIError.httpError, and the edit is lost.

Fix

Point the desktop call at /v1/conversations/{id}/title with the title as a query item, matching the backend contract and the mobile client. Uses URLComponents so the title is percent-encoded. Removes the unused TitleUpdate body struct.

Testing

Edited a conversation title in the desktop app and confirmed it persists across a refresh.

[greptile-apps]

Greptile Summary

This PR fixes a silent failure when editing a conversation title in the macOS desktop app by correcting the API call to match the actual backend contract and the existing Flutter mobile client.

• Wrong endpoint corrected: updateConversationTitle was calling PATCH /v1/conversations/{id} with a JSON body; it now calls PATCH /v1/conversations/{id}/title with title as a query parameter, matching the Python backend route and the Flutter client's implementation.
• Proper encoding: URLComponents is used to percent-encode the title, and the now-unused TitleUpdate struct is removed.
• Changelog updated: A brief entry is added under unreleased in desktop/CHANGELOG.json.

Confidence Score: 5/5

Minimal, targeted fix that aligns the desktop client with the documented backend route — safe to merge.

The change is a two-line correction: the URL path gains /title and the title moves from a JSON body to a percent-encoded query parameter. The approach is consistent with the existing URLComponents usage in the file, mirrors the Flutter mobile client exactly, and removes dead code. The one pre-existing style note (sending Content-Type: application/json on a body-less request) is systemic throughout APIClient.swift and not introduced here.

No files require special attention; both changed files are straightforward.

Important Files Changed

Filename	Overview
desktop/Desktop/Sources/APIClient.swift	Fixes updateConversationTitle to call /v1/conversations/{id}/title with a title query param via URLComponents (for proper percent-encoding) instead of the non-existent PATCH /v1/conversations/{id} JSON-body route; removes the unused TitleUpdate struct.
desktop/CHANGELOG.json	Adds a changelog entry under unreleased for the conversation title fix.

Sequence Diagram

sequenceDiagram
    participant Desktop as macOS Desktop App
    participant API as APIClient.swift
    participant Backend as Python Backend

    note over Desktop,Backend: Before fix (broken)
    Desktop->>API: updateConversationTitle(id, title)
    API->>Backend: "PATCH /v1/conversations/{id} Body: {"title": "..."}"
    Backend-->>API: 404 Not Found (no such route)
    API-->>Desktop: throws APIError.httpError(404)
    note over Desktop: Title silently lost

    note over Desktop,Backend: After fix (working)
    Desktop->>API: updateConversationTitle(id, title)
    API->>Backend: "PATCH /v1/conversations/{id}/title?title=..."
    Backend-->>API: 200 OK
    API-->>Desktop: success — title persists

Loading

_{Reviews (1): Last reviewed commit: "desktop: changelog - conversation title ..." | Re-trigger Greptile}

[greptile-apps]

Content-Type: application/json on a body-less PATCH

buildHeaders always injects "Content-Type": "application/json", but this request no longer sends a body. Sending Content-Type: application/json with an empty body is technically incorrect and could confuse proxies or strict middleware. This pattern is already widespread in APIClient.swift (e.g., the starred PATCH on line 327), so it's a pre-existing issue not introduced here, but worth noting while the endpoint contract is being corrected.