RTN17b #385
RTN17b #385
Conversation
ricardopereira
force-pushed
the
rtn17b
branch
2 times, most recently
from
a6aeb04 to
7cd2470
Compare
ricardopereira
force-pushed
the
rtn17b
branch
2 times, most recently
from
4084f7f to
41f5f93
Compare
|
PTAL. I had to switch from SwiftWebSocket to PocketSocket to be able to inspect which kind of error the websocket connection is failing with. SwiftWebSocket uses a Swift enum for this, which can't be used from Objective-C. Originally I tried to add some Swift to our Objective-C codebase to do the bridging, but Xcode gave me a extremely hard time with this, so I gave up. Forking SwiftWebSocket to add Objective-C support is another possibility, but that would've required fighting against Swift's way of doing things from inside a Swift project, so I decided to just use a Objective-C library. |
|
LGTM but it's not passing. |
|
@ricardopereira Not yet. The switch to PocketSocket unveiled a few things that are wrong that were working basically by chance. We need some of the changes in ably/docs#112 for this, will do that first. |
tcard
force-pushed
the
rtn17b
branch
2 times, most recently
from
708a69f to
c5845c7
Compare
|
What's the status on this? |
|
@mattheworiordan I'm about to try to reproduce why the Travis build stalls with this. |
tcard
force-pushed
the
rtn17b
branch
5 times, most recently
from
f06dd4b to
f1baf62
Compare
- to be used with both TestProxyHTTPExecutor and TestProxyTransport
I had to switch from SwiftWebSocket to PocketSocket to be able to inspect which kind of error the websocket connection is failing with. SwiftWebSocket uses a Swift enum for this, which can't be used from Objective-C.
tcard
force-pushed
the
rtn17b
branch
2 times, most recently
from
735fd24 to
6cda49e
Compare
|
Sitrep: this might be the worst case of Works On My Machine™ I've encountered so far. The whole test suite works on my machine. I've already implemented #387, #388, #389 and #390 on top of this and they also work. I've implemented MessagePack encoding on top of this: also works. So the only thing missing now is pretty much to have this stop crashing on Travis. Since there doesn't seem to be a way of looking into stdout from Travis, I've tried to get some insight into what's going on by capturing every single line of logging, sending it in a HTTP request to a server, and writing them there. But I can't spot anything wrong from the logs; it just seems to stall at some random point. I'll try to add some more external monitoring. Any idea would be appreciated. |
|
Is this since PocketRocket change? |
|
@tcard Change the |
|
Something like: |
|
@mattheworiordan Yes, although it was still happening with SocketRocket. I need one or the other to implement this spec line, as explained above. Now it works. There's only one test failing, unrelated to this PR (I'll fix it separately). I don't know what changed, but it's passed consistently a few times now. Maybe PocketSocket was broken, and since the switch to SocketRocket it was just a coincidence with some other condition? Anyway, it's so annoying that it's so hard to get better diagnostics. Please confirm I can merge this. |
👍 |
I've tested the ARTOSReachability "live" manually (by switching on/off the real Internet connection on my machine) and it works as expected, but it needs #385 to properly handle transport errors.
* Test suite: removed Custom case from NetworkAnswer - to be used with both TestProxyHTTPExecutor and TestProxyTransport * Test suite: replaceMethod * TestProxyTransport can now mock network answers * RTN17b * RTN17b: pending * Replace SwiftWebSocket -> PocketRocket. * Fix RTN17b. I had to switch from SwiftWebSocket to PocketSocket to be able to inspect which kind of error the websocket connection is failing with. SwiftWebSocket uses a Swift enum for this, which can't be used from Objective-C. * Use upstream PocketSocket. * Small fix in test. * Switch back to SocketRocket. PocketSocket seems to be kind of buggy. * Queue messages when CONNECTED but renewing token. * Logging: always log memory address of current ARTRealtime instance.
I've tested the ARTOSReachability "live" manually (by switching on/off the real Internet connection on my machine) and it works as expected, but it needs #385 to properly handle transport errors.
I've tested the ARTOSReachability "live" manually (by switching on/off the real Internet connection on my machine) and it works as expected, but it needs #385 to properly handle transport errors.
No description provided.