I have a simple service worker set up with workbox. The precache contains index.html and a main.xxx.js javascript bundle (among other things) where xxx is updated on each build. The precache setup is very simple, using workbox-build.
workboxBuild.injectManifest({
// ...
globPatterns: [
'index.html',
'main.*.js',
// ...
]
})
The problem that I'm seeing randomly (particularly in Safary and Firefox) is that the index seems to get into a bad (outdated) state where it references main.xxx.js yet the current build is on main.yyy.js, which doesn't exist and breaks the site. I can verify this by visiting Chrome which shows the correct reference to main.yyy.js in the index.html and works fine. What am I missing here and what strategy can I use to insure that I always have the same version?
To be clear, nothing seems to solve the problem once it's in a bad state. Refreshing does nothing.
Related
We are developing a custom UI5 application.
It is developed in the WebIDE, and therefore deployed as a BSP.
When we use the underlying model for calls ( currently 3, no CRUD ), we chose the path of using ONLY functionimports to communicate with the backend.
All of them work with the POST method.
And all of them work ONLY inside the WebIDE.
Once, I access the BSP URL otherwise, we get HTTP 500 error with "error while requesting the ressource.
We already created links, to enable special portfowarding, no result.
Let's stick to my URL from the BSP first.
I paste it into my 3 browsers: 500.
We also created a special non dialogue-user with proper roles and permissions, and in the SICF tree we assigned it .
Again, when calling from inside the WebIDE, the functionimport-calls work, otherwise not.
Error-Logs are empty.
Dumps do not happen.
ST05 trace shows where 500 is passed, deeply inside the HTTP framework, yet no chance to spot the code location, neither a breaktpoint.
In SICF logon-settings we have:
Types all, also flagged "all", SAML: inherited from parent node, sec-sessions Not limited, fix user and pw, sec: Standard, auth:Standard Sap user.
The gui-options contain ONLY one flag: ~CHECK_CSRF_TOKEN 0.
In my client I use :
Where the model is initialized as :
function initModelV2() {
var sUrl = "/sap/opu/odata/sap/Z_this_is_a_company_secret_service/";
var oModel = new sap.ui.model.odata.v2.ODataModel(sUrl);
sap.ui.getCore().setModel(oModel);
}
What else can I do to get "at least closer" to the reason, WHY ?
I could solve it, and believe it or not, sometimes simple logic helps.
I debugged the backend of CL_HTTP_RESPONSE, and once I saw, GET_STATUS, I thought to look for SET_STATUS.
There it was:
this.rModel.setHeaders( {"X-Requested-With" : "X" } );
Was missing.
Though I set it in the manifest of my model, it was not passed.
Once set in the code, it worked.
I wonder, why it is not accepted in manifest.
I have an assumption.
1st: I have this in my manifest ( yellow arrow shows, where i HAD it set up before):
But I also have an instantiation in my code, in servicebindings.js with this code
Can it be, that, in the end, I have accidently created 2 models ?
I'm using nebula docker but it throws me an error when I connected first. Then I retried everything is ok. Why is that? Must I retry every time?
This is likely caused by setting the heartbeat_interval_secs value to fetch data from the meta server. Conduct the following steps to resolve:
If meta has registered, check heartbeat_interval_secs value in console with the following command.
nebula> GET CONFIGS storage:heartbeat_interval_secs
nebula> GET CONFIGS graph:heartbeat_interval_secs
If the value is large, change it to 1s with the following command.
nebula> UPDATE CONFIGS storage:heartbeat_interval_secs=1
nebula> UPDATE CONFIGS graph:heartbeat_interval_secs=1
Note the changes take effect in the next period.
I'm trying to separate out some code from drake/automotive/automotive_demo.cc. As a first step, I'm trying to copy automotive_demo.cc and automotive_demo.py into differently named files (test.cc and test.py) and then running bazel run automotive:test -- --num_simple_cars=1. I modified automotive/BUILD.bazel and test.py to take into account the new dependencies.
The problem is that after I bazel run, the simulator window opens but no car gets rendered. Eventually it just crashes with the following errors:
[lcm-spy] ClassDiscoverer: java.lang.NoClassDefFoundError: apple/laf/AquaPopupMenuUI
[lcm-spy] jar: ../com_jidesoft_jide_oss/jide-oss-2.9.7.jar
[lcm-spy] class: com/jidesoft/plaf/aqua/AquaJidePopupMenuUI.class
...
[drake_visualizer] Qt WebEngine seems to be initialized from a plugin. Please set Qt::AA_ShareOpenGLContexts using QCoreApplication::setAttribute before constructing QGuiApplication.
...
[lcm-spy] LCM: Disabling IPV6 support
[lcm-spy] LCM: TTL set to zero, traffic will not leave localhost.
[lcm-spy] java.net.SocketException: Can't assign requested address
Here is an (unresolved) Github issue that points to the problem being that test is a "custom plug-in". But if automotive_demo can work, surely there's a way to reproduce that behavior for test? I also tried grepping for QGuiApplication and only found a series of binary files, so I didn't know how to follow the error message's suggestion.
when trying out your steps on Mac I unfortunately cannot reproduce your specific errors. I do not think that having test as a target name should cause problems (at least I did not experience issues).
Could you please make sure:
You're able to run bazel run automotive:demo -- --num_simple_car=1?
After having renamed automotive_demo.* to test.*, in your BAZEL.build, test.py files the following are mapped correctly: demo -> test and automotive_demo -> test_cc (or whatever unique name you choose)?
I have a SPA that makes use of the breeze.js library. I am using require.js to load modules. I want to optimize the application into a single JavaScript file using r.js, however I am getting the following error:
Tracing dependencies for: main
Error: ../Scripts/breeze.debug.js has two many anonymous modules in it.
at ...\Scripts\r.js:20154:35
Am I barking up the wrong tree trying to optimize with r.js? I can't see anything on the breeze.js site site to indicate that it can or can not be done.
Cut down version of m main.js:
require.config({
paths: {
"jquery": "../Scripts/jquery-1.9.1",
"Q": "../Scripts/q",
"breeze": "../Scripts/breeze.debug"
},
shim: {
"breeze": {
"deps": ["Q"]
}
},
});
require(["breeze"], function (breeze) {
//do something
});
Here is the app.build.js build file:
({
baseUrl: "../App",
mainConfigFile: '../app/main.js',
name: "main",
out: "../Build/Output/main-built.js"
})
Don't know why you're getting that error.
To be honest, we are unlikely to explore why any time soon mostly because we're not convinced that merging the entire application into a single file is a goal we would pursue with much enthusiasm.
There is great value in reducing the number of script files but it's not clear that there is much value in reducing that number to one. Breeze itself is on the (ahem) larger side so you've got a pretty healthy payload for that script request alone. A browser that can ask for scripts in parallel might actually load several scripts more quickly than it could load just one big script. And, finally, you could benefit from loading Breeze from a CDN rather than as embedded material in a mondo-script file on your web server.
Still, we hate the idea that this is failing for you. If you can figure out what is going on, we'd take reasonable steps to correct it. Thanks ... from the Breeze team.
I deployed my symfony 1.4 project from my local machine (Windows 7) to my test server (Linux Ubuntu Server).
Whenever I open this project through my browser (IE, FF...) I get an Error 500 which is most certainly caused due to an error which I get from the log/frontend_staging:
"symfony [err] {InvalidArgumentException} Unable to load "I18nHelper.php" helper in: SF_ROOT_DIR/apps/frontend/lib/helper, SF_ROOT_DIR/lib/helper, SF_ROOT_DIR/lib/vendor/symfony/lib/helper."
The File I18NHelper.php is located in SF_ROOT_DIR/lib/vendor/symfony/lib/helper, so I don't see a problem there. I already played with the naming, though some people mentioned they had trouble with the uppercase N in the Helpers name on Unix systems, but this didn´t solve my problem at all.
It's a very nasty little thing:
Use <?php use_helper('I18N'); ?> instead of <?php use_helper('I18n'); ?> (Mind the upper case of the last 'n').
Linux is case-sensitive, unlike Windows.
You have misspelled the helper's name The last "N" should be uppercase.
In templates it should look like:
<?php use_helper('I18N'); ?>
If you are modifying the settings.yml it should look like:
standard_helpers: [Partial, Cache, I18N]
You have to keep in mind that symfony YAML configuration files are cached as php files. If you don't clean your cache, your changes won't be applied (depending on the environment of course). Try using:
php symfony cc
from command line, it should fix it.