Apparently Fabric Beta can sometimes have some internal error where it cannot resend invites. But then five minutes later (just now) when I went back it did work. During the time it fails and gives the flash/toast/popup error in the title, there's nothing else that tells the user what they can do about it. I guess if I have a question it would be, is this something Fabric will fix UX wise?
Related
We are sending lots and lots of FCM Messages to our millions of users. As the message is triggered by an external event (Kick off in a football match) we sent many messages at the same time.
Sometimes the sending of an FCM message fails and we get an error message like this:
<H1>302 Moved</H1> The document has moved
<A HREF="https://fcm.googleapis.com/batch?
google_abuse=GOOGLE_ABUSE_EXEMPTION%3DID%....3B+expires%3DTue,+22-Nov-
2022+19:04:17+GMT">here</A>. </BODY></HTML>
(I removed some text for privacy reasons.)
For sending the messages we use
implementation 'com.google.firebase:firebase-admin:9.1.0'
We got thousands of error messages like this in one minute. In the next minute everthing worked fine again.
I have search the internet for information about it. But i couldn't find any abuse rules for FCM. Does anybody has information about this kind of error?
firebaser here
At first glance, your project may be getting throttled, but it may also be another problem in the API calls or the FCM backend. It’ll be challenging to pinpoint or even narrow down what is the specific cause of the error on a public forum without going into project-specific details. I would recommend reaching out to Firebase support as they can offer personalized help. Please provide the latest request and response (with timestamp) you have so they can check what happened to the message delivery.
Lately numerous network requests with Alamofire made from our iOS device fail with the following error:
Error Domain=NSPOSIXErrorDomain Code=28 "No space left on device"
UserInfo={_NSURLErrorFailingURLSessionTaskErrorKey=LocalDataTask
.<3>,
_kCFStreamErrorDomainKey=1, _NSURLErrorRelatedURLSessionTaskErrorKey=( "LocalDataTask .<3>" ),
_kCFStreamErrorCodeKey=28}
Our app has a mechanism to send a network request if the user has moved +- 10 meters. This is checked every 5 seconds, so in theory every five seconds a call can be made. The network request fails occasionally with this message, returning no status code and the above error.
The message implies the error has to do with available disk/memory space on the device. However, after checking both there is no link to be found since there is plenty of space available. Also, the error occurs on multiple devices, all running iOS 14.4 or higher.
Is there information available regarding error code 28 and what could be the culprit on iOS devices? Even better; how can this error be prevented?
To answer the occurrence of the error itself:
NSPOSIXErrorDomain Code=28 "No space left on device"
With logs in the Xcode terminal:
2021-05-07 15:56:50.873428+0200 MYAPP[21757:7406020] [] nw_path_evaluator_create_flow_inner NECP_CLIENT_ACTION_ADD_FLOW 05CD829A-810D-412F-B86E-7524369359E8 [28: No space left on device]
2021-05-07 15:56:50.877243+0200 MYAPP[21757:7400322] Task <5504BCDF-7DFE-4045-BD4B-E75054636D5B>.<1> finished with error [28] Error Domain=NSPOSIXErrorDomain Code=28 "No space left on device" UserInfo={_NSURLErrorFailingURLSessionTaskErrorKey=LocalUploadTask <5504BCDF-7DFE-4045-BD4B-E75054636D5B>.<1>, _kCFStreamErrorDomainKey=1, _NSURLErrorRelatedURLSessionTaskErrorKey=(
"LocalUploadTask <5504BCDF-7DFE-4045-BD4B-E75054636D5B>.<1>"
), _kCFStreamErrorCodeKey=28}
It appears to get called when there are too many NSURLSessions created, reaching a limit of (in our tests) 600-700 sessions, which are not maintained or closed properly. The error started to get thrown since iOS 14, so it is interesting to see if there was a limit introduced.
Linked is a github issue raised stating the same issues on the ktor microservices framework by JetBrains, pointing in the same direction, mentioning the invalidation of sessions to prevent this issue:
https://github.com/ktorio/ktor/issues/1341
In our own project the origin of the problem turned out to be our implementation of the StarScream websocket library. This might not be relevant for the issues others are having, but explained anyways to create a complete picture of the problem. It is the cause and fix of our specific situation.
At first we assumed it had something to do with the URLSession created by Alamofire (networking library used) since POST requests started to get cancelled, and a kill of the app seemed the only solution to do requests again.
However, we also make use of websocket connections using the StarScream library, which attempts to connect to an socket, and if failed retry to connect every two seconds for a max time of two hours. This would mean for two hours, every two seconds, we connect to the socket -> receive a failure to connect -> disconnect the socket -> connect again. Using a singleton of the socket it was thought there was no possibility of creating multiple URLSessions, since the socket was only initiated once. However calling the connect to the socket again would create a new nw_connection object every single time, since the library did not handle the disconnect properly.
image of NWConcrete_nw_connection objects generated in socket connection
The way this was validated was using the instruments app to check for the creation of new nw_connection objects. Logged as a "memory leak" there, the creation of the nw_connection objects was getting logged and the solution was to make sure we disconnect the socket (invalidate the session) properly before connecting again.
I hope to answer a big part of the issue here, and I will mark my own question answered since this was the solution to the problem at hand. I think Apple should consider giving accurate reports on the number of objects created being limited, instead of giving an error "No space left on device".
Just wanted to chime in with more info, since we're experiencing the same issue.
Based on our analytics, this issue only started happening since iOS 14. We've verified it happening on 14.2, 14.4 and 14.5. Naturally the most straightforward cause for this error would be low memory or disk storage. We've excluded this option with additional logging, as you seem to have done as well.
A possibly related SO post has attributed the issue to a network inspecting framework that was enabled in their release build. It's worth checking if you use a similar tool.
Another report of this issue, this time on the Github of AFNetworking (predecessor to the Alamofire library you use), says they were able to fix it by limiting the creation of URLSession objects.
For us personally, neither of these did the trick. We created a support ticket with Apple, but this hasn't lead to a solution. They requested a small sample project that reproduces the issue, but the error only manifested after 7 days of continuous use in our app. If you have a faster way to reproduce this, it may be worth it to submit your own support ticket.
Hopefully this helps you find a solution, if you do please add this to your post to help others!
I have configured Fabric and Crashlytics in my application. I have added the call to test crashes:
Crashlytics.sharedInstance().crash()
I am seeing those crashes reported in the Dashboard with the stack traces and everything.
In the Settings menu under Notifications, I have all the alerts set to On, including Issue Velocity Alert.
According to this answer the Issue Velocity Alert:
If an issue is causing a crash in 1% of all user sessions within the past hour, you'll be notifiied.
I have received a New Fatal Issue Alert for the calls to crash() which shows the I am receiving alerts correctly.
But I haven't received any Issue Velocity Alert. Since 100% of my sessions have crashed to the same error, I should be receiving it right? The first crash happened 3 hours ago.
Note that I have tested it with 1 user on 1 device.
Why am I not receiving any alerts?
Paul from Fabric here. Crashlytics has a minimum threshold of unique users of an app before Velocity Alerts will be sent. I can't say what the exact numbers are, but they're designed to prevent apps with few users from getting spammed by our issue reporting.
This is what I found out looking into it:
An issue in an app exceeds the defined threshold for that app.
The app has 250 sessions in that time period.
There was no alert previously raised for the issue in the app.
Source: https://firebase.google.com/docs/crashlytics/velocity-alerts
Personally, I find the name velocity alert quite misleading.
I use Crashlytics to log a non-fatal issue whenever the backend returns unexpected data. Is there a way to get notified when the frequency of this issue suddenly increases? Basically something like the "Issue Velocity Alert" that works for non-fatals too.
Right now we only show notifications for velocity alerts for fatal crashes. However, I'll let the team know you are interested so we can think about this going forward. -Todd from Fabric :)
In my Windows Store App the following exception is thrown when I attempt to access
CurrentAppSimulator.LicenseInformation
"A quota was exceeded. (Exception from HRESULT: 0x803D0008)"
I have tried creating a new solution and copying all the code files across to it but still get the same error, I have found no help on MSDN or Googling in general.
Judging from the answer here and another one here, I would say you are exceeding a memory limit somewhere. The linked questions/answers indicate that "A quota was exceeded" indicates you used up your entire heap or that your message buffer isn't large enough.
Additionally, some users have indicated that they get that error when their developer license has expired and have had to re-install Windows 8 to resolve the issue.
With a little help from Googling I have discovered that uninstalling the app from the windows start screen seems to help.
When you debug your application seems to get installed and appears on the start screen, in the past I had just ignored this fact. After uninstalling the application and debugging again I was able to get past that error and was able to see the real underlying errors that were occurring. I'm not sure of the relationship between these underlying errors and the one we are discussing here, I suspect they are not directly related.