While implement Fire-base cloud messaging in browser with help of Service Worker getting an error "DOMException: Registration failed - storage error" please help why i am getting this error
This means that your Service Worker has stored so much data that the storage available to it is full, and upon SW installation it tries to store even more which in turn leads to an error.
You have to either manually remove stuff from your storage or use some library that automatically handles these situations for you in a way or another (eg. removes stuff FIFO style).
In my case the problem was caused by create-react-app's own service worker unregistration logic at the very bottom of index.js:
serviceWorker.unregister();
It was conflicting with the fact of using a service worker in the middle of our own application's logic.
Solution was simple – just removing that line from index.js
Related
I've a project using firebase realtime database for over 2 years now... it is a big project with many rules and over 1GB data and around 10k users dayly
I was checking the firebase rules monitor and i notice something unwanted
In my happy world there would be ZERO denies and zero errors. The denies I'm monitoring on my own, but I dont know any way to monitore the errors or debug them
I understand that errors come from firebase trying to evaluate some specific rule and it throwing an exception... BUT HOW CAN I DETERMINE WHICH RULE WAS IT? so i can fix the error...
when dealing with the client side firebase only return PERMISSION DENIED without any further explanation so it is impossible to me guess from the client side if this was a normal permission denied or anything related to a rule error [making it impossible to log or debug]
does anyone know ANY WAY to determine which rules are having errors?
================UPDATE===================
I've pasted the rules in this bin
https://ghostbin.co/paste/3bj823
This normally isn't possible with the limitations firebase gives us.
However, a sound solution is to have a catch on your realtime requests that pushes a log object to realtime db in a separate bucket or a dedicated node. Since realtime db writes are fundamentally free besides storage, this creates an environment where you can debug the users' request, their app state, and any data they may be trying to send.
example:
realtimeReference.push({
user: uid,
path: "path/that/failed",
payload: Json.stringify(payload),
meta: {additional:data,etc:etc},
timestamp: firebase.database.ServerValue.TIMESTAMP
})
To ensure that your app isn't always pushing data and to avoid constantly updating your app, you can use global variables with Remote Config:
https://firebase.google.com/docs/remote-config
If you are using cloud functions, you could automatically save all errors into a separate log file with the full trace of the requests chains
I'm trying to open the Artifactory Users Management page, following the Admin->Security->Users tab.
Then I'm getting the following error:
Any idea of what might be causing it? Also, which log I can check this? Couldn't find anything yet.
The server error generally indicates there is problem fetching the user details from Artifactory. This can happen due to any of the following reasons:
when you have a high volume of users and the request is timing out.
There is a chance that you might have created a username with a
special character which is not allowed (using the REST method or some
other method)
There is an issue with the backend database
And the best place to troubleshoot is to first check the request log a good valid entry looks like below:
20200715164402|104|REQUEST|165.225.104.49|admin|GET|/ui/users|HTTP/1.1|200|0
Next check the artifactory.log file for java stack or check catalina.out under tomcat/logs directory.
I'm running a DAG in Google Cloud Composer (hosted Airflow) which runs fine in Airflow locally. All it does is print "Hello World". However, when I run it through Cloud Composer I receive the error:
*** Log file does not exist: /home/airflow/gcs/logs/matts_custom_dag/main_test/2020-04-20T23:46:53.652833+00:00/2.log
*** Fetching from: http://airflow-worker-d775d7cdd-tmzj9:8793/log/matts_custom_dag/main_test/2020-04-20T23:46:53.652833+00:00/2.log
*** Failed to fetch log file from worker. HTTPConnectionPool(host='airflow-worker-d775d7cdd-tmzj9', port=8793): Max retries exceeded with url: /log/matts_custom_dag/main_test/2020-04-20T23:46:53.652833+00:00/2.log (Caused by NewConnectionError('<urllib3.connection.HTTPConnection object at 0x7f8825920160>: Failed to establish a new connection: [Errno -2] Name or service not known',))
I've also tried making the DAG add data into a database and it actually succeeds 50% of the time. However, it always returns this error message (and no other print statements or logs). Any help much appreciated on why this might be happening.
We also faced the same issue then raised a support ticket to GCP and got the following reply.
The message is related to the latency of syncing logs from Airflow workers to WebServer, it takes at least some minutes (depending on the number of objects and their size)
The total log size seems not large but it’s enough to noticeably slow down synchronization, hence, we recommend cleanup/archive the logs
Basically we recommend relying on Stackdriver logs instead, because of latency due to the design of this sync
I hope this will help you solve the problem.
I have the same problem after upgrading from 1.10.3 to 1.10.6 of Google Composer.
I can see in my logs that airflow is trying to get the logs from a bucket with a name ended with -tenant while the bucket in my account ends with -bucket
In the configuration, I can see something weird too.
## airflow.cfg
[core]
remote_base_log_folder = gs://us-east1-dada-airflow-xxxxx-bucket/logs
## also in the running configuration says
core remote_base_log_folder gs://us-east1-dada-airflow-xxxxx-tenant/logs env var
I wrote to google support and they said the team is working on a fix.
EDIT:
I've been accessing my logs with gsutil and replacing the bucket name suffix to -bucket
gsutil cat gs://us-east1-dada-airflow-xxxxx-bucket/logs/...../5.logs
I faced the same situation in multiple occasions.
As soon as when the job finished when I take a look at the log on Airflow Web UI, it used to give me the same error. Although when I check back the same logs on UI after a min or 2, I could see the logs properly.
As per the above answers, its a sync issue between the webserver and the Worker node.
In general, the issue describe here should be more like a sporadic issue.
In certain situations, what could help is setting default-task-retries to a value that allows for retrying a task at least 1.
This issue is resolved at least since Airflow version: 1.10.10+composer.
Not appear every time, but sometimes this error appears in the log:
FIREBASE WARNING: {"code":"app/invalid-credential","message":"Credential implementation provided to initializeApp() via the \"credential\" property failed to fetch a valid Google OAuth2 access token with the following error: \"read ECONNRESET\"."}
Is there any way to handle this kind of error like retry?
Or is it okay to ignore it?
Just ensure that your machine time auto sync. and not manualy,
And your XXX......json from firebase is the latest downloaded. (if you dont sure, download it again - and this file will be the newer one)
that what helped me.
I am also facing this issue. Looks like it retries and get the job done but cloud functions are taking time to process data.
I converted a standalone Flex app into a module. Now that it's a module, when I login (and call the backend services), I'm getting a security sandbox violation.
The login handler throws this fault String: 'Send Failed', with a more descriptive: 'Channel.Connect.Failed error NetConnection.Call.Failed: HTTP: Failed:url: 'http://myUrl:8080/AppManager/messagebroker/amf'.
Then the FB console throws an 'unhandled security sandbox violation error'.
Can converting an app into a module cause a sandbox violation?
Thanks for any helpful tips.
I'm making extensive use of modules and haven't run into this. There are memory issues I ran into that I had to fix by actually declaring an instance of the modules in the main modules...I didn't have to create an instance, just declare a variable to get the linkage right, then have all the other modules compile against that main module. Memory errors went away, and all the other modules were much smaller too.