I might be doing this wrong, but I was just following the instructions here.
I start geth with this command: geth --mine --minerthreads=1 --datadir ./test/testDataDir/ --networkid 15
I connect to the geth console with this command: geth attach ipc:./test/testDataDir/geth.ipc
Then I unlock the account and submit a transaction, like this:
> web3.eth.sendTransaction({from:eth.coinbase, to:"0x3e1127Bf1A673D378a8570f7a79cEA4F10E20489", value: 100})
"0xe122a9fa56068f9c10802bf607b572d57de83022f6b46238b6a96629c5a0478e"
This is the output of the miner:
INFO [07-03|11:18:04] Successfully sealed new block number=1846 hash=fe4bcc…c4eea9
INFO [07-03|11:18:04] 🔗 block reached canonical chain number=1841 hash=a45268…7aee1b
INFO [07-03|11:18:04] 🔨 mined potential block number=1846 hash=fe4bcc…c4eea9
INFO [07-03|11:18:04] Commit new mining work number=1847 txs=0 uncles=0 elapsed=160.998µs
INFO [07-03|11:18:05] Submitted transaction fullhash=0xe122a9fa56068f9c10802bf607b572d57de83022f6b46238b6a96629c5a0478e recipient=0x3e1127Bf1A673D378a8570f7a79cEA4F10E20489
INFO [07-03|11:18:14] Successfully sealed new block number=1847 hash=76f3ee…169d0f
INFO [07-03|11:18:14] 🔗 block reached canonical chain number=1842 hash=d170fb…84b87e
INFO [07-03|11:18:14] 🔨 mined potential block number=1847 hash=76f3ee…169d0f
INFO [07-03|11:18:14] Commit new mining work number=1848 txs=1 uncles=0 elapsed=233.923µs
Here's how I connect to web3 from my code:
const Web3 = require('web3'); //1.0.0-beta.34
const net = require('net');
if (typeof web3 !== 'undefined') {
web3 = new Web3(web3.currentProvider);
}
else {
web3 = new Web3('./test/testDataDir/geth.ipc', net);
}
And here's where I subscribe to the logs. I want to have a callback whenever a transaction is sent to a particular address.
var options = {
fromBlock: '0x0',
address: '0x3e1127Bf1A673D378a8570f7a79cEA4F10E20489'
};
var subscription = web3.eth.subscribe('logs', options, function(error, result){
if(error || result == null){
console.log('Error when watching incoming transactions: ', error.message);
return;
}
console.log('Got something back: ', result);
// code continues...
}
subscription.on('data', function(log){
console.log(log);
});
Yet nothing gets printed at all. Also, my geth version is 1.7.2-stable-1db4ecdc. It appears that either the documentation is incorrect or incomplete, or there might be a bug in web3 itself.
@yousufzu The options.address is the contract address, not the account address, and the upper code can only get log from that specific contract because of the options filter.
I am basically getting this same issue and I have tried account address and contract address both. I have tried it with my local geth and wss://mainnet.infura.io/ws both.
there is no error and no logs for the below subscription.
Version: 1.8.13-stable
Git Commit: 225171a4bfcc16bd12a1906b1e0d43d0b18c353b
Architecture: amd64
Protocol Versions: [63 62]
Network Id: 1
Go Version: go1.10
Operating System: linux
geth process command, has been running for last 24 hours without restarts and is fully synced.
/usr/bin/geth --cache=2048 --datadir=/ethereumData/data/.ethereum --config=/ethereumData/data/config.toml --ws --wsaddr x.x.x.x --wsapi=db,eth,net,web3,personal,web3,txpool --wsorigins *
var options = {
fromBlock: '0x0',
address: '0x0A22aBDfE9c05EaF2293b994F84d9fCF60029a9A'
};
var subscription = web3.eth.subscribe('logs', options, function(error, result){
if(error || result == null){
console.log('Error when watching incoming transactions: ', error.message);
return;
}
console.log('Got something back: ', result);
// code continues...
}
subscription.on('data', function(log){
console.log(log);
});
Same here, no error and result, any example code from https://web3js.readthedocs.io/en/1.0/web3-eth-subscribe.html does not print anything, but node is working.
Facing same issue with Web3js version 1.2.6
var Web3 = require('web3');
let web3 = new Web3(Web3.providers.WebsocketProvider("wss://kovan.infura.io/ws/v3/projectid")
);
var subscription = web3.eth.subscribe('logs', {
address: ['0x8e0Df5B54737e0cF1708863826490aE00656a07b',0x3314bf4B1286F495B1fe8908F7d0f05D8818b168'],
}, function (error, result) {
console.log('inside this fun.');
if (!error)
console.log("result: ", result);
})
.on("connected", function (subscriptionId) {
console.log("subscriptionId: ", subscriptionId);
})
.on("data", function (log) {
console.log("logs: ", log);
})
.on("changed", function (log) {
console.log(" changed logs: ", log);
});
@surindergiri Is it possible for you to use the markdown code block and to add networking information from the browser or nodejs runtime? It’s kind of hard to help you without that information. Thanks! :)
Same issue with Web3.js v1.2.6 from nodejs. I just got only response subscriptionId.
javascriptconst
const project_id = "my_project_id"
const socket_network = "wss://mainnet.infura.io/ws/v3"
web3socket = new Web3(
new Web3.providers.WebsocketProvider(`${socket_network}/${project_id}`)
);
web3socket.eth
.subscribe(
"logs",
{
address: "0xCE354148B47b29907EE984F553Cb7c9606c32A29"
},
function(error, result) {
if (!error) console.log(result);
}
)
.on("connected", function(subscriptionId) {
console.log("subscriptionId:" + subscriptionId);
})
.on("data", function(log) {
console.log("data:" + log);
})
.on("changed", function(log) {
console.log("changed:" + log);
});
@kamonwananww
Have added a couple tests in #3375 to make sure this subscription works as expected using local clients and am seeing everything pass.
This suggests that the problem is most likely related to the reliability of Infura's (and sometimes geth's) websockets, which have a history of dropping connections.
On Web3's side, errors have not been fired correctly when this happens. That problem is fixed in #3190 which also adds an auto-reconnect option and should make subscriptions much more reliable overall. It should be included in the next release (1.2.7).
In the interim, the getPastEvents method over http is probably the most robust way of getting events by contract address. You can emulate a subscription by polling Infura at intervals to see what new blocks have been mined and request events across that range.
Most helpful comment
@yousufzu The
options.addressis the contract address, not the account address, and the upper code can only get log from that specific contract because of the options filter.