You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In WebSocketTransport the subscribers dictionary is not Atomic and is modified using the processingQueue however it is read in processMessage(text:) function which is called on a different thread by the WebSocketClient. This can lead to a data race if the updates are coming in on the web socket very fast and at the same time new subscriptions are started or stopped.
By adding @Atomic to the subscribers variable, this crash is completely resolved.
While I didn't encounter a crash on subscriptions variable, I suspect the same can happen there.
Version
1.16.1
Steps to reproduce the behavior
This is tough because for us it only happened during a really high load scenario where we were receiving tens of messages per second on the web socket and a lot of those messages also resulted in our code stopping and starting subscriptions.
We have seen this crash happen on production as well. The crash shows up as EXC_BAD_ACCESS KERN_INVALID_ADDRESS
Logs
Anything else?
No response
The text was updated successfully, but these errors were encountered:
Do you have any feedback for the maintainers? Please tell us by taking a one-minute survey. Your responses will help us understand Apollo iOS usage and allow us to serve you better.
Summary
In
WebSocketTransport
thesubscribers
dictionary is notAtomic
and is modified using theprocessingQueue
however it is read inprocessMessage(text:)
function which is called on a different thread by theWebSocketClient
. This can lead to a data race if the updates are coming in on the web socket very fast and at the same time new subscriptions are started or stopped.By adding
@Atomic
to thesubscribers
variable, this crash is completely resolved.While I didn't encounter a crash on
subscriptions
variable, I suspect the same can happen there.Version
1.16.1
Steps to reproduce the behavior
This is tough because for us it only happened during a really high load scenario where we were receiving tens of messages per second on the web socket and a lot of those messages also resulted in our code stopping and starting subscriptions.
We have seen this crash happen on production as well. The crash shows up as
EXC_BAD_ACCESS KERN_INVALID_ADDRESS
Logs
Anything else?
No response
The text was updated successfully, but these errors were encountered: