Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Run PR #1823 in loop #1827

Closed
wants to merge 15 commits into from
Closed

Run PR #1823 in loop #1827

wants to merge 15 commits into from

Conversation

lawrence-forooghian
Copy link
Collaborator

To gather data to see if #1823 has increased test failures.

I’m going to need to change this test in an upcoming commit and want the
original intent to be clear before I do.
The use of the non-completing authCallback already ensures a timeout.
Want to add a new test with another failure reason.
RTN14d says that a transport error should be considered recoverable if
it is

> a network failure, a timeout such as RTN14c, or a disconnected
> response, other than a token failure RTN14b)

However, it does not define what it means by a "network failure",
leading to each platform having to provide its own interpretation.

In particular, a client recently told us that they’ve been seeing lots
of OSStatus 9806 (errSSLClosedAbort) errors. This appears to indicate
some sort of failure to perform an SSL handshake. We don’t understand
the cause of this issue but we noticed that it was causing the client to
transition to the FAILED state.

Speaking to Paddy, he said that this error should be provoking a
connection retry, not failure. And more broadly, he indicated that,
basically, _all_ transport errors should be considered recoverable. So,
that’s what we do here. He’s raised a specification issue [1] for us to
properly specify this and to decide if there are any nuances to
consider, but is keen for us to implement this broad behaviour in
ably-cocoa ASAP to help the customer experiencing the errSSLClosedAbort
errors.

Resolves #1817.

[1] ably/specification#171
This is so that we can see things like library logs, or any additional
logging we might add to help debug a test case.
… GitHub job running time limit

I’m trying to understand the reason that the upload artifacts step is
hung here [1], and I’m wondering if it’s because the job execution limit had
already been reached by my script.

[1] https://github.com/ably/ably-cocoa/runs/5979297645?check_suite_focus=true
To help with understanding issue described in 39ab787.
I’m hoping this will reduce the upload time (more by reducing the number
of files than the size).
This lets us choose the length and parallelism of our test runs.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

1 participant