Error invalid json rpc response

const Web3 = require('web3')

class TransactionChecker {
    web3;
    account;

    constructor(projectId, account) {
        this.web3 = new Web3(new Web3.providers.HttpProvider('https://rinkeby.infuria.io/v3/' + projectId));
        this.account = account.toLowerCase();
    }

    async checkBlock() {
        let block = await this.web3.eth.getBlock('latest');
        let number = block.number;
        console.log('Searching block ' + number);

        if (block != null && block.transactions != null) {
            for (let txHash of block.transactions) {
                let tx = await this.web3.eth.getTransactions(txHash);
                if (this.account = tx.to.toLowerCase()) {
                    console.log('Transaction found on block: ' + number);
                    console.log({address: tx.from, value: this.web3.utils.fromWei(tx.value, 'ether'), timestamp: new Date()});
                }
            }
        }
    }
}

var web3 = new Web3('http://rinkeby.infuria.io/v3/' + '8116e17c869942ceb3cdbe04cf7c7248');
web3.eth.getBlockNumber()
.then(console.log);

I am using web3.js module for ethereum. While executing a transaction I am getting error response.

Error:

"Error: Invalid JSON RPC response: ""
    at Object.InvalidResponse (/home/akshay/WS/ethereum/node_modules/web3-core-helpers/src/errors.js:42:16)
    at XMLHttpRequest.request.onreadystatechange (/home/akshay/WS/ethereum/node_modules/web3-providers-http/src/index.js:73:32)
    at XMLHttpRequestEventTarget.dispatchEvent (/home/akshay/WS/ethereum/node_modules/xhr2/lib/xhr2.js:64:18)
    at XMLHttpRequest._setReadyState (/home/akshay/WS/ethereum/node_modules/xhr2/lib/xhr2.js:354:12)
    at XMLHttpRequest._onHttpResponseEnd (/home/akshay/WS/ethereum/node_modules/xhr2/lib/xhr2.js:509:12)
    at IncomingMessage.<anonymous> (/home/akshay/WS/ethereum/node_modules/xhr2/lib/xhr2.js:469:24)
    at emitNone (events.js:111:20)
    at IncomingMessage.emit (events.js:208:7)
    at endReadableNT (_stream_readable.js:1064:12)
    at _combinedTickCallback (internal/process/next_tick.js:138:11)
    at process._tickCallback (internal/process/next_tick.js:180:9)"

I am using ropsten test network url for testing my smart contract:

https://ropsten.infura.io/API_KEY_HERE

When I call the balanceOf function, it works fine but when I try to call function transfer it send me this error. The code is mentioned below:

router.post('/transfer', (req, res, next)=>{
  contractInstance.methods.transfer(req.body.address, req.body.amount).send({from:ownerAccountAddress})
  .on('transactionHash',(hash)=>{
console.log(hash)
  }).on('confirmation',(confirmationNumber, receipt)=>{
    console.log(confirmationNumber)
    console.log(receipt)
  }).on('receipt', (receipt)=>{
    console.log(receipt)
  }).on('error',(err)=>{
    console.log(err)
  })
})

Please let me know where I am wrong.

EDIT: I am using web3js version "web3": "^1.0.0-beta.34"

Exceptions¶

According to specification, error code should be in response message. Http server should respond with status code 200, even if there is an error.

JSON-RPC Errors¶

Error is an object which represent any kind of erros in JSON-RPC specification. It is not python Exception and could not be raised.

Errors (Error messages) are members of JSONRPCError class. Any custom error messages should be inherited from it. The class is responsible for specification following and creates response string based on error’s attributes.

JSON-RPC has several predefined errors, each of them has reserved code, which should not be used for custom errors.

JSONRPCResponseManager handles common errors. If you do not plan to implement own manager, you do not need to write custom errors. To controll error messages and codes, json-rpc has exceptions, covered in next paragraph.

JSON-RPC Exceptions¶

Exception here a json-rpc library object and not related to specification. They are inherited from python Exception and could be raised.

JSON-RPC manager handles dispatcher method’s exceptions, anything you raise would be catched. There are two ways to generate error message in manager:

First is to simply raise exception in your method. Manager will catch it and return JSONRPCServerError message with description. Advantage of this mehtod is that everything is already implemented, just add method to dispatcher and manager will do the job.

If you need custom message code or error management, you might need to raise exception, inherited from JSONRPCDispatchException . Make sure, your exception class has error code.

New in version 1.9.0: Fix Invalid params error false generated if method raises TypeError. Now in this case manager introspects the code and returns proper exception.

© Copyright 2013-2015, Kirill Pavlov. Revision f1b4e5e9 .

Источник

JSON-RPC 2.0

JSON-RPC is a stateless, light-weight remote procedure call (RPC) protocol. Primarily this specification defines several data structures and the rules around their processing. It is transport agnostic in that the concepts can be used within the same process, over sockets, over http, or in many various message passing environments. It uses JSON (RFC 4627) as data format.

It is designed to be simple!

2 Conventions

The key words «MUST», «MUST NOT», «REQUIRED», «SHALL», «SHALL NOT», «SHOULD», «SHOULD NOT», «RECOMMENDED», «MAY», and «OPTIONAL» in this document are to be interpreted as described in RFC 2119.

Since JSON-RPC utilizes JSON, it has the same type system (see http://www.json.org or RFC 4627). JSON can represent four primitive types (Strings, Numbers, Booleans, and Null) and two structured types (Objects and Arrays). The term «Primitive» in this specification references any of those four primitive JSON types. The term «Structured» references either of the structured JSON types. Whenever this document refers to any JSON type, the first letter is always capitalized: Object, Array, String, Number, Boolean, Null. True and False are also capitalized.

All member names exchanged between the Client and the Server that are considered for matching of any kind should be considered to be case-sensitive. The terms function, method, and procedure can be assumed to be interchangeable.

The Client is defined as the origin of Request objects and the handler of Response objects.
The Server is defined as the origin of Response objects and the handler of Request objects.

One implementation of this specification could easily fill both of those roles, even at the same time, to other different clients or the same client. This specification does not address that layer of complexity.

3 Compatibility

JSON-RPC 2.0 Request objects and Response objects may not work with existing JSON-RPC 1.0 clients or servers. However, it is easy to distinguish between the two versions as 2.0 always has a member named «jsonrpc» with a String value of «2.0» whereas 1.0 does not. Most 2.0 implementations should consider trying to handle 1.0 objects, even if not the peer-to-peer and class hinting aspects of 1.0.

4 Request object

A rpc call is represented by sending a Request object to a Server. The Request object has the following members:

jsonrpc A String specifying the version of the JSON-RPC protocol. MUST be exactly «2.0». method A String containing the name of the method to be invoked. Method names that begin with the word rpc followed by a period character (U+002E or ASCII 46) are reserved for rpc-internal methods and extensions and MUST NOT be used for anything else. params A Structured value that holds the parameter values to be used during the invocation of the method. This member MAY be omitted. id An identifier established by the Client that MUST contain a String, Number, or NULL value if included. If it is not included it is assumed to be a notification. The value SHOULD normally not be Null [1] and Numbers SHOULD NOT contain fractional parts [2]

The Server MUST reply with the same value in the Response object if included. This member is used to correlate the context between the two objects.

[1] The use of Null as a value for the id member in a Request object is discouraged, because this specification uses a value of Null for Responses with an unknown id. Also, because JSON-RPC 1.0 uses an id value of Null for Notifications this could cause confusion in handling.

[2] Fractional parts may be problematic, since many decimal fractions cannot be represented exactly as binary fractions.

4.1 Notification

A Notification is a Request object without an «id» member. A Request object that is a Notification signifies the Client’s lack of interest in the corresponding Response object, and as such no Response object needs to be returned to the client. The Server MUST NOT reply to a Notification, including those that are within a batch request.

Notifications are not confirmable by definition, since they do not have a Response object to be returned. As such, the Client would not be aware of any errors (like e.g. «Invalid params.», «Internal error.»).

4.2 Parameter Structures

If present, parameters for the rpc call MUST be provided as a Structured value. Either by-position through an Array or by-name through an Object.

• by-position: params MUST be an Array, containing the values in the Server expected order.
• by-name: params MUST be an Object, with member names that match the Server expected parameter names. The absence of expected names MAY result in an error being generated. The names MUST match exactly, including case, to the method’s expected parameters.

5 Response object

When a rpc call is made, the Server MUST reply with a Response, except for in the case of Notifications. The Response is expressed as a single JSON Object, with the following members:

jsonrpc A String specifying the version of the JSON-RPC protocol. MUST be exactly «2.0». result This member is REQUIRED on success.
This member MUST NOT exist if there was an error invoking the method.
The value of this member is determined by the method invoked on the Server. error This member is REQUIRED on error.
This member MUST NOT exist if there was no error triggered during invocation.
The value for this member MUST be an Object as defined in section 5.1. id This member is REQUIRED.
It MUST be the same as the value of the id member in the Request Object.
If there was an error in detecting the id in the Request object (e.g. Parse error/Invalid Request), it MUST be Null.

Either the result member or error member MUST be included, but both members MUST NOT be included.

5.1 Error object

When a rpc call encounters an error, the Response Object MUST contain the error member with a value that is a Object with the following members:

code A Number that indicates the error type that occurred.
This MUST be an integer. message A String providing a short description of the error.
The message SHOULD be limited to a concise single sentence. data A Primitive or Structured value that contains additional information about the error.
This may be omitted.
The value of this member is defined by the Server (e.g. detailed error information, nested errors etc.).

The error codes from and including -32768 to -32000 are reserved for pre-defined errors. Any code within this range, but not defined explicitly below is reserved for future use. The error codes are nearly the same as those suggested for XML-RPC at the following url: http://xmlrpc-epi.sourceforge.net/specs/rfc.fault_codes.php

The remainder of the space is available for application defined errors.

6 Batch

To send several Request objects at the same time, the Client MAY send an Array filled with Request objects.

The Server should respond with an Array containing the corresponding Response objects, after all of the batch Request objects have been processed. A Response object SHOULD exist for each Request object, except that there SHOULD NOT be any Response objects for notifications. The Server MAY process a batch rpc call as a set of concurrent tasks, processing them in any order and with any width of parallelism.

The Response objects being returned from a batch call MAY be returned in any order within the Array. The Client SHOULD match contexts between the set of Request objects and the resulting set of Response objects based on the id member within each Object.

If the batch rpc call itself fails to be recognized as an valid JSON or as an Array with at least one value, the response from the Server MUST be a single Response object. If there are no Response objects contained within the Response array as it is to be sent to the client, the server MUST NOT return an empty Array and should return nothing at all.

Источник

simple is better

Table of Contents

1 Overview

JSON-RPC is a stateless, light-weight remote procedure call (RPC) protocol. Primarily this specification defines several data structures and the rules around their processing. It is transport agnostic in that the concepts can be used within the same process, over sockets, over http, or in many various message passing environments. It uses JSON (RFC 4627) as data format.

It is designed to be simple!

2 Conventions

The key words «MUST», «MUST NOT», «REQUIRED», «SHALL», «SHALL NOT», «SHOULD», «SHOULD NOT», «RECOMMENDED», «MAY», and «OPTIONAL» in this document are to be interpreted as described in RFC 2119.

Since JSON-RPC utilizes JSON, it has the same type system (see http://www.json.org or RFC 4627). JSON can represent four primitive types (Strings, Numbers, Booleans, and Null) and two structured types (Objects and Arrays). The term «Primitive» in this specification references any of those four primitive JSON types. The term «Structured» references either of the structured JSON types. Whenever this document refers to any JSON type, the first letter is always capitalized: Object, Array, String, Number, Boolean, Null. True and False are also capitalized.

All member names exchanged between the Client and the Server that are considered for matching of any kind should be considered to be case-sensitive. The terms function, method, and procedure can be assumed to be interchangeable.

The Client is defined as the origin of Request objects and the handler of Response objects. The Server is defined as the origin of Response objects and the handler of Request objects.

One implementation of this specification could easily fill both of those roles, even at the same time, to other different clients or the same client. This specification does not address that layer of complexity.

3 Compatibility

JSON-RPC 2.0 Request objects and Response objects may not work with existing JSON-RPC 1.0 clients or servers. However, it is easy to distinguish between the two versions as 2.0 always has a member named «jsonrpc» with a String value of «2.0» whereas 1.0 does not. Most 2.0 implementations should consider trying to handle 1.0 objects, even if not the peer-to-peer and class hinting aspects of 1.0.

4 Request object

A rpc call is represented by sending a Request object to a Server. The Request object has the following members:

jsonrpc A String specifying the version of the JSON-RPC protocol. MUST be exactly «2.0». method A String containing the name of the method to be invoked. Method names that begin with the word rpc followed by a period character (U+002E or ASCII 46) are reserved for rpc-internal methods and extensions and MUST NOT be used for anything else. params A Structured value that holds the parameter values to be used during the invocation of the method. This member MAY be omitted. id An identifier established by the Client that MUST contain a String, Number, or NULL value if included. If it is not included it is assumed to be a notification. The value SHOULD normally not be Null [1] and Numbers SHOULD NOT contain fractional parts [2].

The Server MUST reply with the same value in the Response object if included. This member is used to correlate the context between the two objects.

4.1 Notification

A Notification is a Request object without an «id» member. A Request object that is a Notification signifies the Client’s lack of interest in the corresponding Response object, and as such no Response object needs to be returned to the client. The Server MUST NOT reply to a Notification, including those that are within a batch request.

Notifications are not confirmable by definition, since they do not have a Response object to be returned. As such, the Client would not be aware of any errors (like e.g. «Invalid params.», «Internal error.»).

4.2 Parameter Structures

If present, parameters for the rpc call MUST be provided as a Structured value. Either by-position through an Array or by-name through an Object.

• by-position: params MUST be an Array, containing the values in the Server expected order.
• by-name: params MUST be an Object, with member names that match the Server expected parameter names. The absence of expected names MAY result in an error being generated. The names MUST match exactly, including case, to the method’s expected parameters.

5 Response object

When a rpc call is made, the Server MUST reply with a Response, except for in the case of Notifications. The Response is expressed as a single JSON Object, with the following members:

jsonrpc A String specifying the version of the JSON-RPC protocol. MUST be exactly «2.0». result

Either the result member or error member MUST be included, but both members MUST NOT be included.

5.1 Error object

When a rpc call encounters an error, the Response Object MUST contain the error member with a value that is a Object with the following members:

code A Number that indicates the error type that occurred. This MUST be an integer. message A String providing a short description of the error. The message SHOULD be limited to a concise single sentence. data A Primitive or Structured value that contains additional information about the error. This may be omitted. The value of this member is defined by the Server (e.g. detailed error information, nested errors etc.).

The error codes from and including -32768 to -32000 are reserved for pre-defined errors. Any code within this range, but not defined explicitly below is reserved for future use. The error codes are nearly the same as those suggested for XML-RPC at the following url: http://xmlrpc-epi.sourceforge.net/specs/rfc.fault_codes.php

The remainder of the space is available for application defined errors.

6 Batch

To send several Request objects at the same time, the Client MAY send an Array filled with Request objects.

The Server should respond with an Array containing the corresponding Response objects, after all of the batch Request objects have been processed. A Response object SHOULD exist for each Request object, except that there SHOULD NOT be any Response objects for notifications. The Server MAY process a batch rpc call as a set of concurrent tasks, processing them in any order and with any width of parallelism.

The Response objects being returned from a batch call MAY be returned in any order within the Array. The Client SHOULD match contexts between the set of Request objects and the resulting set of Response objects based on the id member within each Object.

If the batch rpc call itself fails to be recognized as an valid JSON or as an Array with at least one value, the response from the Server MUST be a single Response object. If there are no Response objects contained within the Response array as it is to be sent to the client, the server MUST NOT return an empty Array and should return nothing at all.

7 Examples

rpc call with positional parameters:

rpc call with named parameters:

rpc call of non-existent method:

rpc call with invalid JSON:

rpc call with invalid Request object:

rpc call Batch, invalid JSON:

rpc call with an empty Array:

rpc call with an invalid Batch (but not empty):

rpc call with invalid Batch:

rpc call Batch (all notifications):

8 Extensions

Method names that begin with rpc. are reserved for system extensions, and MUST NOT be used for anything else. Each system extension is defined in a related specification. All system extensions are OPTIONAL.

Copyright (C) 2007-2010 by the JSON-RPC Working Group

This document and translations of it may be used to implement JSON-RPC, it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way.

The limited permissions granted above are perpetual and will not be revoked.

This document and the information contained herein is provided «AS IS» and ALL WARRANTIES, EXPRESS OR IMPLIED are DISCLAIMED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Источник

Мы используем web3 для подключения к тестовой сети Ethereum rinkeby. При этом через geth через localhost с помощью следующей команды web3:

var web3 = new Web3('http://localhost:8545');

Мы не получаем ошибок. Мы используем эту команду для запуска geth:

geth --rinkeby --rpc --rpcapi = "personal,eth,network,web3,net" --ipcpath "~/Library/Ethereum/geth.ipc"

Однако, когда мы пытаемся использовать тестовую сеть rinkeby напрямую:

var web3 = new Web3('https://rinkeby.infura.io/');

Получаем такую ​​ошибку:

Error: Invalid JSON RPC response: ""
   at Object.InvalidResponse (errors.js:42)
   at XMLHttpRequest.request.onreadystatechange (index.js:73)
   at XMLHttpRequest.dispatchEvent (event-target.js:172)
   at XMLHttpRequest.setReadyState (XMLHttpRequest.js:546)
   at XMLHttpRequest.__didCompleteResponse (XMLHttpRequest.js:387)
   at XMLHttpRequest.js:493
   at RCTDeviceEventEmitter.emit (EventEmitter.js:181)
   at MessageQueue.__callFunction (MessageQueue.js:353)
   at MessageQueue.js:118
   at MessageQueue.__guardSafe (MessageQueue.js:316)

Большинство операций работают в обеих сетях, но вызовы .send() не работают при прямом подключении к сети rinkeby.

Мы думаем, что это проблема аутентификации, поскольку успешно выполняются другие команды, не выполняющие транзакции. Однако мы попытались использовать HDWalletProvider, и ни одна из наших учетных записей, созданных с помощью geth, не имеет мнемоники.

Будем признательны за любые советы или шаги по устранению неполадок. Спасибо