Breaking change in MusicServer 5.0: sync endpoints are POST only. Fix this before (or together with) deploying the new server, or starting a sync from the player stops working.
What changed on the server
MusicServer (Sansan/MusicServer, develop) changed these endpoints from GET to POST, on both the legacy routes and /api/v1:
/sync, /sync/new, /sync/quick (sync only changes)
/sync/full, /sync/new/full (full sync)
/sync/reset (deletes all soundtracks and songs)
A GET on these paths now returns 404 (the frontend's static files answer it) and does nothing. GET /sync/progress is unchanged.
Starting a sync while one is running returns 423 Locked, same as before.
HttpTransport.request only adds a Content-Type header for PUT. The server doesn't need a body for these POSTs, so no other change is needed.
Tests
Update tests/unit/test_music_server_client.gd so the fake transport asserts start_sync uses METHOD_POST.
Check any test that fakes /sync.
Acceptance criteria
Starting a sync from the player works against MusicServer 5.0
Unit test covers the method
**Breaking change in MusicServer 5.0:** sync endpoints are POST only. Fix this before (or together with) deploying the new server, or starting a sync from the player stops working.
## What changed on the server
MusicServer (Sansan/MusicServer, `develop`) changed these endpoints from GET to POST, on both the legacy routes and `/api/v1`:
- `/sync`, `/sync/new`, `/sync/quick` (sync only changes)
- `/sync/full`, `/sync/new/full` (full sync)
- `/sync/reset` (deletes all soundtracks and songs)
A GET on these paths now returns **404** (the frontend's static files answer it) and does nothing. `GET /sync/progress` is unchanged.
Starting a sync while one is running returns **423 Locked**, same as before.
## Change in MusicPlayer
`server/music_server_client.gd`:
```gdscript
func start_sync(on_done: Callable, on_failed: Callable = Callable()) -> void:
send("/sync", on_done, on_failed, HTTPClient.METHOD_POST)
```
`HttpTransport.request` only adds a `Content-Type` header for PUT. The server doesn't need a body for these POSTs, so no other change is needed.
## Tests
- Update `tests/unit/test_music_server_client.gd` so the fake transport asserts `start_sync` uses `METHOD_POST`.
- Check any test that fakes `/sync`.
## Acceptance criteria
- Starting a sync from the player works against MusicServer 5.0
- Unit test covers the method
Sansan
added the bug label 2026-10-06 16:11:36 +02:00
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Breaking change in MusicServer 5.0: sync endpoints are POST only. Fix this before (or together with) deploying the new server, or starting a sync from the player stops working.
What changed on the server
MusicServer (Sansan/MusicServer,
develop) changed these endpoints from GET to POST, on both the legacy routes and/api/v1:/sync,/sync/new,/sync/quick(sync only changes)/sync/full,/sync/new/full(full sync)/sync/reset(deletes all soundtracks and songs)A GET on these paths now returns 404 (the frontend's static files answer it) and does nothing.
GET /sync/progressis unchanged.Starting a sync while one is running returns 423 Locked, same as before.
Change in MusicPlayer
server/music_server_client.gd:HttpTransport.requestonly adds aContent-Typeheader for PUT. The server doesn't need a body for these POSTs, so no other change is needed.Tests
tests/unit/test_music_server_client.gdso the fake transport assertsstart_syncusesMETHOD_POST./sync.Acceptance criteria
Update:
/sync/new,/sync/quickand/sync/new/fullwere removed from the server. OnlyPOST /syncandPOST /sync/fullexist now.