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
- Check the wrapped cause: verify the access token is valid and the homeserver is reachable (curl the /_matrix/client/versions endpoint).
- Restart the platform after clearing stale server-side device keys (delete the device via homeserver admin API) so key upload succeeds.
- If the 'not marked as shared' retry already fired and failed, remove the local crypto DB (dbPath) and restart for a clean re-upload.
- Inspect slog output around the failure for network/HTTP status details; fix connectivity or TLS trust as indicated.
- 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
- Rotate access tokens before expiry and re-deploy rather than letting them lapse mid-run.
- Keep the crypto DB persistent across restarts to avoid repeated stale-key uploads.
- Verify homeserver TLS certificates are trusted by the bridge container.
- Watch for /keys/upload rate limits on large deployments and stagger key uploads.
- Keep mautrix-go and cryptohelper versions aligned with your homeserver release.
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
- device ID not available from whoami
- get home dir: %w
- create data dir: %w
- create crypto helper: %w
- matrix: encrypt: %w
AI-assisted analysis of chenhg5/cc-connect@4000b2338a (2026-09-06).
Data as JSON: /api/errors/327a15d4d0b78be6.
Report an issue: GitHub.