Problem
handleWaitForSync in internal/mcpserver/server.go has an outer time.Now().Before(deadline) loop, but each iteration calls WatchEvents(since) which does a 60-second long poll. If Syncthing is slow to respond, each poll iteration can block for up to 60 seconds, meaning the actual wait time can overshoot timeout_seconds by up to 60s:
for time.Now().Before(deadline) {
st, err := s.client.GetFolderStatus()
...
events, nextID, err := s.client.WatchEvents(since) // blocks up to 60s
...
}With the default 30s timeout, it's possible the loop checks deadline at t=0, starts a 60s long-poll, and doesn't return until t=60.
Fix
Once WatchEvents accepts a context.Context (see related issue), pass a context with the deadline:
ctx, cancel := context.WithDeadline(context.Background(), deadline)
defer cancel()
events, nextID, err := s.client.WatchEvents(ctx, since)
This ensures the long-poll respects the timeout exactly.
Problem
handleWaitForSyncininternal/mcpserver/server.gohas an outertime.Now().Before(deadline)loop, but each iteration callsWatchEvents(since)which does a 60-second long poll. If Syncthing is slow to respond, each poll iteration can block for up to 60 seconds, meaning the actual wait time can overshoottimeout_secondsby up to 60s:With the default 30s timeout, it's possible the loop checks deadline at t=0, starts a 60s long-poll, and doesn't return until t=60.
Fix
Once
WatchEventsaccepts acontext.Context(see related issue), pass a context with the deadline:This ensures the long-poll respects the timeout exactly.