chenhg5/cc-connect · error
failed to update field %q (may be read-only or invalid type)
Error message
failed to update field %q (may be read-only or invalid type)
What it means
UpdateJob applies the field change through cs.store.Update, which returns false when the field name is unknown, read-only, or the value has the wrong type for the field. The scheduler surfaces this as a wrapped error naming the offending field so callers know the persisted job was not modified.
Source
Thrown at core/cron.go:598
}
}
// Check if reschedule is needed
needsReschedule := field == "cron_expr" || field == "enabled"
if needsReschedule {
// Remove current schedule
cs.mu.Lock()
if entryID, ok := cs.entries[id]; ok {
cs.cron.Remove(entryID)
delete(cs.entries, id)
}
cs.mu.Unlock()
}
// Update the field
if !cs.store.Update(id, field, value) {
return fmt.Errorf("failed to update field %q (may be read-only or invalid type)", field)
}
// Reschedule if needed
if needsReschedule {
updatedJob := cs.store.Get(id)
if updatedJob != nil && updatedJob.Enabled {
if err := cs.scheduleJob(updatedJob); err != nil {
return fmt.Errorf("reschedule failed: %w", err)
}
}
}
return nil
}
func (cs *CronScheduler) Store() *CronStore {
return cs.store
}View on GitHub (pinned to 4000b2338a)
Solutions
- Check the field name spelling against the supported set (e.g. "cron_expr", "enabled", "prompt")
- Ensure the value type matches the field (string for cron_expr/prompt, bool for enabled)
- Inspect store.Update to confirm the field is writable before calling
- Log the returned error with job id and field for diagnosis
Example fix
// before cs.UpdateJob(id, "cronExpr", expr) // wrong field name // after cs.UpdateJob(id, "cron_expr", expr)
Defensive patterns
Strategy: validation
Validate before calling
var validFields = map[string]bool{"cron_expr": true, "enabled": true, "prompt": true}
if !validFields[field] { return fmt.Errorf("unsupported field %q", field) } Try / catch
if err := cs.UpdateJob(id, field, val); err != nil {
if strings.Contains(err.Error(), "failed to update field") {
slog.Warn("cron edit rejected", "field", field, "err", err)
}
} Prevention
- Keep a single canonical list of editable field names shared by handler and store
- Validate user-supplied flag names against that list before calling UpdateJob
When it happens
Trigger: Calling UpdateJob(id, field, value) with a field name that does not exist on the job struct (typo like "cronExpr" instead of "cron_expr"), a read-only field (e.g. "id"), or a value whose type mismatches the field's stored type for non-validated fields.
Common situations: A command handler maps user-supplied flag names directly to field names; a config or plugin passes an outdated field name after a schema rename.
Understand the failure class
Background: "Must be a positive integer", "Invalid value", "Unsupported": the invalid-argument-value error family, when a library rejects the value you pass — this error's family across 35 libraries.
Related errors
- %s must be true or false
- timeout_mins must be >= 0
- unknown or invalid field: %s
- invalid cron expression %q: %w
- job %q not found
AI-assisted analysis of chenhg5/cc-connect@4000b2338a (2026-09-06).
Data as JSON: /api/errors/42ddb3551e000326.
Report an issue: GitHub.