Error in bridge logs

Polygon Mainnet (PoS) POS Validators
1

Hi Polygon team,
I hope it’s the right place to ask a question about setting up an archive Polygon node (if not feel free to re-route me to wherever I can ask).

Setup :
Running this with Kubernetes, PV set to a max of 16TB storage, deployment is having a max limit of 20GB ram and 4 core cpu limit.
Running a pod from a Dockerfile starting from Ubuntu 20.04.4 (Focal Fossa)
Building Heimdall from https://github.com/maticnetwork/heimdall/archive/refs/tags/v0.2.9.zip (unzip + make build)

Run Heimdall related with

heimdall  start –home my_home > my_heimdall_log_path.log &
heimdall rest-server –home my_home > my_rest_log_path.log &

sleep 50 (so I’m sure it’s all started)

bridge start –all –home my_home > my_bridge_log_path.log

I’m also starting off a snapshot https://matic-blockchain-snapshots.s3-accelerate.amazonaws.com/matic-mainnet/heimdall-snapshot-2022-08-02.tar.gz

It syncs OK and a curl to localhost:26657/status shows catching_up: false at which point I start an Erigon node as well.

At some point I can see my bridge logs show this error:

E[2022-08-05|06:58:43.806] Error fetching block header from mainchain while calculating next span seed module=bor error="Post \http://localhost:9545\: dial tcp [::1]:9545: connect: connection refused"
E[2022-08-05|06:58:43.807] Error fetching proposers                     module=span service=processor error="Error while fetching data from url: http://0.0.0.0:1317/bor/prepare-next-span?chain_id=137&proposer=0xc19d41fa1f612983322ee8b5b68a71f3bdbf3320&span_id=4930&start_block=31545856, status: 400"

I made sure 9545 is exposed in Dockerfile as well as from Kubernetes deployment and service as well.
A bit of research done and I stumbled upon something that seems similar:
https://docs.polygon.technology/docs/maintain/validate/faq/known-issues/#16-error-error-while-fetching-data-from-url

My questions are:
How can I fix this error? A manual stop/restart of the bridge does not sound like an option for long-term use.
Does this affect my syncing (both for Heimdall and Erigon) OR the syncing speed in any way?
I got another question as well – as I was running the same setup but with Bor in the past and now switched to Erigon I’m still waiting for Heimdall to be in catching_up: false state and then start Erigon as it was with Bor.
Is this still the case or I can start Erigon even if Heimdall is still catching up?

Thanks in advance!
Best,
Dimitar

1 Like
2

Hi @dvarbenov.

I think that @Jackson and/or @Gobinath will be able to help you with this.

1 Like
3

@dvarbenov

Good Day answering your query bridge doesn’t have a part to play in the archive node setup as per my understanding.

Bridge comes in handy only in cases of Validator and RPC nodes in your case it’s the archive nodes.

The highlighted errors are regarding the block proposer.

Still to confirm we would like to know if is there something affecting your node’s functionality if so please share more logs.

Also, I’m noticing you are on the wrong Heimdall release the latest version is 0.2.11.

And finally, we recommend you follow our official docs

1 Like
4

Hi and thanks for your reply.
I think it’s not affecting functionalities of the node but I’m wondering if it could affect performance as syncing seems a bit slow?

5

There are several symptoms that can indicate that scheduled refreshes are not performing as expected. Symptoms might include, but not limited to, the following:

  • As the site admin or data source owner, you see an alert on Tableau Cloud that a scheduled refresh could not complete.
  • As the site admin or data source owner, you receive an email notification from Tableau indicating that a Bridge refresh could not complete.