src/scope/server/osc_server.py (1)

125-130: Consider sampling unknown-message logs.

A misconfigured OSC sender can hit this branch at message rate, and each event is now written at INFO to both console and rotating file logs. A simple per-address rate limit or summary counter would make the new default much safer operationally.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/scope/server/osc_server.py` around lines 125 - 130, The current
logger.info call for unknown OSC messages (the branch where path_info is None
using logger.info with address and value) can flood logs; implement a
sampling/rate-limit or summary counter keyed by address to reduce spam: add a
small in-memory map (e.g., unknown_msg_counters or last_logged_timestamps)
updated in the message handler that either logs only every Nth event per address
or only once per time window, and increment an aggregated counter for suppressed
events so you can periodically emit a summary log (e.g., "OSC UNKNOWN x
occurrences for %s, last value=%r"). Update the branch that checks path_info is
None to consult this map before calling logger.info and to increment the
suppression counter instead of logging every event.

frontend/src/lib/api.ts (1)

946-965: Return the server-confirmed OSC status from this helper.

PUT /api/v1/osc/settings already returns srv.status(), but this helper drops that payload and forces OscTab.tsx to re-create the state update locally. Returning a typed response would keep the frontend aligned with the backend contract and remove one partial state copy.

♻️ Suggested refactor

 export interface OscSettingsRequest {
   log_all_messages: boolean;
 }
 
+export interface OscStatusResponse {
+  enabled: boolean;
+  listening: boolean;
+  port: number | null;
+  host: string | null;
+  log_all_messages: boolean;
+}
+
 export const updateOscSettings = async (
   settings: OscSettingsRequest
-): Promise<void> => {
+): Promise<OscStatusResponse> => {
   const response = await fetch("/api/v1/osc/settings", {
     method: "PUT",
     headers: { "Content-Type": "application/json" },
     body: JSON.stringify(settings),
   });
@@
   if (!response.ok) {
     const errorText = await response.text();
     throw new Error(
       `Update OSC settings failed: ${response.status} ${response.statusText}: ${errorText}`
     );
   }
+
+  return response.json();
 };

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@frontend/src/lib/api.ts` around lines 946 - 965, The updateOscSettings helper
currently ignores the server response; modify updateOscSettings (which accepts
OscSettingsRequest) to parse and return the typed server payload (the
srv.status() object returned by PUT /api/v1/osc/settings) instead of void so
callers like OscTab.tsx can use the server-confirmed status; keep the same error
handling (throw on !response.ok) but after validating response.ok call await
response.json(), validate/shape it to the expected status type, and return that
parsed object to callers.

src/scope/server/app.py (1)

675-703: Give the new OSC payload a response model.

Both endpoints now define a shared frontend/backend contract, but they still return raw dicts. A small OscStatusResponse model here would make FastAPI validate log_all_messages/host/port and keep the OpenAPI schema in sync with src/scope/server/osc_server.py::status().

♻️ Possible shape

+class OscStatusResponse(BaseModel):
+    enabled: bool
+    listening: bool
+    port: int | None
+    host: str | None
+    log_all_messages: bool
+
-@app.get("/api/v1/osc/status")
+@app.get("/api/v1/osc/status", response_model=OscStatusResponse)
 async def osc_status():
     ...

-@app.put("/api/v1/osc/settings")
+@app.put("/api/v1/osc/settings", response_model=OscStatusResponse)
 async def update_osc_settings(request: OscSettingsRequest):
     ...

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/scope/server/app.py` around lines 675 - 703, Add a FastAPI response model
for the OSC status and use it on both endpoints: define a Pydantic model named
OscStatusResponse matching the keys returned by get_osc_server().status()
(enabled: bool, listening: bool, port: Optional[int], host: Optional[str],
log_all_messages: bool), then annotate the osc_status() and
update_osc_settings() route handlers with response_model=OscStatusResponse;
continue to use get_osc_server() and srv.status() as the source of values but
let FastAPI validate/serialize via the new OscStatusResponse model.