Skip to content
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

ingest/ledgerbackend: Let filewatcher check for binary hash to detect captive core updates. #4050

Merged
merged 2 commits into from
Nov 8, 2021

Conversation

erika-sdf
Copy link
Contributor

@erika-sdf erika-sdf commented Nov 5, 2021

PR Checklist

PR Structure

  • This PR has reasonably narrow scope (if not, break it down into smaller PRs).
  • This PR avoids mixing refactoring changes with feature changes (split into two PRs
    otherwise).
  • This PR's title starts with name of package that is most changed in the PR, ex.
    services/friendbot, or all or doc if the changes are broad or impact many
    packages.

Thoroughness

  • This PR adds tests for the most critical parts of the new functionality or fixes.
  • I've updated any docs (developer docs, .md
    files, etc... affected by this change). Take a look in the docs folder for a given service,
    like this one.

Release planning

  • I've updated the relevant CHANGELOG (here for Horizon) if
    needed with deprecations, added features, breaking changes, and DB schema changes.
  • I've decided if this PR requires a new major/minor version according to
    semver, or if it's mainly a patch change. The PR is targeted at the next
    release branch if it's not a patch change.

What

Let file_watcher check for binary hash to detect captive core updates.

Why

Horizon watches it's captive stellar-core binary timestamp to detect if a new version has been deployed. However, the binaries are timestamped with the package changelog, which is not dynamically updated during build.

Known limitations

The hash function currently takes < ~30ms to finish. The 10 second duration for file_watcher's loop should be sufficient.

"github.com/stellar/go/support/log"
)

type hash []byte
Copy link
Contributor

Choose a reason for hiding this comment

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

nit: I don't think this type alias provides much benefit since we end up using bytes.Equal to compare hashes anyways

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Fair point. I slightly prefer to keep the type definition though, so I defined a Equals method for type hash that just calls byte.Equals.

Copy link
Contributor

@Shaptic Shaptic left a comment

Choose a reason for hiding this comment

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

We could've kept the old watcher, but I doubt anyone would miss it. LGTM 👍 Just one comment below ⬇️

ingest/ledgerbackend/file_watcher.go Outdated Show resolved Hide resolved
"github.com/stellar/go/support/log"
)

type hash []byte

func (h *hash) Equals(other hash) bool {
Copy link
Contributor

Choose a reason for hiding this comment

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

what's the rationale for making the function have a pointer receiver?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I wasn't thinking too much about it. I think defining it on the object itself makes a copy of it, which doesn't seem like a big deal either way. Do you have a reason to prefer one or the other?

Copy link
Contributor

Choose a reason for hiding this comment

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

In https://github.com/golang/go/wiki/CodeReviewComments#receiver-type it states:

If the receiver is a slice and the method doesn't reslice or reallocate the slice, don't use a pointer to it.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Sounds good to me. Updated.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
4 participants