chenhg5/cc-connect · error
timer not found
Error message
timer not found
What it means
HTTP 404 response from the timer-info API endpoint: an `id` was supplied but the timer store's Get returned nil, meaning no timer job with that ID exists (already fired, deleted, or never created).
Source
Thrown at core/api.go:721
func (s *APIServer) handleTimerInfo(w http.ResponseWriter, r *http.Request) {
if r.Method != http.MethodGet {
http.Error(w, "GET only", http.StatusMethodNotAllowed)
return
}
if s.timer == nil {
http.Error(w, "timer scheduler not available", http.StatusServiceUnavailable)
return
}
id := r.URL.Query().Get("id")
if id == "" {
http.Error(w, "id is required", http.StatusBadRequest)
return
}
job := s.timer.Store().Get(id)
if job == nil {
http.Error(w, "timer not found", http.StatusNotFound)
return
}
apiJSON(w, http.StatusOK, job)
}
func (s *APIServer) handleTimerDel(w http.ResponseWriter, r *http.Request) {
if r.Method != http.MethodPost {
http.Error(w, "POST only", http.StatusMethodNotAllowed)
return
}
if s.timer == nil {
http.Error(w, "timer scheduler not available", http.StatusServiceUnavailable)
return
}
var req struct {
ID string `json:"id"`View on GitHub (pinned to 4000b2338a)
Solutions
- List current timer jobs first and confirm the id exists before querying info
- Re-create the timer job if the server restarted (in-memory store)
- Check for typos or whitespace in the id
- Handle 404 in the client by refreshing the job list instead of retrying the same id
Example fix
// before GET /api/timer/info?id=stale-id // 404 // after GET /api/timer/list // confirm valid id, then GET /api/timer/info?id=<valid-id>
Defensive patterns
Strategy: fallback
Validate before calling
const list = await (await fetch('/api/timer/list')).json();
if (!list.some(j => j.id === id)) throw new Error(`timer ${id} does not exist`); Try / catch
try { const job = await getTimerInfo(id); } catch (e) { if (e.status === 404) { refreshJobList(); return null; } throw e; } Prevention
- Refresh the job list after any delete or server restart before reusing ids
- Assume the timer store is in-memory and non-durable across restarts
- Never hardcode timer ids
When it happens
Trigger: Requesting timer info with an id that was never created, already deleted via timer-del, or from a previous server run whose in-memory timer store was reset.
Common situations: Stale ids cached in a client after a server restart (timer store is not durable); double-delete races; typos in the id.
Understand the failure class
Background: 'Could not be found', 'does not exist', 'not found in database': the resource-not-found family when an ID, slug, key, or URI lookup comes back empty — this error's family across 20 libraries.
Related errors
- timer scheduler not available
- cron job not found
- cron project not found
- pi: session %q not found
- no session found for project %q with key %q
AI-assisted analysis of chenhg5/cc-connect@4000b2338a (2026-09-06).
Data as JSON: /api/errors/b156610697b3a5ec.
Report an issue: GitHub.