Skip to content

sidechain: change pooling time to 1s#4074

Open
carpawell wants to merge 1 commit into
masterfrom
fix/meta-sync-pooling-time
Open

sidechain: change pooling time to 1s#4074
carpawell wants to merge 1 commit into
masterfrom
fix/meta-sync-pooling-time

Conversation

@carpawell

Copy link
Copy Markdown
Member

In most cases meta chain will see fractions of seconds as a config, that is too small period that make logs full of:

info blockchain/blockchain.go:365 waiting for synchronization with the blockchain network... {"component": "metadata chain (IR)"}
info sidechain/sidechain.go:116 waiting for synchronization with the blockchain network... {"component": "metadata chain (SN)"}

In most cases, meta chain will see fractions of a second as a config, which is
too small a period that makes logs full of:
```
info blockchain/blockchain.go:365 waiting for synchronization with the blockchain network... {"component": "metadata chain (IR)"}
info sidechain/sidechain.go:116 waiting for synchronization with the blockchain network... {"component": "metadata chain (SN)"}
```

Signed-off-by: Pavel Karpy <carpawell@nspcc.io>
@carpawell carpawell force-pushed the fix/meta-sync-pooling-time branch from 263056f to a419019 Compare July 8, 2026 15:41
@codecov

codecov Bot commented Jul 8, 2026

Copy link
Copy Markdown

Codecov Report

❌ Patch coverage is 0% with 1 line in your changes missing coverage. Please review.
✅ Project coverage is 26.30%. Comparing base (5df4d7b) to head (a419019).

Files with missing lines Patch % Lines
pkg/services/sidechain/sidechain.go 0.00% 1 Missing ⚠️
Additional details and impacted files
@@           Coverage Diff           @@
##           master    #4074   +/-   ##
=======================================
  Coverage   26.29%   26.30%           
=======================================
  Files         671      671           
  Lines       45865    45865           
=======================================
+ Hits        12060    12063    +3     
+ Misses      32673    32671    -2     
+ Partials     1132     1131    -1     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

t := time.NewTicker(s.core.GetConfig().Genesis.TimePerBlock)
t := time.NewTicker(time.Second)

for {

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What's the purpose of this loop?

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

notify if we are in sync. the same way for FSchain:

for {
x.logger.Info("waiting for synchronization with the blockchain network...")
select {
case <-ctx.Done():
return fmt.Errorf("await state sync: %w", ctx.Err())
case <-t.C:
if x.netServer.IsInSync() {
x.logger.Info("blockchain state successfully synchronized")
return nil
}
}
}
. how do i know there is a problem if not this way? you saw logs, they told you smth was wrong

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Usually netServer has something to say on its own when it's in sync.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Then this can be also changed for FS chain.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

so drop both loops? for neofs-dev it is clearer than neo-go internal logs

@carpawell carpawell Jul 8, 2026

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i often searched for blockchain state successfully synchronized to be sure everything was ok

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

To me they're useless, if you're running a netServer it will log the moment it detects sync state.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

neo-go's logger can be suppressed, it can be changed independently. current solution is neofs app level to me

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I still think it's useless, but if you need it we can leave it. It has to be consistent with FS chain though.

go s.netServer.Start()

t := time.NewTicker(s.core.GetConfig().Genesis.TimePerBlock)
t := time.NewTicker(time.Second)

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

if frequent log records is the only problem, i'd just move waiting... record before loop

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

as for me: if something is wrong, it would be better to repeat it until smth is done

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

as i understand this is a background job. If observer does not care about synchronized message, it does not matter how many waiting... there was. If cares, again does not matter

overall, any spam is annoying, so im ok with this change

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

as i understand this is a background job

yes it is. meta was enabled and configured incorrectly, there are no blocks/objects on the node, and this log is the only way to understand that smth must be done (ok, @roman-khimov, also says that there is smth inside neo-go that would also tell you that there are no new blocks, but i do not want to rely on it)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants