chenhg5/cc-connect · error

init crypto: %w

Error message

init crypto: %w

What it means

This error wraps failures from ch.Init(ctx) during Matrix E2EE setup. Init loads/creates the device account, performs key uploads and device-list syncing with the homeserver. If Init fails and it is not the retryable 'not marked as shared' stale-key case, the helper is cleaned up (cleanupFailedCrypto closes the DB and resets client stores) and this wrapped error propagates.

Source

Thrown at platform/matrix/e2ee.go:215

	if err := ch.Init(ctx); err != nil {
		if !isRetry && strings.Contains(err.Error(), "not marked as shared") {
			slog.Warn("matrix: stale device keys on server, force-uploading new keys")
			func() {
				defer func() { recover() }()
				if mach := ch.Machine(); mach != nil {
					if shareErr := mach.ShareKeys(ctx, -1); shareErr != nil {
						slog.Error("matrix: failed to force-share keys", "error", shareErr)
					}
				}
			}()
			ch.Close()
			client.StateStore = nil
			client.Store = mautrix.NewMemorySyncStore()
			return p.tryInitCrypto(ctx, client, pickleKey, dbPath, true)
		}
		p.cleanupFailedCrypto(client, ch)
		return nil, fmt.Errorf("init crypto: %w", err)
	}
	return ch, nil
}

func (p *Platform) cleanupFailedCrypto(client *mautrix.Client, ch *cryptohelper.CryptoHelper) {
	ch.Close()
	client.StateStore = nil
	client.Store = mautrix.NewMemorySyncStore()
}

// tryEncryptAndSend attempts to encrypt and send an event if E2EE is available.
// Returns (true, nil) if handled, (true, err) if handled with error, (false, nil) if not handled.
func (p *Platform) tryEncryptAndSend(ctx context.Context, client *mautrix.Client, roomID id.RoomID, evtType event.Type, content any) (bool, error) {
	ch := p.getE2EECryptoHelper()
	if ch == nil {
		return false, nil
	}
	if !p.isRoomEncrypted(ctx, roomID) {

View on GitHub (pinned to 4000b2338a)

Solutions

  1. Check the wrapped cause: verify the access token is valid and the homeserver is reachable (curl the /_matrix/client/versions endpoint).
  2. Restart the platform after clearing stale server-side device keys (delete the device via homeserver admin API) so key upload succeeds.
  3. If the 'not marked as shared' retry already fired and failed, remove the local crypto DB (dbPath) and restart for a clean re-upload.
  4. Inspect slog output around the failure for network/HTTP status details; fix connectivity or TLS trust as indicated.
  5. Update mautrix-go/cryptohelper if the failure is a known compatibility issue with your Synapse/Dendrite version.

Example fix

// before
if err := ch.Init(ctx); err != nil {
    return nil, fmt.Errorf("init crypto: %w", err)
}
// after
if err := ch.Init(ctx); err != nil {
    slog.Error("matrix: crypto init failed", "err", err)
    return nil, fmt.Errorf("init crypto: %w", err) // inspect %w cause for HTTP status / token issues
}
Defensive patterns

Strategy: retry

Validate before calling

// Go: pre-check homeserver reachability and token before enabling E2EE
resp, err := http.Get(homeserver + "/_matrix/client/versions")
if err != nil || resp.StatusCode != 200 {
    return fmt.Errorf("homeserver unreachable before crypto init: status=%v err=%v", resp, err)
}

Try / catch

ch, err := initCrypto(ctx, client, key, dbPath)
if err != nil && strings.Contains(err.Error(), "init crypto") {
    // one clean retry with a fresh store
    os.Remove(dbPath)
    ch, err = initCrypto(ctx, client, key, dbPath)
    if err != nil {
        return fmt.Errorf("crypto init failed after retry: %w", err)
    }
}

Prevention

When it happens

Trigger: tryInitCrypto calls ch.Init(ctx) and it returns err that either is a retry (isRetry already true) or does not contain 'not marked as shared' — e.g. homeserver API failures during key upload, WHOAMI/keys/query endpoints returning errors, expired/invalid access token, network timeout, or the stale-key retry path also failing.

Common situations: Homeserver unreachable or returning 401/403 because the access token was revoked; device keys marked as not shared after server DB restore, and the single forced retry also fails; rate limiting on /keys/upload; TLS/certificate problems between the bridge and homeserver.

Understand the failure class

Background: "API error: {status}" and "HTTP 401/403/404/429/5xx" errors: non-2xx HTTP responses explained — this error's family across 27 libraries.

Related errors


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