Maintenance Windows
The RPC API enables you to query future maintenance windows for a specific validator in current epoch
Maintenance windows​
The maintenance windows for a specific validator are future block height ranges in current epoch, in which the validator does not need produce block or chunk If the provided account is not a validator, then it will return the range from now to the end of the epoch.
- method:
EXPERIMENTAL_maintenance_windows
- params:
account_id
Example:
- JSON
- HTTPie
- Lantstool
{
"jsonrpc": "2.0",
"id": "dontcare",
"method": "EXPERIMENTAL_maintenance_windows",
"params": {
"account_id": "node0"
}
}
http POST https://rpc.testnet.near.org \
jsonrpc=2.0 \
id=dontcare \
method=EXPERIMENTAL_maintenance_windows \
params:='{
"account_id": "node0"
}'
Try it out on Lantstool
Loading...
Example response:
The result will be a list of future maintenance windows in current epoch.
For example a window [1028, 1031]
includes 1028, 1029 and 1030.
{
"jsonrpc": "2.0",
"id": "dontcare",
"result": [
[1028, 1031],
[1034, 1038]
]
}
What Could Go Wrong??​
When API request fails, RPC server returns a structured error response with a limited number of well-defined error variants, so client code can exhaustively handle all the possible error cases. Our JSON-RPC errors follow verror convention for structuring the error response:
{
"error": {
"name": <ERROR_TYPE>,
"cause": {
"info": {..},
"name": <ERROR_CAUSE>
},
"code": -32000,
"data": String,
"message": "Server error"
},
"id": "dontcare",
"jsonrpc": "2.0"
}
Heads up
The fields
code
,data
, andmessage
in the structure above are considered legacy ones and might be deprecated in the future. Please, don't rely on them.
Here is the exhaustive list of the error variants that can be returned by maintenance_windows
method:
ERROR_TYPEerror.name | ERROR_CAUSEerror.cause.name | Status Code | Reason | Solution |
---|---|---|---|---|
INTERNAL_ERROR | INTERNAL_ERROR | 500 | Something went wrong with the node itself or overloaded |
|