chenhg5/cc-connect · warning

operation not supported by this platform

Error message

operation not supported by this platform

What it means

ErrNotSupported is the core sentinel meaning the connected platform adapter cannot perform the requested operation. Callers check optional capability maps (e.g. capabilities["update_message"], capabilities["preview"]) and return this error when the adapter is missing or lacks the capability. It lets generic core code degrade gracefully across heterogeneous platforms.

Source

Thrown at core/interfaces.go:48

		}
	}
	if v, ok := m[LangEnglish]; ok && v != "" {
		return v
	}
	return string(key)
}

// Platform abstracts a messaging platform (Feishu, DingTalk, Slack, etc.).
type Platform interface {
	Name() string
	Start(handler MessageHandler) error
	Reply(ctx context.Context, replyCtx any, content string) error
	Send(ctx context.Context, replyCtx any, content string) error
	Stop() error
}

// ErrNotSupported indicates a platform doesn't support a particular operation.
var ErrNotSupported = errors.New("operation not supported by this platform")

// ReplyContextReconstructor is an optional interface for platforms that can
// recreate a reply context from a session key. This is needed for cron jobs
// to send messages to users without an incoming message.
type ReplyContextReconstructor interface {
	ReconstructReplyCtx(sessionKey string) (any, error)
}

// RelayGroupVisibilityTarget is an optional interface for platforms that
// want to customise the session key used when echoing relay request /
// response messages into the group chat for visibility.  Platforms that
// understand the concept of a thread, topic, or sub-conversation can
// return a thread-scoped session key so the visibility echoes land in
// the same conversation that triggered the relay; platforms without
// such a concept simply don't implement this interface and core falls
// back to the legacy "<platform>:<chatID>:relay" target.
//
// Returning (key, true) → core uses key verbatim as the group session

View on GitHub (pinned to 4000b2338a)

Solutions

  1. Check support before calling: verify the platform adapter exposes the capability (capabilities map or optional interface) and skip/hide the feature otherwise.
  2. Handle the sentinel with errors.Is(err, core.ErrNotSupported) and disable the corresponding UI affordance for that platform.
  3. Implement the operation in the platform adapter and register it in its capabilities map if the platform truly supports it.

Example fix

// before
if err := bridge.UpdateMessage(ctx, rc, newContent); err != nil {
    return err
}
// after
if err := bridge.UpdateMessage(ctx, rc, newContent); err != nil {
    if errors.Is(err, core.ErrNotSupported) {
        return bridge.Send(ctx, rc.replyCtx, newContent) // fallback to new message
    }
    return err
}
Defensive patterns

Strategy: fallback

Validate before calling

adapter := getAdapter(platformName)
supported := adapter != nil && adapter.capabilities["update_message"]

Type guard

func supportsUpdateMessage(p core.Platform) bool {
    type cap interface{ Capabilities() map[string]bool }
    c, ok := p.(cap)
    return ok && c.Capabilities()["update_message"]
}

Try / catch

if errors.Is(err, core.ErrNotSupported) {
    // degrade: fall back to sending a new message or hide the feature
}

Prevention

When it happens

Trigger: Calling bridge paths that edit or preview messages (core/bridge.go:515, core/bridge.go:532) when getAdapter(platform) returns nil or the adapter's capabilities map lacks the required key (e.g. update_message, preview).

Common situations: Invoking /edit or message preview on a platform (QQ, LINE, etc.) whose adapter did not declare update_message/preview capability; a stale session referencing a platform adapter that was never registered; cron/delayed reply paths hitting a platform that only supports plain Send.

Related errors

AI-assisted analysis of chenhg5/cc-connect@4000b2338a (2026-09-06). Data as JSON: /api/errors/6608081bec5e1b4f. Report an issue: GitHub.