-
Notifications
You must be signed in to change notification settings - Fork 864
Flatten sei-tendermint go mod into sei-chain
#2817
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
Flatten the sei-tendermint go module into sei-chain tin reduce dependency management complexity and error-prone multi layer replace directives. Part of PLT-6
|
The latest Buf updates on your PR. Results from workflow Buf / buf (pull_request).
|
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #2817 +/- ##
===========================================
- Coverage 56.77% 48.13% -8.65%
===========================================
Files 2070 666 -1404
Lines 168274 50121 -118153
===========================================
- Hits 95542 24126 -71416
+ Misses 64247 23885 -40362
+ Partials 8485 2110 -6375
Flags with carried forward coverage won't be shown. Click here to find out more.
🚀 New features to boost your workflow:
|
* errcheck: 50 * goconst: 1 * goimports: 3 * gosec: 50 * ineffassign: 2 * misspell: 2 * prealloc: 17 * staticcheck: 45 * unconvert: 1
Codecov Report❌ Patch coverage is Additional details and impacted files@@ Coverage Diff @@
## main #2817 +/- ##
==========================================
+ Coverage 56.77% 57.11% +0.33%
==========================================
Files 2070 2088 +18
Lines 168274 171053 +2779
==========================================
+ Hits 95542 97694 +2152
- Misses 64247 64682 +435
- Partials 8485 8677 +192
Flags with carried forward coverage won't be shown. Click here to find out more.
🚀 New features to boost your workflow:
|
| dumpDebugData(ctx, logger, rpc, dumpArgs) | ||
| } | ||
| ticker := time.NewTicker(time.Duration(frequency) * time.Second) //nolint: gosec | ||
| defer ticker.Stop() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: not needed since 1.23
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Although it is not strictly needed after 1.23, there are a few reasons to still call stop: communication of intent, defensive programming in case of refactoring that may move the ticker and so on.
But the main functional reason to call it is that it would stop the ticker immediately, instead of leaving it to GC. It makes up a more predictable code behaviour.
| @@ -153,19 +153,19 @@ func ProofFromProto(pb *tmcrypto.Proof) (*Proof, error) { | |||
| // Recursive impl. | |||
| func computeHashFromAunts(index, total int64, leafHash []byte, innerHashes [][]byte) ([]byte, error) { | |||
| if index >= total || index < 0 || total <= 0 { | |||
| return nil, fmt.Errorf("Calling computeHashFromAunts() with invalid index (%d) and total (%d)", index, total) | |||
| return nil, fmt.Errorf("calling computeHashFromAunts() with invalid index (%d) and total (%d)", index, total) | |||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
fyi, the lint which checks that the first letter of the error is lowercase is imprecise and super annoying - sometimes the first letter simply has to be uppercase (like when the first word is a name of a public type, or sth). I'd recommend to disable it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agreed that ST1005 can be annoying, but I'd push back on disabling it entirely; the consistency alone is worth it. The general practice is to instead capitalise the first letter in logs, because they typically are a list of sentences. See:
The "(unless beginning with proper nouns or acronyms)" is loose. As a reference, I very rarely come across Go SDK implementation that falls in that exceptional category.
In this specific case, the error should indeed start with lower case.
| @@ -336,7 +336,7 @@ func newValidBlockMessageFromProto(pb *tmcons.NewValidBlock) (*NewValidBlockMess | |||
| func proposalMessageFromProto(pb *tmcons.Proposal) (*ProposalMessage, error) { | |||
| proposal, err := types.ProposalFromProto(&pb.Proposal) | |||
| if err != nil { | |||
| return nil, fmt.Errorf("Proposal: %w", err) | |||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
like here: the field is "Proposal", not "proposal". Lowercasing is not helpful.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sure, we can keep it uppercase and add a lint ignore. But looking at the repo, the error strings are already inconsistent. Rather than adding lint ignores case by case, I'd suggest adopting a consistent "verb noun/Noun: %w" pattern; example
fmt.Errorf("converting Proposal: %w", err)This reads well when errors chain and eventually logged; e.g. :
Failed to process peer message: converting Proposal: invalid signature length
vs.
Failed to process peer message: Proposal: invalid signature length
...and naturally avoids the capitalization lint issue entirely. It also matches the Go stdlib pattern (e.g. "tls: failed to find certificate...") where error strings compose mid-sentence as described in the Go Code Review Comments.
This repo doesn't have a logging convention yet. Adopting "verb noun/Noun/WhatEver: %w" now means fewer lint ignores going forward and clearer log lines for debugging.
| @@ -394,7 +395,7 @@ func (ps *PeerState) ApplyNewRoundStepMessage(msg *NewRoundStepMessage) { | |||
| defer ps.mtx.Unlock() | |||
|
|
|||
| // ignore duplicates or decreases | |||
| if msg.HRS.Cmp(ps.PRS.HRS) <= 0 { | |||
| if msg.Cmp(ps.PRS.HRS) <= 0 { | |||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this lint does something weird - we compare HRS embedded fields here. Hiding that fact harms readability.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is from QF1008 staticcheck linter. Its rationale is rooted in Effective Go, where the entire point of embedding is promotion; to avoid bookkeeping and decouple from internals.
I'm against always using the explicit form, because that defeats the purpose of the language feature. In this case, HRS is a core type with no clashing receiver functions on both embedder and embedded types in this repo.
If HRS is more than an implementation detail, then my recommendation is to not embed it; use a named field instead. That forces callers to always spell out "I want to compare X and Y by their progress in terms of height, round, step". What harms readability most is allowing two ways of doing the same thing when the intent is to always use one. Keeping QF1008 enabled helps enforce that consistency.
Happy to revert this change in any case.
| @@ -298,7 +298,8 @@ func (ps *PeerState) EnsureVoteBitArrays(height int64, numValidators int) { | |||
| } | |||
|
|
|||
| func (ps *PeerState) ensureVoteBitArrays(height int64, numValidators int) { | |||
| if ps.PRS.Height == height { | |||
| switch ps.PRS.Height { | |||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@masih wdyt about this if -> switch lint? Do you find it more readable?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This wasn't a linter suggestion; it was a style choice on my part. The switch makes the two height cases immediately visible as the top-level branching structure, with the nil checks as secondary logic within each. With nested if/else, the height comparison and nil checks sit at the same visual level.
Happy to revert if you prefer the original. You'll be staring at this code more than I will.
| @@ -215,7 +215,7 @@ func (app *Application) FinalizeBlock(_ context.Context, req *abci.RequestFinali | |||
| }, | |||
| { | |||
| Key: []byte("height"), | |||
| Value: []byte(strconv.Itoa(int(req.Height))), | |||
| Value: []byte(strconv.FormatInt(req.Height, 10)), | |||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
huh, how is this better?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It is better because, Itoa literally calls FormatInt under the hood. The issue is correctness:
req.Height is int64. The original code does strconv.Itoa(int(req.Height)), which casts int64 → int. On 64-bit platforms int is 64 bits so this is fine, but int is only guaranteed to be platform-sized; on a 32-bit platform it's 32 bits, and that cast silently truncates any height above ~2.1 billion. FormatInt takes int64 directly, so there's no cast and no truncation risk.
Even if this will never run on 32-bit in practice, the cast is doing nothing useful; it's an extra conversion that only exists because Itoa takes int instead of int64.
Simply put, FormatInt is the right function when you already have an int64.
pompon0
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM for code in sei-tendermint dir.
Flatten the sei-tendermint go module into sei-chain tin reduce dependency management complexity and error-prone multi layer replace directives.
Part of PLT-6