chenhg5/cc-connect · error
resolve cron reply target: %w
Error message
resolve cron reply target: %w
What it means
When a cron job is not muted, the engine optionally asks the platform to resolve a better reply target via the CronReplyTargetResolver interface (e.g. pick the right thread/topic for the run). If the resolver returns an error that is not ErrNotSupported (which would be tolerated and fall back to ReconstructReplyCtx), the engine aborts with 'resolve cron reply target: %w'. This means the platform tried to resolve the cron reply target and genuinely failed — not that it lacks support.
Source
Thrown at core/engine.go:1514
}
if targetPlatform == nil {
return fmt.Errorf("platform %q not found for session %q", platformName, sessionKey)
}
rc, ok := targetPlatform.(ReplyContextReconstructor)
if !ok {
return fmt.Errorf("platform %q does not support proactive messaging (cron)", platformName)
}
runSessionKey := sessionKey
var replyCtx any
var err error
if !job.Mute {
if resolver, ok := targetPlatform.(CronReplyTargetResolver); ok {
resolvedSessionKey, resolvedReplyCtx, err := resolver.ResolveCronReplyTarget(sessionKey, cronRunTitle(job))
if err != nil {
if !errors.Is(err, ErrNotSupported) {
return fmt.Errorf("resolve cron reply target: %w", err)
}
} else {
if resolvedSessionKey != "" {
runSessionKey = resolvedSessionKey
}
if resolvedReplyCtx != nil {
replyCtx = resolvedReplyCtx
}
}
}
}
if replyCtx == nil {
replyCtx, err = rc.ReconstructReplyCtx(runSessionKey)
if err != nil {
return fmt.Errorf("reconstruct reply context: %w", err)
}
}
View on GitHub (pinned to 4000b2338a)
Solutions
- Unwrap the cause with errors.Is/As on the returned error to see the underlying platform failure; fix that first (auth, scope, deleted target).
- Verify the cron job's session key still points at an existing chat/thread the bot can access.
- Re-create the cron job against a currently valid session (send a message in the target chat and re-register the cron).
- If the platform genuinely cannot resolve for this job type, it should return ErrNotSupported so the engine falls back to ReconstructReplyCtx — check the adapter is returning that sentinel correctly for unsupported cases.
- Check platform token scopes for the channel/thread the resolver targets.
Example fix
// before: resolver returns a hard error for a missing thread
func (p *Platform) ResolveCronReplyTarget(key, title string) (string, any, error) {
th, err := p.findThread(key)
if err != nil { return "", nil, err } // aborts the whole cron run
// after: signal not-supported so the engine falls back gracefully
th, err := p.findThread(key)
if err != nil {
return "", nil, fmt.Errorf("resolve thread: %w: %v", core.ErrNotSupported, err)
} Defensive patterns
Strategy: try-catch
Validate before calling
// Go: pre-flight the resolver before registering the cron job
if r, ok := platform.(core.CronReplyTargetResolver); ok {
if _, _, err := r.ResolveCronReplyTarget(sessionKey, "preflight"); err != nil && !errors.Is(err, core.ErrNotSupported) {
log.Printf("cron target unresolvable: %v", err)
}
} Type guard
resolver, ok := targetPlatform.(core.CronReplyTargetResolver); if !ok { /* engine falls back to ReconstructReplyCtx */ } Try / catch
if err := engine.ExecuteCronJob(job); err != nil {
if strings.Contains(err.Error(), "resolve cron reply target") {
slog.Error("cron reply target resolution failed; check thread/chat still exists and bot scopes",
"job", job.ID, "err", err)
}
} Prevention
- Re-create cron jobs after migrating workspaces so session keys stay valid.
- Ensure the bot token has the scopes required to look up the target channel/thread.
- In adapters, return core.ErrNotSupported (wrapped) for unresolvable-but-tolerable cases instead of hard errors.
- Periodically validate that cron target threads/chats still exist; delete jobs pointing at deleted threads.
When it happens
Trigger: targetPlatform implements CronReplyTargetResolver; resolver.ResolveCronReplyTarget(sessionKey, cronRunTitle(job)) returns a non-ErrNotSupported error — e.g. its internal API call to find the target thread/chat fails, the session key is malformed for that platform, or auth fails during resolution.
Common situations: Slack/Feishu-style adapters whose resolver must look up a thread via API and the API call 404s because the thread was deleted; session keys persisted before a workspace migration; bot token lacking scope to resolve the target channel.
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
- cron job not found
- cron project not found
- %s must be true or false
- timeout_mins must be an integer
- session_key is required
AI-assisted analysis of chenhg5/cc-connect@4000b2338a (2026-09-06).
Data as JSON: /api/errors/f887ad02750bfecb.
Report an issue: GitHub.