Call to plugin has timed out compilerMetadata - deployMetadataOf - {"from":"udapp","path":"compilerMetadata"} - ethereum

I'm getting an error in the remix ide:
call to plugin has timed out compilerMetadata - deployMetadataOf - {"from":"udapp","path":"compilerMetadata"}
The error is also seen as:
[TIMED OUT]: Call to method "deployMetadataOf" from "udapp" to plugin...

This is most like due to Metamask account being changed.
Refresh the Remix page and it should work fine.

You can also just restart your browser. That worked for me.

[ANSWER] This seems to be a browser based issue. I receive this error from Remix IDE on a Chrome instance, but when I switch to Firefox, the issue doesn't persist.

Clearing browser cache (ctrl + shift + delete) worked for me. PS if your using Remix, make sure to save your work somewhere just in case

Related

Strange Angular PWA Service worker behaviour when deployed

This issue has taken up all my day, and I can't figure out whats going on
I can see that my service worker is registered , however "sometimes" when I click offline in developer tools the ServiceWorker for my domain just disappears!!
But this is the main problem when I reload the app I see the following behaviour.
You can see the ngsw.json is loaded twice and the main.js is loaded 3 times! main.d3ae2084xxxx && main.bbe5073dxxxx && then main.d3ae2084xxxx again!
If I inspect the response of both ngsw.json requests you can see that both show main.d3ae2084xxxx as the correct version of main.js but it still loads main.bbe5073dxxxx...
First ngsw.json request
Second ngsw.json request
Whats even more frustrating is the actual loaded version is the previous main.bbe5073dxxxx...!!!!
If anyone has any ideas how this can be happening please let me know.
Update... So found out about this excellent little endpoint
https://you-app-url/ngsw/state
This will give you lots of debug information about your service worker.
In my case this
Driver state: EXISTING_CLIENTS_ONLY (Degraded due to failed
initialization: Hash mismatch (cacheBustedFetchFromNetwork):
https://dev-xxxx.net/main.eb8468bb3ed28f02d7c2.js: expected
b5601102b721e0cf777691d327dc965d40d1c96e, got
83c18fdb4a5942c964a31c119a57e0b8e16fe46e (after cache busting)
So looks like this is going to be a CDN issue of some sort in my case, will update with an answer when I know for sure.
You've probably resolved this by now, but I had the same issue which turned out to be due to the CDN (Cloudflare in my instance) was optimising the content.
In Cloudflare the key option is 'Auto minify' that needs to be disabled.

GoogleWebAuthorizationBroker sometimes crashes the app

I have a Windows Phone 8.1 app with Google login, which uses the
GoogleWebAuthorizationBroker.AuthorizeAsync
method. 90 % of the time, the authentication works, however, occasionally, the app just crashes on this line (I am logging right before it, so I am sure). I have the call wrapped inside try - catch, but that doesn't seem to work - exception is never caught.
I am also sure I am calling the method on a UI thread, I am using the DispatcherHelper from MVVMLight for that.
The fact that I am not able to reproduce the crash complicates this a lot, I have not experienced it with debugger attached, only in Release mode, on target device, run locally.
Do you guys have any ideas / clues / pointers? I know I'm not providing a lot of information, but I don't have any..
EDIT> So the error now happened with debugger attached - and the app just froze, last message in Ouput window was
"WinRT information: Cannot get credential from Vault"
But that's normal behavior..

Calling Rest service with json return, issue in chrome

I have a Rest service which if I execute it in IE or Firefox it executes fine.
http://MyPC.com/Services/REST.svc/Work/Lists?$format=json
But when I try to execute it in Chrome I just get this error.
http://MyPC.com/Services/REST.svc/Work/Lists?$format=json:1 GET http://MyPC.com/Services/REST.svc/Work/Lists?$format=json net::ERR_CONNECTION_RESET
Has anyone experienced this before and find a way to resolve it.
I've played around with the bindings in the config with no success
Just a note, I tried another Rest Service which I wasn't hosting and it worked in both IE and Chrome.
So it doesn't look like the issue is with Chrome.
I just want to add I didn't write any of these services, I'm still figuring it all out
Seems it sending the windows credentials through in binding did the trick, Chrome for some reason throws a connection issue when it didn't have the credentials for the service where as IE and Firefox seem to sk for the credentials when its required

How to solve authentication problems in facebook

I am creating an application that until yesterday seemed to work, but this morning, performing a function as I always do, it turns out this message:
"Fatal error: Uncaught OAuthException: An active access token must be used to query information about the current user. Thrown in ../base_facebook.php on line 1254"
Where am I doing wrong?
you Try to clean the cookies and cache from your firefox browser and try to execute your application once again...and check if you are app works in firefox this time...

Chrome : websocket connection not closed when browser closed

I am using Netty websockets and everything seems to work fine except this minor issue :
If I close the browser / tab of the js websocket client , the websocket connection is automatcally closed when using Mozilla firefox (currently using firefox 14) but the same thing does not happen in Chrome 20/21.
Anyone seen a similar issue / can anyone tell why is the connection not closed automatically ?
I guess I should have checked this earlier in the chromium bug section but I was not sure if it is a bug.
It has been reported earlier by someone and a chromium bug already exists :
Issue 51687 : WebSocket: Send close with code 1001 on reload / tab close
Update : Someone has submitted a patch to fix this issue, can be seen in the above link.
This may not be right, but I cannot post a comment to your question. Chrome/Chromium does not really close if you have an App running and have selected "Continue running background apps when Chromium is closed" from Settings-->Under the hood.
It may be that it treats the websocket connection as an app. Try looking at your running processes and kill any chrome/chromium process you find.
Again, this is just speculation on my part.
Chrome doesn't close the connection, when a user will close the window or browser.
It will trigger an Error event.
A possible workaround could look like this:
#OnError
public void onErr(Throwable t) {
onClose(this.container.getWsSession(), null);
}
But this will close the connection every time, an Error is triggered. You may wan't to check the throwable, before closing the connection by yourself.
For more discussion, please join this question:
Websocket: Closing browser triggers onError() in chrome but onClose() event in Firefox