I am facing an issue regarding service worker update. I have deployed my code on production now we have some changes in service worker, after changes have been done when i deploy on production, i am not getting any changes made on device.
Please help me
On continuation of above problem...
After spending some time on this issue what i have done, i put a version in url of serviceworker in a queryParam e.g. main page- var workerVersion = 'v1' and registered with sw.js?ver=workerVersion.
Now on page load i checked the previous registered version with getRegistration() method if version is different then first unregister the existing worker and install new worker with latest version.
Is there any better way of doing this??
Have you read this section?
Also, are you using self.skipWaiting() inside the install event? If not it maybe that the new version is waiting until the page is closed.
Related
Explanation
I'm having an issue with Workbox where my website doesn't update when a file's content is changed, unless I manually clear storage/site data in my browser.
Since v4 release this year, the cleanupOutdatedCaches, which is in my code, should take care of this, but the problem persists.
Example
I created this website to exemplify. Once you access it, Workbox will install the service worker, but if I change, for example, test1 to test2, you won't see the change, unless you clear the site data in your browser and refresh.
I also tried only unregistering the sw; it shows the updated version (test2), but when refreshing twice it goes back to the old version (test1).
You can see the website's code in GitHub here.
Thanks in advance,
Luiz.
cleanOutdatedCaches will only clean caches created by older versions of the workbox library. In this case, since you are using the same version fo workbox, the call to this method does nothing.
https://developers.google.com/web/tools/workbox/reference-docs/latest/workbox.precaching#.cleanupOutdatedCaches
Once a particular file is precached by Workbox, it will never attempt to retrieve that file from the network, unless the revision you have specified in the precacheAndRoute call is different from what was previously cached.
Since you changed index.html but not the revision in precacheAndRoute, workbox assumes the file is unchanged. So,what you need to do is to update the precacheAndRoute with a new hash that corresponds to the new version of index.html
You can achieve this by either using injectManifest
https://developers.google.com/web/tools/workbox/modules/workbox-build
or any other build tooling you use.
Edit:
You can invoke skipWaiting programmatically as well
https://developers.google.com/web/tools/workbox/modules/workbox-core#skip_waiting_and_clients_claim
But you do need to use it with caution. Here is one way to do it :
https://developers.google.com/web/tools/workbox/guides/advanced-recipes
I have been checking a lot of threads on this topic , and can't seem to find a clear answer to this .
Question :
Do service workers check imported scripts for byte size difference, and trigger update of SW if there is difference.
In GitHub issues I went through :
Add web SDK API for service worker to be updated manually
Consider relying on eTags (or other headers) for service worker dependencies to check for updates
And also followed up with these :
Jake Archibald's Service worker meeting notes
Service worker: importScripts never updates scripts
Most of the articles are from 2016/17 and they are saying this should be implemented. On GitHub theres even a mention that work on this has started, but nothing more, no clear status on this or maybe I'm just missing it ?
Any info on this would be helpful.
According to this, starting in version 68, chrome will ignore HTTP cache when requesting updates to the service worker script. Requests for importScripts will still go via the HTTP cache. But this is just the default—a new registration option, updateViaCache is available that offers control over this behavior.
Example of updateViaCache option:
if ('serviceWorker' in navigator) {
navigator.serviceWorker.register('/service-worker.js', {
updateViaCache: 'none'
});
}
When set to 'none', the HTTP cache will not be consulted when making requests for either the top-level /service-worker.js or for any imported scripted, such as the hypothetical path/to/import.js.
It's actually the filesize difference in the SW file itself. If you would look at this SW example at line 31, the variable CACHE_VERSION gets updated everytime there is an update. This will enable the browser to dump the old one and get a new version from the server.
Not sure if this is a potential bug or me doing something wrong.
I'm using cli based app, #angular/serviceworker 5.1.0 #angular/cli 1.6.0
Implementation of the SW is exactly by the book
I will try to describe what's going on:
Consider an app with running service worker. The SW caches data from ngsw.json.
Now, I am going to deploy a new ng build --prod files with new budle hash.
Currently running app's ServiceWorker will be loading old cached files unless explicitly ask to update by SwUpdate service. That's fine.
But here's the thing. Upon opening new tab and loading new instance of the app it still loads the old files. In network log there is no fetch of new ngsw.json.
Do both tabs use the same ServiceWorker?
How does ServiceWorker knows when to check for new ngsw.json?
The most bizzare things:
Sometimes upon hitting F5 the ServiceWorker still loading old files. Sometimes it loads the new files. Sometimes it tries to fetch files with old hash and fails (404)!
I haven't been able to figure out any pattern so far.
Is it possible browser caching is causing problems? I tried to add server response headers to no-cache and expire: 0 but no difference.
At the time of this answer, the latest version of ngsw (#angular/service-worker) is 8.2.13.
Do both tabs use the same ServiceWorker?
Yes, both tabs activate the same service worker. This is done because of data integrity, if you had one service worker processing differently to another service worker across different tabs, this would become a nightmare to maintain.
How does the ServiceWorker know when to check for new ngsw.json?
ngsw.json is updated when you call a production build, as you've identified: ng build --prod. The service worker doesn't consider an update to ngsw.json as an update to the service worker. As such, it can update the service worker's cache without creating a new version of the service worker and a simple refresh should suffice, without needing to close the browser tabs.
If the service worker is updated, a new service worker should get installed but it won't activate until all associated browser clients (tabs) have been closed, which will make it safe to update.
Sometimes upon hitting F5 the ServiceWorker still loading old files.
Sometimes it loads the new files. Sometimes it tries to fetch files
with old hash and fails (404)!
The refresh button doesn't behave ordinarily when it comes to service workers. If you're doing a hard reload, you will bypass the service worker and request new data. This action won't necessarily update the service worker's cache. As a result, you might find the next refresh loads old data, retrieved from the cache associated with the old service worker.
Is it possible browser caching is causing problems?
To manually invalidate the service worker's cache, head into DevTools > Application (tab) > Cache storage and delete its contents.
I'm using Hangfire in my MVC webapp. I configured it this way:
GlobalConfiguration.Configuration
.UseMongoStorage(mongoConnectionString, mongoDatabaseName);
app.UseHangfireServer();
When I run the application I see IIS Worker Process takes constantly almost 40% CPU.
Removing it brings the application to works normally.
What's wrong?
Hangfire.Mongo since version 0.2.2 uses a new version of the mongocsharpdriver package that migrated to async API when talking with Mongo. Hangfire still uses synchronous methods, and looks like there is an error in "sync over async" wrapper.
One user reported that after setting the following options everything is fine.
CountersAggregateInterval = TimeSpan.FromMinutes(5);
JobExpirationCheckInterval = TimeSpan.FromHours(1);
However, the fix isn't available currently, and another option is to downgrade the Hangfire.Mongo package to the previous version. Please see the related GitHub issue.
I'm currently developing three workflows that are supposed to handle the status of items in different lists.
Each Workflow is attached to a separate list.
When I'm deploying and debugging in my development Environment, everything works fine.
Except for the case, when an item is created via an incoming mail.
I already figured out, that I have to restart some services and then it'll work, but I'm still not sure wich of the services is caching the workflow.
Afterwards I build a .wsp file which I deploy on a server.
Each time I deploy the solution, I do a retract and delete solution first.
After deployment I'll recreate the workflows on the lists
It seems to me that this has no effect. An older version of the workflow is still triggered, if I create a new instance in the list.
I already restarted the whole server and still no result.
Has anyone an idea what else I could try in order to get this working?
Thanks in advance.
If Timer Service is the one that calls your code, then restart Windows SharePoint Services Timer (OWSTIMER.EXE).
When workflow waits on something, it gets serialized (hydrated). When event happens, OWSTIMER.EXE deserializes (dehydrates) and continues workflow execution.
So timer is the one that wakes workflow up.
So this problem kind of resolved itself.
I was reading an article on Kirk Evanns Blog on an issue with the development of workflows in VS2008 for WSS.
I had not realized that I still had an illeagle reference in my Project properties.
I removed the reference. The second thing I tried was deploying with -upgradesolution rather than doing a retract-delete-add-deploy...
I don't know which of both did the trick, but I can finally see the new workflows kicking in.
Thanks for your help.