Stuck on an issue?

I’ve noticed that it’s possible for the Java Bayeux Client to send a /meta/disconnect message without a clientId.

According to the protocol documentation, a /meta/disconnect message must include a clientId.

Steps to Reproduce

• Ask the client to handshake and then immediately attempt to disconnect.

client.handshake();
client.disconnect();

Expected Result

• I’d expect the handshake() call to make the client enter into the handshaking session state and send a meta/handshake message.

• I’d expect the following immediate disconnect() call to make the client enter into either the disconnecting or terminating state and not send a /meta/disconnect message since the client doesn’t yet have a clientId to include in the message.

Actual Result

• The handshake() call makes the client enter into the handshaking session state and send a meta/handshake message.

• The following immediate disconnect() call makes the client enter into the disconnecting state and send a /meta/disconnect message without a clientId.

Additional Information

Looking at the code, it’s currently legal for the client to transition directly from handshaking to disconnecting state:

private boolean isUpdateableTo(State newState) {
    switch (this) {
        case DISCONNECTED:
            return newState == HANDSHAKING;
        case HANDSHAKING:
        case REHANDSHAKING:
            return EnumSet.of(REHANDSHAKING, HANDSHAKEN, DISCONNECTING, TERMINATING).contains(newState);
        case HANDSHAKEN:
            return EnumSet.of(CONNECTING, DISCONNECTING, TERMINATING).contains(newState);
        case CONNECTING:
        case CONNECTED:
        case UNCONNECTED:
            return EnumSet.of(REHANDSHAKING, CONNECTED, UNCONNECTED, DISCONNECTING, TERMINATING).contains(newState);
        case DISCONNECTING:
            return newState == TERMINATING;
        case TERMINATING:
            return newState == DISCONNECTED;
        default:
            throw new IllegalStateException();
    }
}

I wonder if transitioning from handshaking or rehandshaking directly to disconnecting should be an illegal transition. Instead, maybe the client should transition directly to terminating since the client can’t have a clientId when handshaking and may not have a clientId when rehandshaking. (Side note – would it make sense to always clear the clientId before rehandshaking anyway)?

Alternatively, maybe the disconnecting state could skip sending the /meta/disconnect message if the client is coming from handshaking or rehandshaking states. This would likely require updating the documentation for the disconnecting state since it currently implies that a disconnect message will be sent in this state.

/**
* State assumed when the disconnect is being sent
*/
DISCONNECTING,