Delete unnecessary recover error test #1291
Conversation
The test removed in this commit expects that using an invalid recovery key leads to an ERROR protocol message being returned which thus fails the connection, but this isn't part of the spec, we make no guarantee that invalid recovery keys are rejected, and in fact returning a CONNECTED protocol message with the error field indicating the recovery key was invalid is a perfectly good response, which is in fact what we will start to do in the future. The functionality that an ERROR protocol message is treated as fatal and fails the connection is still tested elsewhere, so rmeoving this test doesn't materially reduce the amount of test coverage. Signed-off-by: Lewis Marshall <[email protected]>
There was a problem hiding this comment.
Btw, this test is related to spec https://sdk.ably.com/builds/ably/specification/main/features/#RTN15c4. Are we planning to remove spec since we are deleting related integration tests?
For clarity, here's what that spec point says:
That is still valid, if the server sends an ERROR message then it should be handled as this spec point describes, but the test deleted in this PR is making a connection with an invalid connection key and expecting that to trigger an ERROR which will no longer happen in the future, it will instead get a CONNECTED message with an error field and thus the test won't pass. |
Then can please you suggest some sort of test for the missing spec. I mean I don't want spec implementation without related test |
|
@sacOO7 yes agreed, I'll follow up with a suggestion but going to merge this to avoid blocking other work, thanks. |
The test removed in this commit expects that using an invalid recovery key leads to an ERROR protocol message being returned which thus fails the connection, but this isn't part of the spec, we make no guarantee that invalid recovery keys are rejected with an ERROR, and in fact returning a CONNECTED protocol message with the error field indicating the recovery key was invalid is a perfectly good response, which is in fact what we will start to do in the future.
The functionality that an ERROR protocol message is treated as fatal by the SDK and fails the connection is still tested elsewhere, so removing this test doesn't materially reduce the amount of test coverage.