chenhg5/cc-connect · error

matrix: init verification: %w

Error message

matrix: init verification: %w

What it means

initVerification wraps a failure from VerificationHelper.Init(ctx) with "matrix: init verification: %w". The helper initializes olm/megolm session handling and registers event handlers for interactive device verification; a failure here means the crypto machine or its state store rejected initialization. The original error is preserved in the wrap.

Source

Thrown at platform/matrix/verification.go:222

	// Wrap the client's actual HTTP transport. We must use client.Client directly
	// (not p.httpClient) because cryptohelper.Init() may have replaced client.Client
	// with a new http.Client instance.
	if client.Client == nil {
		return fmt.Errorf("matrix: client http.Client is nil")
	}
	base := client.Client.Transport
	if base == nil {
		base = http.DefaultTransport
	}
	client.Client.Transport = &encryptingTransport{base: base, p: p}
	slog.Info("matrix: transport wrapped for verification encryption")

	callbacks := &verificationCallbacks{platform: p}
	helper := verificationhelper.NewVerificationHelper(client, ch.Machine(), nil, callbacks, false, false, true)

	if err := helper.Init(ctx); err != nil {
		return fmt.Errorf("matrix: init verification: %w", err)
	}

	p.setVerificationHelper(helper)
	slog.Info("matrix: verification helper initialized and event handlers registered")
	return nil
}

// handleVerificationMAC works around a mautrix library bug where
// onVerificationMAC uses GetOwnCrossSigningPublicKeys() instead of the other
// user's cross-signing keys for cross-user verification. This causes "unknown
// key ID" errors when verifying devices belonging to a different user.
//
// Instead of dispatching the MAC event to the buggy handler, we trust the
// device directly and send a verification done event. The SAS emoji comparison
// already proved both sides share the same secret, so this is safe for
// auto-verify bots.
func (p *Platform) handleVerificationMAC(ctx context.Context, client *mautrix.Client, ch *cryptohelper.CryptoHelper, evt *event.Event) {
	// Extract transaction ID (already fixed by CustomPostDecrypt to be the request event ID)

View on GitHub (pinned to 4000b2338a)

Solutions

1. Read the wrapped cause (%w) in logs to identify the underlying failure
2. Verify the crypto store path is writable and not locked by another process
3. If the store is corrupt, back it up and remove it so keys are re-created (devices will need re-verification)
4. After a library upgrade, check for store schema migration notes; downgrade or migrate the store accordingly

// check store accessibility before init
if f, err := os.OpenFile(storePath, os.O_RDWR, 0o600); err != nil {
    // crypto store not usable
} else { f.Close() }

if err := helper.Init(ctx); err != nil {
    slog.Error("matrix: verification helper init failed", "cause", errors.Unwrap(err))
    return fmt.Errorf("matrix: init verification: %w", err)
}

When it happens

Trigger: helper.Init(ctx) returns an error — typically because the OlmMachine's crypto store is inaccessible/corrupt, keys cannot be loaded, or the client is not properly synced — inside initVerification.

Common situations: SQLite/sql crypto store file locked by another cc-connect instance; corrupted crypto store after an unclean shutdown; mismatched store schema after a library upgrade; account keys not found because the store directory was moved or deleted.

Related errors

• create crypto helper: %w
• matrix: client not available
• device ID not available from whoami
• get home dir: %w
• create data dir: %w

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