Code Monkey home page Code Monkey logo

fcd-classic's People

Contributors

byeongsu-hong avatar dependabot[bot] avatar etienne-napoleone avatar gregnuj avatar hanjukim avatar kjessec avatar maruf0011 avatar masternode24 avatar ny6234 avatar octalmage avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

fcd-classic's Issues

FCD collector stuck in collecting validator information

Hi there, we are starting a fcd node with a backfilled database until 11/24/21. But our collector keeps collecting validators' info and has been doing so for 12+hrs. We are using the branch bombay. Does anyone know how to make it start picking up blocks from 11/24 (height~= 5417391)? Thanks in advance!

Logs from collector:

01-02 19:26 [INFO]: Trying to run process ProposalCollector
01-02 19:26 [INFO]: Process ProposalCollector starting...
01-02 19:26 [INFO]: Proposal collector started.
01-02 19:26 [INFO]: Checking for deleted proposals
01-02 19:26 [INFO]: Saved proposal 137
01-02 19:26 [INFO]: Proposal collector completed.
01-02 19:26 [INFO]: Process ProposalCollector ended.
01-02 19:26 [INFO]: collectValidator: Talis Protocol(terravaloper1qd0uk3wrw73x662y2gx4kaulrzlcky6275gl5s)
01-02 19:26 [INFO]: collectValidator: Accomplice Blockchain(terravaloper1p72vswk5zfzzr7myhrerm78ty5tjc8ypl259tm)
01-02 19:26 [INFO]: collectValidator: Smart Stake(terravaloper1alpf6snw2d76kkwjv3dp4l7pcl6cn9uyt0tcj9)
01-02 19:26 [INFO]: collectValidator: Orion.Money(terravaloper1259cmu5zyklsdkmgstxhwqpe0utfe5hhyty0at)
01-02 19:26 [INFO]: collectValidator: SolidStake(terravaloper1fhx7y75643tze8dxf4m9gwhkxn955q8r7vxjel)
01-02 19:26 [INFO]: collectValidator: Marte Cloud(terravaloper1dg7zhmt4g4zq74y4tksq4xfzf5pwx4cnngavjk)
01-02 19:26 [INFO]: collectValidator: stake.systems(terravaloper1a9q6jl792qg36cp025ccjtgyf4qxrwzqjkmk5d)
01-02 19:26 [INFO]: collectValidator: Orion.Money(terravaloper1259cmu5zyklsdkmgstxhwqpe0utfe5hhyty0at)
01-02 19:26 [INFO]: collectValidator: Bit Cat🐱(terravaloper1k4ef8m95t7eq522evmmuzvfkpla04pezmu4j7k)
01-02 19:26 [INFO]: collectValidator: SolidStake(terravaloper1fhx7y75643tze8dxf4m9gwhkxn955q8r7vxjel)
01-02 19:26 [INFO]: collectValidator: OneStar(terravaloper18hpew39uymssr52w8euxqh4zrrjt02x7k0jmhk)
01-02 19:26 [INFO]: collectValidator: Inotel(terravaloper1vqegsqhe8q06t6jwgvww0qcr2u6v6g9xrwjnmw)
...

Our .envrc:

export TYPEORM_CONNECTION=postgres
export TYPEORM_HOST=xxxxxxxxxxxx
export TYPEORM_USERNAME=postgres
export TYPEORM_PASSWORD=xxxxxxxxx
export TYPEORM_DATABASE=fcd
export TYPEORM_PORT=5432
export TYPEORM_SYNCHRONIZE=false
export TYPEORM_LOGGING=false
export TYPEORM_ENTITIES=src/orm/*Entity.ts
export TYPEORM_MIGRATIONS=src/orm/migration/*.ts

export SERVER_PORT=3060
export CHAIN_ID=columbus-5
export LCD_URI=http://localhost:1317
export FCD_URI=https://tequila-fcd.terra.dev
export RPC_URI=
export BYPASS_URI=https://tequila-fcd.terra.dev
export MIRROR_GRAPH_URI=https://tequila-graph.mirror.finance/graphql
export STATION_STATUS_JSON=https://terra.money/station/version-web.json
export SENTRY_DSN=
#export USE_LOG_FILE=true
export INITIAL_HEIGHT=5417391
export TOKEN_NETWORK=mainnet

Our ormconfig:

module.exports = {
        name: 'default',
        type: 'postgres',
        host: 'xxxxxxxx,
        database: 'fcd',
        username: 'postgres',
        password: 'xxxxxxxxx',
        synchronize: false
}

Fix query validation

Problem

After we add query validations using Joi, many endpoints are responding 400 Invalid Request to valid queries

To Be

Responses to valid queries must to be successful

FCD and LCD mainnet give back wrong parameter. But Tequila-LCD/FCD are correct

FCD gives back erroneous parameter for slash_window. Not sure where the issue is arising from. Not sure if it is a reporting issue only or if this is affecting the entire Core slashing calculation. Tequila-FCD reports correct data.

https://fcd.terra.dev/oracle/parameters
Slash_window: 432000 (blocks per month) (erroneous)

https://tequila-fcd.terra.dev/oracle/parameters
Slash_window: 100800 (blocks per week) (correct)

Optimize government endpoints

Store the proposal info in Db and collector will update those in regular interval. it will reduce LCD dependency and realtime calls to lcd.

violated not-null constraint for code_id column

while running a code from bombay branch on bombay network:

10-08 04:53 [INFO]: Trying to run process ProposalCollector
10-08 04:53 [INFO]: Process ProposalCollector starting...
10-08 04:53 [INFO]: Proposal collector started.
10-08 04:53 [INFO]: Checking for deleted proposals
10-08 04:53 [INFO]: Proposal collector completed.
10-08 04:53 [INFO]: Process ProposalCollector ended.
10-08 04:53 [INFO]: collectBlock: begin transaction for block 5902461
10-08 04:53 [INFO]: SaveTxs - txs: 4, accountTxs: 12
10-08 04:53 [INFO]: collectWasm: new contract terra1hgjp2yjqe7ngzsx283tm7ch8xcsvk5c8mdj2tw
10-08 04:53 [ERROR]: null value in column "code_id" of relation "wasm_contract" violates not-null constraint
QueryFailedError: null value in column "code_id" of relation "wasm_contract" violates not-null constraint
    at QueryFailedError.TypeORMError [as constructor] (/app/src/error/TypeORMError.ts:7:9)
    at new QueryFailedError (/app/src/error/QueryFailedError.ts:9:9)
    at PostgresQueryRunner.<anonymous> (/app/src/driver/postgres/PostgresQueryRunner.ts:258:19)
    at step (/app/node_modules/typeorm/node_modules/tslib/tslib.js:143:27)
    at Object.throw (/app/node_modules/typeorm/node_modules/tslib/tslib.js:124:57)
    at rejected (/app/node_modules/typeorm/node_modules/tslib/tslib.js:115:69)
    at runMicrotasks (<anonymous>)
    at processTicksAndRejections (internal/process/task_queues.js:95:5)

mishandled getAddressFromMsg()

in getAddressFromMsg(),

    case 'staking/MsgDelegate':
    case 'staking/MsgCreateValidator':
    case 'staking/MsgBeginRedelegate':
    case 'staking/MsgUndelegate':
    case 'distribution/MsgSetWithdrawAddress':
    case 'distribution/MsgWithdrawValidatorCommission':
    case 'distribution/MsgWithdrawDelegationReward': {
      return {
        staking: get(msg, 'value.delegator_address') ? [get(msg, 'value.delegator_address')] : []
      }
    }

the type distribution/MsgWithdrawValidatorCommission doesn't have value.delegator_address. it should rather be value.validator_address.

checked against [email protected]

// msg struct for validator withdraw
type MsgWithdrawValidatorCommission struct {
	ValidatorAddress sdk.ValAddress `json:"validator_address" yaml:"validator_address"`
}

Cannot destructure property 'tx_response' of '(intermediate value)' as it is undefined

Running bombay branch collector seems consistently crashing at specific block heights.

Columbus:

12-27 05:30 [INFO]: collectBlock: begin transaction for block 4822834
12-27 05:30 [ERROR]: Cannot destructure property 'tx_response' of '(intermediate value)' as it is undefined.
TypeError: Cannot destructure property 'tx_response' of '(intermediate value)' as it is undefined.
    at Object.getTx (/fcd/src/lib/lcd.ts:55:11)
    at async generateLcdTransactionToTxEntity (/fcd/src/collector/block/tx.ts:166:14)

Bombay:

12-26 23:36 [INFO]: collectBlock: begin transaction for block 6682919
12-26 23:36 [ERROR]: Cannot destructure property 'tx_response' of '(intermediate value)' as it is undefined.
TypeError: Cannot destructure property 'tx_response' of '(intermediate value)' as it is undefined.
    at Object.getTx (/fcd/src/lib/lcd.ts:55:11)
    at async generateLcdTransactionToTxEntity (/fcd/src/collector/block/tx.ts:166:14)

GraphQL query for Mirror token supply needs to be updated

Querying https://fcd.terra.dev/v1/circulatingsupply/mir returns:

{
  "type": "API_ERROR",
  "message": "400 - {\"errors\":[{\"message\":\"Cannot query field \\\"mirTotalSupply\\\" on type \\\"Statistic\\\". Did you mean \\\"mirSupply\\\"?\",\"locations\":[{\"line\":3,\"column\":13}],\"extensions\":{\"code\":\"GRAPHQL_VALIDATION_FAILED\"}},{\"message\":\"Cannot query field \\\"mirCirculatingSupply\\\" on type \\\"Statistic\\\".\",\"locations\":[{\"line\":4,\"column\":13}],\"extensions\":{\"code\":\"GRAPHQL_VALIDATION_FAILED\"}}]}"
}

Due to this error, CoinGecko currently fails to display MIR's circulating supply:

Screen Shot 2021-09-20 at 12 02 51 AM

The cause of this is that FCD uses an outdated query here to fetch data from Mirror's GraphQL server:

# outdated
query statistic {
  statistic {
    mirTotalSupply
    mirCirculatingSupply
  }
}

This needs to be updated to

query statistic {
  statistic {
    mirSupply {
      circulating
      staked
      liquidity
    }
  }
}

FCD vs LCD

Silly questions,

what FCD stands for?
what's the difference with LCD?

Fix historical active accounts in /v1/account_growth

Description

Fix /v1/account_growth endpoint for querying active accounts within specific period

Changes

Query parameter: count

Description: Number of previous days
For validation, we have to change:
As Is: >= 0
To Be: 0, 7, 14, 30
Why: For query cache

Result

{
   activeAccountCount: `unique account count within selected period`,
   cumulative: [
       { 
          datetime: `unix timestamp`,
          totalAccountCount: `cumulative total accounts`
          activeAccountCount: `cumulative daily active accounts`
       },
       ...
   ],
   periodic: [
       { 
          datetime: `unix timestamp`,
          totalAccountCount: `daly account growth`,
          activeAccountCount: `daily active accounts`
       },
       ...
   ]
}

We need to fix activeAccountCount property for every elements in both cumulative and periodic array.

Notes

To show distinct accounts(activeAccountCount property in the result) within specific period, we have to query database by:

SELECT COUNT(*) FROM (SELECT DISTINCT account FROM account_tx WHERE timestamp >= `daysBefore(count)` AND timestamp < `startOfToday`

Incorrect uptime percent in Terra station

Hi!
Uptime percent in Terra Station looks incorrect.

For example MoonletWallet validator has 91% uptime
image

from validatorDetails.ts

upTime: getOracleUptime(missedOracleVote)

Uptime shows only from oracle misses, and not for missed blocks. Why?

And oracle misses uptime percent looks incorrect too.

According to https://lcd.terra.dev/oracle/voters/terravaloper19xe62428tlfesdym0zn5wx9slyefqjp00r67kw/miss
MoonletWallet has 9271 oracle misses.

According to https://lcd.terra.dev/oracle/parameters "slash_window": "432000"

Uptime percent should be 100% - 9271 / 432000 = 98%

Maybe problem is in config.ts?

// We can ORACLE_SLASH_WINDOW from {lcd}/oracle/parameters, but do this way because it's rare to be changed ORACLE_SLASH_WINDOW: parseInt(ORACLE_SLASH_WINDOW || '100800') || 100800

looks so: 100% - 9271/100800 = 91% as shown in Terra Station

[question] FCD usage for dApp

Hi, we are investigating our possibilities of using FCD in our application. The question is whether https://fcd.terra.dev is intended to be used as production API for 3rd party applications or should we prepare our standalone instance if we would love to use it.

Using this as an API?

Hi all!

I am slowly dipping my toes into Terra, and saw this project. I want to built a small website (to learn), where I interact with the Terra blockchain. More specifically, I want to monitor my transactions in a dashboard kind of way.

Can I use this service as an API for that? I.e. submitting GET requests directly?

Example: GET https://fcd.terra.dev/v1/tx/terra.....

Or do I need to fork it, and run the project myself?

Standalone tests

Change tests so they can run on an empty db (for example by running migrations and injecting mocked data if not present).
Maybe see if possible to mock lcd calls too (less problematic than db calls for ci runs)

I will help CI or external contributors running tests without relying on existing infrastructure.

API no longer works for columbus-4

I am not sure if this is the right place to post this, but I can no longer use the public api to get columbus-4 info.

Simple query of tx api fails for columbus-4 blocks:
curl -X GET "https://lcd.terra.dev/validatorsets/3999999" -H "accept: application/json"

Cache Improvements

Problem

Currently caching is done by collector/cacheStakingReward by accessing every endpoints periodically, which is not horizontally scalable.

To Be

We need to find a cache method that fits the blockchain. Every GET queries can be cached until next block comes. For Dashboard endpoints, we should change queries to calculate yesterday data and add it to another table, now we are querying the whole data from the beginning every single day.

To Do

  • Move memoizee to higher level
  • Remove cacheStakingReward
  • Cache for /block/{height}, /tx/{hash}
  • Find / Implement solution for Dashboard

Separate cache table for WASM

Now fcd uses tx search for finding code and contracts information. Now it will move to separate cache table for wasm.

What is this?

Description from https://github.com/terra-money/awesome-terra

Indexer that powers core Terra Finder and Terra Station

is still better than repository metadata:

Terra ETL + RestFul API Server
fcd.terra.dev/swagger

README has no intro what is exactly, but mentions modules:

  • Collector(Indexer)
  • Rest API server

What does FCD stay for? Isn't it acronym/abreviation?

Get txs list - `limit` not working

When I try https://fcd.terra.dev/v1/txs?block=5837920&limit=10 it returns full block's txs instead of 10. Also when I try to set limit with any other value aside from 10 or 100 it returns a weird error.

{
  "type": "INVALID_REQUEST_ERROR",
  "message": "child \"limit\" fails because [\"limit\" must be one of [10, 100]]",
  "code": 400
}

Collector TypeError

Hi,
I got an error when i run the collector by npm run coldev,
01-02 10:28 [ERROR]: result.flat is not a function TypeError: result.flat is not a function at Object.getValidatorConsensus (/data/fcd/src/lib/lcd.ts:202:17) 01-02 10:28 [ERROR]: result.flat is not a function TypeError: result.flat is not a function at getValidatorConsensus (/data/fcd/src/lib/lcd.ts:202:17)

How can i solve this problem?

Collector should reflect removed proposals

Description

This bug was found from internal testnet with following context. It has 10minutes deposit period. If the proposal does not achieve the minimum deposit, it will be deleted from the network after 10 minutes for preventing proposal spamming.

How to reproduce

  1. Create a proposal without any deposit.
  2. Wait for deposit period ends.
  3. You will find that proposal has gone by terracli q gov proposals

Expect

Collector should remove proposal from DB, if it can't find proposal from network.

FCD is trying to read invalid proposal from API.

0|collector  | 04-27 13:20 [ERROR]: 500 - {"error":"internal"} /gov/proposals/16
0|collector  | APIError: 500 - {"error":"internal"} /gov/proposals/16
0|collector  |     at /root/fcd/src/lib/lcd.ts:38:11
0|collector  |     at tryCatcher (/root/fcd/node_modules/bluebird/js/release/util.js:16:23)
0|collector  |     at Promise._settlePromiseFromHandler (/root/fcd/node_modules/bluebird/js/release/promise.js:547:31)
0|collector  |     at Promise._settlePromise (/root/fcd/node_modules/bluebird/js/release/promise.js:604:18)
0|collector  |     at Promise._settlePromise0 (/root/fcd/node_modules/bluebird/js/release/promise.js:649:10)
0|collector  |     at Promise._settlePromises (/root/fcd/node_modules/bluebird/js/release/promise.js:725:18)
0|collector  |     at _drainQueueStep (/root/fcd/node_modules/bluebird/js/release/async.js:93:12)
0|collector  |     at _drainQueue (/root/fcd/node_modules/bluebird/js/release/async.js:86:9)
0|collector  |     at Async._drainQueues (/root/fcd/node_modules/bluebird/js/release/async.js:102:5)
0|collector  |     at Immediate.Async.drainQueues [as _onImmediate] (/root/fcd/node_modules/bluebird/js/release/async.js:15:14)
0|collector  |     at processImmediate (internal/timers.js:461:21)

Seems proposals 16 does not exist.
By this error can't save block #240341

Error while building apidoc

Apidoc and swagger are currently not served from the docker image because it errors while building it in the Dockerfile:

Step 7/9 : RUN yarn run apidoc     && yarn run mergeswagger -- -o swagger.json
 ---> Running in c92d2975b90c
yarn run v1.22.0
$ npx apidoc -f ".*\\.ts$" -i src/controller -o static/
internal/modules/cjs/loader.js:985
  throw err;
  ^

Error: Cannot find module '/root/.npm/_npx/28/lib/node_modules/apidoc/node_modules/nodemon/bin/postinstall'
    at Function.Module._resolveFilename (internal/modules/cjs/loader.js:982:15)
    at Function.Module._load (internal/modules/cjs/loader.js:864:27)
    at Function.executeUserEntryPoint [as runMain] (internal/modules/run_main.js:74:12)
    at internal/main/run_main_module.js:18:47 {
  code: 'MODULE_NOT_FOUND',
  requireStack: []
}
Done in 12.64s.
yarn run v1.22.0
warning From Yarn 1.0 onwards, scripts don't require "--" for options to be forwarded. In a future version, any explicit "--" will be forwarded as-is to the scripts.
$ ts-node --files -r tsconfig-paths/register src/scripts/mergeSwaggerFile.ts -o swagger.json
Combined file saved in /app/static/swagger.json
Done in 5.05s.
Removing intermediate container c92d2975b90c

tested with commit 2a44e71

No connection options were found in any orm configuration files

Hi,
we built fcd and only created the .envrc configuration file. Is the ormconfig.js still needed for anything else?

$ npm start

> [email protected] start /opt/terra-fcd
> better-npm-run api-prod

running better-npm-run in /opt/terra-fcd
Executing script: api-prod

to be executed: node --stack_size=4096 --max-old-space-size=4096 -r ts-node/register/transpile-only -r tsconfig-paths/register src/server.ts 
05-24 07:56 [ERROR]: No connection options were found in any orm configuration files.
Error: No connection options were found in any orm configuration files.

Thanks,
bert

Fail to start the fcd collector

We're setting up a fcd node and we met this error when running the collector by npm run collector:
/blocks/1 500 - {"error":"height 1 is not available, lowest height is 4724001"}

We want to fetch both columbus-4 and 5's information and right now we leave the CHAIN-ID in the .envrc as the default value tequilia-0004.

Does anyone know what would be the right chain-id to use in our scenario or whether we need to change the start height in the block.ts to other values? thanks a lot!

Add upload of public image on docker hub

For a user friendly usage of fcd (should be also considered for any other public repo), we can have really granular images in our private aws repo, but also propose public images on docker hub so people can docker pull terra/fcd which is way more user friendly to remember and use than docker pull 616478479272.dkr.ecr.ap-northeast-2.amazonaws.com/fcd.
Also docker hub has a cdn.

Swagger or Open API 3 for FCD

AWS api gateway can import swagger or open api 3 specs to define the routes and methods which lead to very detailed endpoints metrics.

Without this, everything is accounted under the proxying endpoint (/{proxy+})

incorrect limits in collector for gov/proposals/119/votes query

In terra fcd collector_combined.log i can see error
09-20 16:49 [ERROR]: /gov/proposals/119/votes?limit=1000000000000 502 - "<html><body><h1>502 Bad Gateway</h1>\nThe server returned an invalid or incomplete response.\n</body></html>\n"
APIError: /gov/proposals/119/votes?limit=1000000000000 502 - "<html><body><h1>502 Bad Gateway</h1>\nThe server returned an invalid or incomplete response.\n</body></html>\n"
    at /mnt/operational/terra-fcd/fcd/src/lib/lcd.ts:38:11
but if I execute query with bigger amount of limits it's work well
https://lcd.terra.dev/gov/proposals/119/votes?limit=10000000000000

What is the purpose of fcd.terra.dev/swagger ?

Greetings,

I'm a little bit confused by the link in the repo (and other official terra resources) "fcd.terra.dev/swagger". What is the purpose of it? Should it be used for testing out endpoints or is it suitable for production use in websites? If so, does it have rate limits/up-time guarantees/any support?

Delegations and validators missing

Hi,
we have the FCD (api and collector) running, but are missing delegations and validators from the API. Is that the case because our collector is not in sync yet?

Collector is catching up:

...
May 24 08:37:27 terra-1 terra-fcd[9351]: 05-24 08:37 [INFO]: Migrated 0 contract
May 24 08:37:27 terra-1 terra-fcd[9351]: 05-24 08:37 [INFO]: collectBlock: transaction finished
May 24 08:37:27 terra-1 terra-fcd[9351]: 05-24 08:37 [INFO]: collectBlock: begin transaction for block 3894
May 24 08:37:27 terra-1 terra-fcd[9351]: 05-24 08:37 [INFO]: SaveTxs - height: 3894, txs: 0, account: 0, accountTxs: 0
May 24 08:37:27 terra-1 terra-fcd[9351]: 05-24 08:37 [INFO]: Storing 0 codes and 0 contracts.
May 24 08:37:27 terra-1 terra-fcd[9351]: 05-24 08:37 [INFO]: Stored 0 codes and 0 contracts.
May 24 08:37:27 terra-1 terra-fcd[9351]: 05-24 08:37 [INFO]: Migrating 0 contract
May 24 08:37:27 terra-1 terra-fcd[9351]: 05-24 08:37 [INFO]: Migrated 0 contract
May 24 08:37:27 terra-1 terra-fcd[9351]: 05-24 08:37 [INFO]: collectBlock: transaction finished
May 24 08:37:27 terra-1 terra-fcd[9351]: 05-24 08:37 [INFO]: collectBlock: begin transaction for block 3895
May 24 08:37:28 terra-1 terra-fcd[9351]: 05-24 08:37 [INFO]: SaveTxs - height: 3895, txs: 0, account: 0, accountTxs: 0
May 24 08:37:28 terra-1 terra-fcd[9351]: 05-24 08:37 [INFO]: Storing 0 codes and 0 contracts.
May 24 08:37:28 terra-1 terra-fcd[9351]: 05-24 08:37 [INFO]: Stored 0 codes and 0 contracts.
May 24 08:37:28 terra-1 terra-fcd[9351]: 05-24 08:37 [INFO]: Migrating 0 contract
May 24 08:37:28 terra-1 terra-fcd[9351]: 05-24 08:37 [INFO]: Migrated 0 contract
May 24 08:37:28 terra-1 terra-fcd[9351]: 05-24 08:37 [INFO]: Save reward Fri Sep 04 2020 12:13:00 GMT+0000 (Coordinated Universal Time) success.
May 24 08:37:28 terra-1 terra-fcd[9351]: 05-24 08:37 [INFO]: Save network - success.
May 24 08:37:28 terra-1 terra-fcd[9351]: 05-24 08:37 [INFO]: collectBlock: transaction finished
May 24 08:37:28 terra-1 terra-fcd[9351]: 05-24 08:37 [INFO]: collectBlock: begin transaction for block 3896
...

When we are checking the FCD api for validators it looks like this:

curl http://10.xxx.xxx.xxx:3060/v1/staking/validators
[]

and for staking information the delegations are missing:

curl http://10.xxx.xxx.xxx:3060/v1/staking/terra12m43m29a5wq88dgrcvy6znc92sv7crlezgdfur
{"delegationTotal":"16910805","undelegations":[],"rewards":{"total":"440018.74521055323872014147","denoms":[{"denom":"uluna","amount":"426580"},{"denom":"ukrw","amount":"5611817"},{"denom":"usdr","amount":"274"},{"denom":"uusd","amount":"76804"},{"denom":"uaud","amount":"4"},{"denom":"ueur","amount":"11"},{"denom":"ugbp","amount":"1"},{"denom":"ujpy","amount":"9"},{"denom":"umnt","amount":"183032"}]},"validators":[],"myDelegations":[],"availableLuna":"953146855"}

The configuration is pointing to the public endpoints:

$ cat .envrc
export TYPEORM_CONNECTION=postgres
export TYPEORM_HOST=127.0.0.1
export TYPEORM_USERNAME=terra_fcd
export TYPEORM_PASSWORD=xxxx
export TYPEORM_DATABASE=terra_fcd
export TYPEORM_PORT=5432 
export TYPEORM_SYNCHRONIZE=true
export TYPEORM_LOGGING=true
export TYPEORM_ENTITIES=src/orm/*Entity.ts
export TYPEORM_MIGRATIONS=src/orm/migration/*.ts

export SERVER_PORT=3060
export CHAIN_ID=tequila-0004
export LCD_URI=https://tequila-lcd.terra.dev
export FCD_URI=https://tequila-fcd.terra.dev
export RPC_URI=https://tequila-fcd.terra.dev
export BYPASS_URI=https://tequila-fcd.terra.dev
export MIRROR_GRAPH_URI=https://tequila-graph.mirror.finance/graphql
export STATION_STATUS_JSON=https://terra.money/station/version-web.json
export SENTRY_DSN=
export SC_AUTH_KEY=

Many thanks,
bert

FCD failing after restart

Hey folks, I'm using the branch bombay (since it contains some variables that I needed) and I could sync the whole columbus-5 just fine. However, after a restart I'm getting the following error

12-06 17:16 [ERROR]: Cannot destructure property 'tx_response' of '(intermediate value)' as it is undefined.
TypeError: Cannot destructure property 'tx_response' of '(intermediate value)' as it is undefined.
    at Object.getTx (/app/src/lib/lcd.ts:55:11)
    at async generateLcdTransactionToTxEntity (/app/src/collector/block/tx.ts:166:14)

Any ideas on how to fix/workaround this?

Complete missing types

Modules to lookup (Subtask).

  • collector

    • block
    • validator
    • staking
    • gov
  • REST API

    • staking
    • gov
    • market
    • dashboards

Collector Run Block Height Error

I get this error when I run npm run collector with CHAIN_ID = columbus-5

[ERROR]: /blocks/1 500 - {"error":"height 1 is not available, lowest height is 4724001"}

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.