I'm using the stageBlock method and the onProgress callback. I thought I had this working when I wrote this 9 months ago but I'm doubting myself now. The progress update is showing "loadedBytes" and it does not resemble what is actually going over the network. onProgress reports as all bytes "loaded" while the browser is still uploading the file via a network request. How do you monitor the network bytes while using this azure method?
await blockBlobClient.stageBlock(blockId, chunk, chunk.size, {
onProgress: e => {
console.log('onProgress loadedBytes: ' + e.loadedBytes);
},
abortSignal: abortControllerRef.current.signal,
});
I'm using version 12.1.1 of azure nodejs package...
I have just upgraded to version 12.3.0 and still have the same problem.
Edit
I have created a small repro here: https://github.com/philwindsor/az-progress-bug
Its a react app, clone it and run yarn install then yarn run.
Gif of problem:
I ended up raising an issue on github: https://github.com/Azure/azure-sdk-for-js/issues/13161 which I have now closed.
Turns out our company virus scanner (sohpos) is the cause of the problem. Once disabled the problem goes away!
Related
I was stuck for a day The bot isn't response back my command /start after setup web hook.
I swear it working fine on local with polling method. But not working after setup web hook . I'm using flask + heroku
This is my full code:
https://pastebin.com/zBesJBjb
Info : Window 10 Pro x64,
Python 3.8,
PythonTelegram Bot = 13.4.1
My WebhookInfo response:
{
"ok": true,
"result": {
"url": "https://hello-world.herokuapp.com/xxxx",
"has_custom_certificate": false,
"pending_update_count": 0,
"max_connections": 40,
"ip_address": "54.165.0.49"
}
}
My log after deploy to heroku:
https://pastebin.com/sFD403LU
IISC, you don't process the incoming updates anywhere in webhook_handler. You'll have to either call dispatcher.process_update(update) or put the update in the dispatchers update_queue if you use dispatcher.start() in order to have the update processed. Also two more notes:
telegram.Update.de_json(request.get_json(force=True), updater) should be changed to telegram.Update.de_json(request.get_json(force=True), updater.bot)
if you don't use the updater for fetching updates, you don't need it at all, you just need a Dispatcher
I recommend to have a look at PTBs wiki page about webhooks. There even is a dedicated section on Heroku. Admittedly, it uses updater.start_webhook, but I didn't really see anything in your code that explains why you're using flask instead of the built-in solution.
I'm doing a tiny offline-able web app / PWA. It's meant to be opened from a home screen icon and mimic a regular app by loading entirely from a cache when offline.
The app is written using Vue and to accomplish the above I'm just using their PWA template and whatever it generates. To the best of my knowledge what this does is set up workbox using the GenerateSW plugin to precache everything in the Webpack build, and registers it using register-service-worker. That is, I have fairly little control out of the box over the fine details, it's meant to be a turnkey solution.
That said, I'm not sure how to actually load a new build of the application when it's available. The above can detect this - the generated SW registration file with my changes looks like this:
import debug from 'debug';
import { register } from 'register-service-worker';
if (process.env.NODE_ENV === 'production') {
register(`${process.env.BASE_URL}service-worker.js`, {
ready(...args) {
log('App is being served from cache by a service worker.\n', ...args);
},
cached(...args) {
log('Content has been cached for offline use.', ...args);
},
updated(...args) {
log('New content is available; please refresh.', ...args);
},
offline(...args) {
log('No internet connection found. App is running in offline mode.', ...args);
},
error(error, ...args) {
log('Error during service worker registration:', error, ...args);
}
});
}
When I make a new build of the application, and I refresh the app in a browser, the updated() callback is executed, but nothing else is done. When I tried adding:
window.location.reload(true);
which should be a forced refresh, I just get a refresh loop. I'm assuming this is because the service worker cache is completely independent from the browser cache and unaffected by things like the above or Ctrl+F5. (Which makes the "please refresh" rather misleading.)
Since this is going to mimic a native app, and it's supposed to be a simple line-of-business tool, I don't really need to do anything more complicated than immediately reload to the new version of the app when an update is available. How can I achieve this?
Okay so the behaviour I've observed is that the update does happen automatically, it's just not obvious as to what the exact sequence of events is. I'll try to describe my best understanding of how the generated service worker works in the installed PWA scenario. I'll speak in terms of "app versions" for simplicity, because the mental model behind this is closer to how apps, not webpages work:
You deploy v1 of your application to a server, install / precache it on a device, and run it for the first time.
When you suspend and resume your app, it does not hit your servers at all.
The app will check for an update when it's either cold-started, or you reload the page, i.e. using the pull down gesture on Android.
(Possibly also periodically as the cached version goes stale, but I haven't checked this.)
Say you've deployed v2 of your app in the meantime. Reloading an instance of v1 of the app will find this update, and precache it.
(One reason why prompting the user to reload doesn't seem to make sense. Whatever the reloading is meant to accomplish has already happened.)
Reloading an instance of v1 again does absolutely nothing. The app remains running between reloads, and you'll just get v1 afterwards.
(Reason number two why prompting the user to reload is pointless - it's not what causes a new version of an app to load.)
However, next time you cold start your app - e.g. nuke it from the task switcher and reopen - v2 of your app will be loaded and I'm guessing v1 will get cleaned out. That is, your app must fully shut down so an update will load.
In short, for an application to be updated from v1 to v2, the following steps need to occur:
Deploy v2 to server
Refresh instance of v1 on device, or shut down and reopen the app.
Shut down and reopen the app (again).
I'm listening to events of my deployed contract. Whenever a transaction gets completed and event is fired receiving the response causes following error:
Uncaught Error: Returned values aren't valid, did it run Out of Gas?
at ABICoder.push../node_modules/web3-eth-abi/src/index.js.ABICoder.decodeParameters
(index.js:227)
at ABICoder.push../node_modules/web3-eth-abi/src/index.js.ABICoder.decodeLog
(index.js:277)
Web3 version: 1.0.0-beta36
Metamask version: 4.16.0
How to fix it?
Try the command truffle migrate --reset so that all the previous values are reset to their original value
Throws the same error when inside a transaction it generates different events with the same name and the same arguments. In my case, this was the Transfer event from ERC721 and ERC20. Renaming one of them solves this problem, but of course this isn't the right way.
This is a bug in web3js, discussed here.
And the following change fixes it (source):
patch-package
--- a/node_modules/web3-eth-abi/src/index.js
+++ b/node_modules/web3-eth-abi/src/index.js
## -280,7 +280,7 ## ABICoder.prototype.decodeLog = function (inputs, data, topics) {
var nonIndexedData = data;
- var notIndexedParams = (nonIndexedData) ? this.decodeParameters(notIndexedInputs, nonIndexedData) : [];
+ var notIndexedParams = (nonIndexedData && nonIndexedData !== '0x') ? this.decodeParameters(notIndexedInputs, nonIndexedData) : [];
var returnValue = new Result();
returnValue.__length__ = 0;
Edit: Also downgrading to web3-1.0.0.beta33 also fixes this issue too.
Before even checking your ABI or redeploying, check to make sure Metamask is connected to whichever network your contract is actually deployed too. I stepped away and while i was afk Metamask logged out, I guess I wasn't watching closely and I was connected to Ropsten when I working on localhost. Simple mistake, wasted an hour or so trying to figure it out. Hope this helps someone else out!
This happened to me on my react app.
I deployed to contract to Ropsten network, but metamask was using the Rinkeby aaccount. So make sure whichever network you deployed, metamask should be using account from that network.
The solution for me was changing of provider. With Infura the error is gone, but with Alchemy is still happening.
Please check your Metamask Login, This issue is generally populated when you are either log out of the Metamask or worse case you have 0 ether left at your account.
This can also happen when the MNEMONIC value from Ganache is different from the one you have in your truffle.js or truffle-config.js file.
I am using private_pub 1.0.3 gem which is build on top of faye and able to use it in my localhost. Now I want to implement functionality to check if user online status is online or offline using this gem.
I am totally new to web sockets and found private_pub really easy to configure it so implemented it.....but Now I am stuck in the above mentioned problem. So, please let me know what is the proper solution for it.
I found this tutorial http://www.ryanepp.com/blog/how-do-i-tell-if-a-user-is-online and I think that can solve my problem....I have configured redis server and tested it through console, it is all working.....Now all I want to do is to replace websocket-rails part of code with our own private_pub gem utilization.
UPDATE
I found these faye events:
bayeux.bind('disconnect', function(clientId) {
// event listener logic
});
client.bind('transport:down', function() {
// Fires when the connection is lost
});
client.bind('transport:up', function() {
// Fires when the connection is established
});
But, how can I use and bind these events using private_pub gem
NEW-UPDATE
I have opened issue in github for faye-rails and private_pub gem, please visite them, I have done partial solution for problem, but that didn't fully solved my problem
private_pub issue 110
faye-rails issue 72
Thanks
I installed node.js from http://nodejs.org/#download, v0.6.6. I am using Windows 7 32-bit.
I've been going through various tuts online, and want to experiment while doing so, but I cannot seem to get node.js working. Node will run my .js file, but any request from the browser times out.
Here is a typical Hello World example that does not work:
var http = require('http');
http.createServer(function (req, res) {
res.writeHead(200, {'Content-Type': 'text/plain'});
res.end('Hello World\n');
}).listen(1337);
Pointing my browser at 127.0.0.1:1337 or localhost:1337 does not work. The request from the browser times out. I've also tried listen(1337,'0.0.0.0') and listen(1337,'127.0.0.1').
I know the server is running; if I CTRL+C and stop node, the browser immediately comes back with ERR_CONNECTION_RESET.
I also tried running the code in this gist, which will not work: https://gist.github.com/1339846. I end up with the console output "Listening!" and then nothing else.
Furthermore, I have tried different ports, and my firewall is off via
netsh firewall set opmode mode=disable
I tried with firewall totally disabled, and the service stopped. If I check connections using netstat -noa, I can see node has a bunch of connections opened for the browsers, all in state CLOSE_WAIT. So it looks like connections are happening, but node.js just isn't working.
The callback function that is supposed to be initiated by a request never executes - I sprinkled some console.log statements in various areas, and they all execute except any in the callback.
I uninstalled, re-installed, tried a couple previous builds, restarted my machine...nothing.
Any help is appreciated!
UPDATE: I have just about given up. I've tried everything I can think of, and it ended up being easier to run node.js in an instance of Ubuntu in VirtualBox than grasp at straws.
!!!!!! Same problem happened for me....
Here is a solution which I have yet to find anywhere:
Look in Windows Firewall with Advanced Security and see if Evented I/O for V8 JavaScript is blocked or appears two times.
If so unblock it and delete the duplicated entry. If you install/uninstall/install nodeJs, there will be 2 entries.
Also when node first runs the Window Firewall dialog opens asking if you want to allow node to have firewall access. If you press "No" or just close the window without asking, it will create Evented I/O for V8 JavaScript AND IT WILL BE BLOCKED.
I ran into the same problem and after reading through the documentation, I unexpectedly ran into what I believe is the solution. In my instance I was noticing that the incoming requests WERE being delivered to node, but the response was never having its 'end' event triggered. So altering incoming firewall rules in windows did not seem to be related to the problem.
So, http.createServer takes in a single argument - a function which should include a request and response parameter. The request parameter seemed to be where the problem lay. The request parameter is an instance of http.incomingMessage. This class only had like one event type, but it was itself also an implementation of Stream.Readable, which is where I found the 'end' event that wasn't triggered. Really for no other reason that to just test which was the first event not triggered, I just added a listener for another type of event ('readable'), and only added a console.log line to it which made the whole thing work.
So the code looks simply something like this:
var http = require("http");
http.createServer(function (request, response) {
console.log('request');
request.on('readable', function(){
console.log('request readable');
});
request.on("end", function () {
console.log('request end');
response.writeHead(200, {
'Content-Type': 'text/plain'
});
response.end('Hello HTTP!');
});
}).listen(8080);
The above code works, whereas the earlier version below without a 'readable' event listener does not ever respond:
var http = require("http");
http.createServer(function (request, response) {
console.log('request');
request.on("end", function () {
console.log('request end');
response.writeHead(200, {
'Content-Type': 'text/plain'
});
response.end('Hello HTTP!');
});
}).listen(8080);
I am not sure why this works except for a little clue in the documentation which reads:
In some cases, listening for a 'readable' event will cause some data
to be read into the internal buffer from the underlying system, if it
hadn't already.
I just tried it and it works for me. Make sure you are not blocking node with your firewall.
I am using Windows 7 32-bit.
What edition of Windows 7 are you using? Eg. Home Premium, Professional, Ultimate?
A thread on the npm github project mentions similar symptoms while installing nodejs modules using npm, and comments seem to narrow it down to being caused by Windows 7 Professional. It being 32/64-bit doesn't seem to matter.
I am having both the problem you describe, as well as the npm installation problem, and am running on Windows 7 Professional 64-bit.
Using XPMode (a workaround mentioned in the npm thread) has allowed me to workaround both of these issues. Although, I suppose this is just a more Windows-y version of your use of Ubuntu in VirtualBox.
Other workarounds tried without success:
Make/run a Debug build of v0.6.6
Make/run a Debug build of v0.6.5 (actually crashed in startup)
Set various Compatability Modes on the installed node.exe
Prepackaged Windows installer of v0.6.5
Go to "Control Panel\All Control Panel Items\Windows Firewall\Allowed
Programs"
Click Allow Programs
select nodejs from the list.
This fixed all the problems for me
I was having the same problem with this code (Http Server example from this link: http://net.tutsplus.com/tutorials/javascript-ajax/node-js-for-beginners/)
var http = require("http");
http.createServer(function (request, response) {
request.on("end", function () {
response.writeHead(200, {
'Content-Type': 'text/plain'
});
response.end('Hello HTTP!');
});
}).listen(8080);
I tried windows 7 64-bit version, windows XP virtual machine, ubuntu virtual machine ... nothing! It only worked after I commented the "request.on" line. Your example (which doesn't have this line) worked fine for me. I'm using the latest stable build from node.js (v0.10.18 for windows or linux). Hope this helps anyone having trouble with this.