80018: Invalid connection key

A client tried to re-use a previous connection ID with a connection key, but the key was not in a valid format, so it could not keep that connection ID and was given a new one.

What you should do

The connection itself is fine: the client still connects, just with a new connection ID rather than continuing the previous one. The one effect to be aware of is presence, where a member is identified by its connection ID, so the client re-enters as a new member.

Whether to act depends on the SDK. With a current SDK, the key is one the SDK manages itself while resuming a dropped connection, so a malformed one is unexpected and points to a problem in the SDK rather than your configuration. Supplying a recovery key yourself, through the recover option, applies only to older SDKs; there, an invalid key means recovery never succeeds, so confirm it is stored and restored intact, not truncated, re-encoded, or replaced.

Why it happens

The connection key supplied could not be parsed. This is a structural problem with the value itself: the wrong string, a corrupted one, or one altered in transit or storage, rather than a key that is merely too old. A valid key whose connection has expired is reported as 80008 instead. The same malformed key supplied on a REST publish is reported as 40006, because there the request fails rather than continuing on a fresh connection.

What you'll see

The error is reported with code 80018 and HTTP status 400, with a message of the form invalid connection key. When it occurs while recovering or resuming a connection, the connection reaches the connected state but with a new connection ID, rather than continuing the previous one.