Closed. This question needs debugging details. It is not currently accepting answers.
Edit the question to include desired behavior, a specific problem or error, and the shortest code necessary to reproduce the problem. This will help others answer the question.
Closed 3 years ago.
Improve this question
I am developing an Ionic application, I am using Firestore as a database, using offline mode.
import {AngularFirestoreModule} from '# angular / fire / Firestore';
AngularFirestoreModule.enablePersistence (),
When I open the application everything works very well, even on offline mode.
However, if the application stays open in the background mode on re-opening it always tells this error:
FIRESTORE (6.2.4) INTERNAL ASSERTION FAILED: AsyncQueue is already
failed: An internal error was encountered in the Indexed Database
server.
And I can no longer navigate anywhere in the application because I have the condition that the subscription is alive until the component is destroyed (that happens when I change the page)
takeUntil (componentDestroyed (this)):
I get the following error:
"1 errors occurred during unsubscription: 1) Error: FIRESTORE (6.2.4)
INTERNAL ASSERTION FAILED: AsyncQueue is already failed: An internal
error was encountered in the Indexed Database server"
And the full application stops working and it is very annoying to have to close it and reopen.
Is there any different way of doing? I already looked at StackOverflow, Github, all google and I can't find any solution.
What I have seen the other applications like Netflix, HBO, etc. do. is that when you reopen the application does not start exactly where it stayed, it warns you that it is loading, and when it finishes loading it leaves you very close to where you were before leaving the application without activity. I imagine it has a background and foreground change detector and a function for each event.
I was thinking that with ionic cycles I could solve that problem, like:
-detect the change to the background and unsubscribe and re-subscribe if any change to the foreground.
Do you know in any other way of doing?
That error I solved with:
window.onerror = function(error) {
if (error.indexOf("An internal error was encountered in the Indexed Database server") >= 0) {
// Refresh the page to restore IndexedDb to a working state.
window.location.reload();
}
};
and about how to observe the state changes of background and foreground:
import { Platform } from 'ionic-angular';
#Component({
template: `OK`
})
constructor(public platform: Platform) {
platform.ready().then(() => {
if (platform.is('cordova')){
//Subscribe on pause
this.platform.pause.subscribe(() => {
//Hello pause
});
//Subscribe on resume
this.platform.resume.subscribe(() => {
window['paused'] = 0;
});
}
});
}
I hope they serve you greetings.
Related
It's been a week I am struggling with this problem. I've searched throughout the web and found many answers but none of them worked for me and also most of the topics relating to this problem are unsolved in various forums as well.
Whenever my application executes the following line of code from the main process it crashes :
win.webContents.print();
Following is the crash report:
'''
I've tried the option:
win.webContents.print({silent: true}, (success, error) => {
if(success) {
console.log("Printed...");
}else {
console.log(error);
}
});
'''
No matter what I do, I get the same crash report.
Furthermore, If I print from the console of the browser window, the same crash occurs,
'''
With the same error as shown below :
'''
I am very close to the deadline of a project in which I have to integrate a printing facility to the POS thermal receipt printer, and can not find any solutions.
Also, I've used other libraries like electron-pos-printer, But internally, it uses the same concept and codes for printing, and thus, this way also failed.
It's really frustrating... Need help !!!
I have an electron app which uses electron-builder for building, packing & publishing the app.
I have the following auto-update code:
autoUpdater.logger = log;
autoUpdater.logger.transports.file.level = "info";
autoUpdater.autoDownload = true;
const updateCheck = () => {
autoUpdater.checkForUpdates().then(resp => {
log.info("autoUpdate response:");
log.info(resp);
});
};
app.on("ready", async () => {
log.info(`Version: ${app.getVersion()}`);
autoUpdater.on("update-downloaded", () => {
log.info("update downloaded");
setImmediate(() => {
try {
log.info("installing update");
// app.relaunch();
autoUpdater.quitAndInstall();
} catch (err) {
log.error("Error installing update");
log.error(err);
}
});
});
autoUpdater.on("error", err => {
log.error("AutoUpdater error");
log.error(err);
});
updateCheck();
schedule.scheduleJob("*/10 * * * *", updateCheck);
});
When I publish a new version, the auto-updater detects it, downloads it successfully, and then tries to install it.
During installation of the update, the progress bar fills up halfway, then disappears.
The app remains closed and does not automatically relaunch after the progress bar disappears.
When I re-launch it manually, it is still the old version. It detects that there is an update which has already downloaded, and tries to install it, with the same result (progress bar fills halfway then disappears, app remains closed after).
My log file shows no errors, either from the catch block or the autoUpdater.on("error") callback.
The location C:\Users\<User>\AppData\Local\<app-name>-updater has an installer.exe file which installs the previous version, and a pending folder which contains an installer for the new version. Manually executing this installer causes the app to be updated with no errors.
I tried testing using checkForUpdatesAndNotify instead of checkForUpdates (and commenting out the call to quitAndInstall), and it worked as advertised, however I would like to ensure the update is installed immediately rather than wait for the user to quit on their own.
How can I debug this further? Why am I not seeing any errors? Where should I be looking for them? What am I doing wrong?
The problem turned out to be the fact that I created the window with the option closable: false, preventing the auto updater from closing it. The auto updater works perfectly after removing this setting
Quick question: have you used
this answer to make your App window closed and minimizable to tray?
If you did, You should application.isQuiting = true before calling autoUpdater.quitAndInstall();
otherwise the application.close() function is pretty much blocked from anywhere other then the contextMenu.
I was facing the same issue and I did a lot of RnD. After trying for few days I found that there was no issue with the auto updater instead it was the issue with the file name I was uploading on my server. Make sure your exe file name for every new version is different otherwise it will not install after auto update.
For eg.
setup_0.0.1.exe than your next version file should be setup_0.0.2.exe
Make sure to update the file name in latest.yml and blockmap file as well.
I'm building a ReactJs PWA but I'm having trouble detecting updates on iOS.
On Android everything is working great so I'm wondering if all of this is related to iOS support for PWAs or if my implementation of the service worker is not good.
Here's what I've done so far:
Build process and hosting
My app is built using webpack and hosted on AWS. Most of the files (js/css) are built with some hash in their name, generated from their content. For those which aren't (app manifest, index.html, sw.js), I made sure that AWS serves them with some Cache-Control headers preventing any cache. Everything is served over https.
Service Worker
I kept this one as simple as possible : I didn't add any cache rules except precache for my app-shell:
workbox.precaching.precacheAndRoute(self.__precacheManifest || []);
Service-worker registration
Registration of the service worker occurs in the main ReactJs App component, in the componentDidMount() lifecycle hook:
componentDidMount() {
if ('serviceWorker' in navigator) {
navigator.serviceWorker.register('/sw.js')
.then((reg) => {
reg.onupdatefound = () => {
this.newWorker = reg.installing;
this.newWorker.onstatechange = () => {
if (this.newWorker.state === 'installed') {
if (reg.active) {
// a version of the SW is already up and running
/*
code omitted: displays a snackbar to the user to manually trigger
activation of the new SW. This will be done by calling skipWaiting()
then reloading the page
*/
} else {
// first service worker registration, do nothing
}
}
};
};
});
}
}
Service worker lifecycle management
According to the Google documentation about service workers, a new version of the service worker should be detected when navigating to an in-scope page. But as a single-page application, there is no hard navigation happening once the app has been loaded.
The workaround I found for this is to hook into react-router and listen for route changes, then manually ask the registered service worker to update itself :
const history = createBrowserHistory(); // from 'history' node package
history.listen(() => {
if ('serviceWorker' in navigator) {
navigator.serviceWorker
.getRegistration()
.then((reg) => {
if (!reg) {
return null;
}
reg.update();
});
}
});
Actual behavior
Throwing a bunch of alert() everywhere in the code showed above, this is what I observe :
When opening the pwa for the first time after adding it to the homescreen, the service worker is registered as expected, on Android and iOS
While keeping the app opened, I deploy a new version on AWS. Navigating in the app triggers the manual update thanks to my history listener. The new version is found, installed in the background. Then my snackbar is displayed and I can trigger the switch to the new SW.
Now I close the app and deploy a new version on AWS. When opening the app again :
On Android the update is found immediately as Android reloads the page
iOS does not, so I need to navigate within the app for my history listener to trigger the search for an update. When doing so, the update is found
After this, for both OS, my snackbar is displayed and I can trigger the switch to the new SW
Now I close the app and turn off the phones. After deploying a new version, I start them again and open the app :
On Android, just like before, the page is reloaded which detects the update, then the snackbar is displayed, etc..
On iOS, I navigate within the app and my listener triggers the search for an update. But this time, the new version is never found and my onupdatefound event handler is never triggered
Reading this post on Medium from Maximiliano Firtman, it seems that iOS 12.2 has brought a new lifecycle for PWAs. According to him, when the app stays idle for a long time or during a reboot of the device, the app state is killed, as well as the page.
I'm wondering if this could be the root cause of my problem here, but I was not able to find anyone having the same trouble so far.
So after a lot of digging and investigation, I finally found out what was my problem.
From what I was able to observe, I think there is a little difference in the way Android and iOS handle PWAs lifecycle, as well as service workers.
On Android, when starting the app after a reboot, it looks like starting the app and searching an update of the service worker (thanks to the hard navigation occuring when reloading the page) are 2 tasks done in parallel. By doing that, the app have enough time to subscribe to the already existing service worker and define a onupdatefound() handler before the new version of the service worker is found.
On the other hand with iOS, it seems that when you start the app after a reboot of the device (or after not using it for a long period, see Medium article linked in the main topic), iOS triggers the search for an update before starting your app. And if an update is found, it will be installed and and enter its 'waiting' status before the app is actually started. This is probably what happens when the splashscreen is displayed...
So in the end, when your app finally starts and you subscribe to the already existing service worker to define your onupdatefound() handler, the update has already been installed and is waiting to take control of the clients.
So here is my final code to register the service worker :
componentDidMount() {
if ('serviceWorker' in navigator) {
navigator.serviceWorker.register('/sw.js')
.then((reg) => {
if (reg.waiting) {
// a new version is already waiting to take control
this.newWorker = reg.waiting;
/*
code omitted: displays a snackbar to the user to manually trigger
activation of the new SW. This will be done by calling skipWaiting()
then reloading the page
*/
}
// handler for updates occuring while the app is running, either actively or in the background
reg.onupdatefound = () => {
this.newWorker = reg.installing;
this.newWorker.onstatechange = () => {
if (this.newWorker.state === 'installed') {
if (reg.active) {
// a version of the SW already has control over the app
/*
same code omitted
*/
} else {
// very first service worker registration, do nothing
}
}
};
};
});
}
}
Note :
I also got rid of my listener on history that I used to trigger the search for an update on every route change, as it seemed overkill.
Now I rely on the Page Visibility API to trigger this search every time the app gets the focus :
// this function is called in the service worker registration promise, providing the ServiceWorkerRegistration instance
const registerPwaOpeningHandler = (reg) => {
let hidden;
let visibilityChange;
if (typeof document.hidden !== 'undefined') { // Opera 12.10 and Firefox 18 and later support
hidden = 'hidden';
visibilityChange = 'visibilitychange';
} else if (typeof document.msHidden !== 'undefined') {
hidden = 'msHidden';
visibilityChange = 'msvisibilitychange';
} else if (typeof document.webkitHidden !== 'undefined') {
hidden = 'webkitHidden';
visibilityChange = 'webkitvisibilitychange';
}
window.document.addEventListener(visibilityChange, () => {
if (!document[hidden]) {
// manually force detection of a potential update when the pwa is opened
reg.update();
}
});
return reg;
};
As noted by Speckles (thanks for saving me the headache), iOS installs the new SW before launching the app. So the SW doesn't get a chance to catch the 'installing' state.
Work-around: check if the registration is in the waiting state then handle it.
I've made an (untested) example of handling this. - a mod to the default CRA SW.
After upgrading to Chrome 64, I realized that this error appears when I load my page on a new tab.
I can't identify where it is on the service worker. Here is my code to run the fetch:
self.addEventListener('fetch', function(event) {
if (event.request.url.startsWith(self.location.origin)) {
event.respondWith(
caches.match(event.request).then(function(response) {
return response || fetch(event.request).then(function(fetch_resp){
return fetch_resp;
});
})
);
}
});
Could anyone here, who has more knowledge about service worker, help me to solve this error?
I believe this is a Chromium bug that has been reported here. Hopefully it will be fixed soon or some more information about the issue will be published.
Paul Irish implemented a temporary work around, which is as follows:
if (e.request.cache === 'only-if-cached' && e.request.mode !== 'same-origin') {
return;
}
I ran it inside the callback for the service worker install and fetch listeners and it prevented the error.
You can see the full commit of Paul's code here.
For those searching for this again, seems like it popped up after a while again when someone opens the devtools you can still see the error mentioned in the question.
See (new) bug report here: https://bugs.chromium.org/p/chromium/issues/detail?id=1098389
So let's hope this will be fixed again soon!
perhaps the cache name is not unique from other applications, seems to fix the issue for me.
When app starts some preliminary process take place. Sometimes it is done quickly in some second, and sometimes It does not end, but without any error it hung up.
I.e. at launch client always fetch the last serverChangedToken. and sometimes it just hung up it does not complete. I am talking about production environment, developer works well. So this route get called, but some times it does not finishes. Any idea why? I do not get any error, timeout.
let fnco = CKFetchNotificationChangesOperation(previousServerChangeToken: nil)
fnco.fetchNotificationChangesCompletionBlock = {newServerChangeToken, error in
if error == nil {
serverChangeToken = newServerChangeToken
dispatch_sync(dispatch_get_main_queue(), {
(colorCodesInUtility.subviews[10] ).hidden = false
})
} else {
Utility.writeMessageToLog("error 4559: \(error!.localizedDescription)")
}
dispatch_semaphore_signal(sema)
}
defaultContainer.addOperation(fnco)
dispatch_semaphore_wait(sema, DISPATCH_TIME_FOREVER)
I know it is not recommended to use semaphores to control flow of the CloudKit method calls.
Do you think the last two line can be swapped? First dispatch_semaphore_wait and then addOperation be called?
Strange that app worked for iOS 8, this bug arise only in iOS 9.
Adding the following line of code will probably solve your problem:
queryOperation.qualityOfService = .UserInteractive
In iOS 9 Apple changed the behavior of that setting. Especially when using cellular data you could get the behaviour you described.
The documentation states for the .qualityOfService this:
The default value of this property is NSOperationQualityOfServiceBackground and you should leave that value in place whenever possible.
In my opinion this is more a CloudKit bug than a changed feature. More people have the same issue. I did already report it at https://bugreport.apple.com