we're implementing Mesibo in our web application and one of the developers in our team encountered a problem with running app successfully in his browser (up-to-date Chrome running on MacOS).
He gets this error in logs:
Uncaught (in promise) DOMException: Failed to execute 'transaction' on
'IDBDatabase': One of the specified object stores was not found.
mesibo.js:83
When I checked his indexedDB in the browser I saw that "messages" and "contacts" stores were not set up (and they should be upon sdk initialization). Deleting "mesibo" database and running app again resulted in the same error. However, when running in incognito mode everything was fine and stores were correctly set up.
We are currently in the testing stage but I'd like to be sure that this problem will not show up to our users in production so I wonder if anyone here encountered such a problem and what could be a cause?
Related
We are developing MaximoAnwhere-7.6 android application using maximoAnwhere server source code but while trying to login to android environment can't able to login and there is no error. So i remove the server code android environment and i tried to recreate it and its login successfully. Now i want to know the below the issues,
how to re-generate apps features plugin eg: map,barcode scanner ...etc
while accesing workorder detail view from workorder list view, there is no response and keep on loading only. While checking the logs for android LOGCAT i am getting following error,
Uncaught TypeError: win.doc.getCSSCanvasContext is not a function
note : i am getting the above error some of few screens.
Thanks
The error "Uncaught TypeError: win.doc.getCSSCanvasContext is not a function" has been addressed in a fix from IBM. You can find another article on stackoverflow related to the same thing. They can provide a fix to work around this. That will alleviate the never-ending loading screen.
I have an app that we are slowly trying to migrate to Azure's Resource Manager model. Last Friday I published the main web app to an App Service. And when I tested it in a browser after publishing, it loaded just fine, I could log in, etc.
Then, over the weekend, it occurred to me that I had published from the wrong branch. So this morning, I came in, changed branches in VS, and re-published. This time, when I tested the app in a browser, it immediate threw an error.
[InvalidOperationException: An error occurred when trying to create a controller of type 'Response.Controllers.LogOnController'. Make sure that the controller has a parameterless public constructor.]
I've seen this error before. It's a Dependency Injection error. The app uses Unity for D.I. The thing is, I can fire up this branch on my local dev box straight out of VS with no problem.
To trouble shoot, I deleted the entire web app in Azure, and re-created it. Then, I reverted VS back to the original branch that I published on Friday, and re-published from that same branch.
I get the same error. In other words, what worked on Friday now throws this DI error on Monday. Nothing has changed. I've looked in the Global.asax file, and the dependency that the error mentions is registered. I have no idea what's going on, but I think the actual error might be a red herring.
And again, everything works just fine when running on my local dev box doing a debug from VS. And the same app runs fine with published to our (soon-to-be-old) server on RackSpace.
You can see the error here:
http://response-web-toyota-staging.azurewebsites.net/LogOn
Well, for what it's worth, I solved this by ftp'ing into the App Service, and manually clearing out all files inside of the 'site' directory. Then I (again) deleted the App Service, re-published, and voila. Now it works again.
I would have thought that deleting the App Service would have done the same thing, but I guess not.
Weird.
I've upgraded to 0.9.0.1 and that appeared to be smooth, an my meteor site works well.
However, on making a simple change to a template - literally changing a text inside a span - I get an error in the server console and the server then restarts.
server console log:
=> App running at: http://localhost:3000/
=> Client modified -- refreshing
I20140828-10:21:38.261(1)? Failed to receive keepalive! Exiting.
=> Exited with code: 1
=> Meteor server restarted
This appears to be related to new hotload process
When running your app with the local development server, changes that
only affect the client no longer require restarting the server.
Changes that only affect CSS no longer require the browser to refresh
the page, both in local development and in some production
environments. #490
What could cause this Failed to receive keepalive! error?
It seems from looking around the internet and on the IRC channel this could have one or two causes:
use of an incompatible package that got past the 0.9.x tests
some bad coding such a missed placed comma which when meteor compiles the application is forcing an error.
Or of course it could be both. Or something entirely different.
For me it was an incompatible package.
On localhost, the app works just fine.
On EC2, the app runs behind nginx. It loads into the browser, but nothing shows up. The browser console displays an Error
TypeError: 'undefined' is not an object (evaluating 'Package["service-configuration"].ServiceConfiguration')
I have no idea how to tackle this problem. Any help appreciated.
EDIT
NGINX is not the problem. The same behavior if I access meteor server directly.
Running "meteor add service-configuration" does fix the above mentioned error, but the absence of the error does not fix the observed behavior, that the app does not render on EC2 whereas it does render when started on localhost. (The error message was the only visible difference between EC2 and localhost. So I suspected that would be the cause. Now that hypothesis must be wrong.) So the problem still persists.
Problem Solved. The Lesson:
Meteor has a debug mode and a production mode. The two may behave differently. On localhost, meteor runs in debug mode per default. On deploy to meteor.com or per mup, the default is production mode. To run meteor in production mode on localhost, run meteor --production.
It looks like you're trying to access the service-configuration configs on your browser.
These are not available client side. This also affects your localhost app but it doesn't break your app (doesn't give you a blank page) because meteor is in debug mode.
In debug mode Meteor files are not concatenated so an error like this would go unnoticed, even if it is thrown on your js console. In production mode the error would halt the rest of your script (since everything is concatenated into a single file)
You need to ensure the code that is doing this only runs on the server side. In general it's not a good idea to have access to the service configuration data on the client side.
Looks like Arunoda and crew are adding a buildOptions.debug setting to the next version of MUP, which should allow you to deploy via MUP and have it act like it's running on localhost. See Arunoda's answer to a related question and (at least for now) documentation for the development version of MUP.
I'm trying to use EQATEC Profiler to profile my ASP.Net app. I followed the instructions listed here. It worked the first time, but every since then, when I run my app, I don't get a "Profiled app started" message. Then when I click on the "Take snapshot" button, I get the following:
"Taking snapshot ...failed: The remote server returned an error: (404) Not Found."
Why can't it find my app?
If a profiled app encounters errors it will log these to the profiler.log file. By default you will find this in C:\Windows\Temp\EQATECProfilerLogs. Try to see if it holds some clues. You can also try to enable "Full logging" in the app options, which will at least output something to the log.
A profiled app is actually the "server" when talking to the profiler; it is the profiler that connects to the app, not the other way around. In your case it seems that the old app has stopped listening (otherwise the profiler's attempt to connect would simply be served by the old app), but the new app has not (could not?) started listening.
It seems strange, though, so my best suggestion is to examine the log-file. It will e.g. show if the app could not start its control-server and if so, why not.
1) Try rebuilding (in Equatec) your application. Make sure "enable runtime control" is enabled in the application options when you build.
1a) Try changing the port being used for runtime control.
2) Run your application through Equatec
3) Check if you have anything funny for firewall settings or similar. Some firewalls treat Equatec communication as traffic to be blocked.
4. If all else fails, just close your application normally. Even if taking snapshots fails, you can still see the profile once your application is closed.
Guess I should provide an update on this. The error was resolved once I downloaded the latest version.