-
Notifications
You must be signed in to change notification settings - Fork 2
chore(deps): bump github.com/uber-go/tally from 3.5.0+incompatible to 5.0.0+incompatible #154
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
Open
dependabot
wants to merge
1
commit into
main
Choose a base branch
from
dependabot/go_modules/main/github.com/uber-go/tally-5.0.0incompatible
base: main
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Open
Changes from all commits
Commits
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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.
🧩 Analysis chain
🌐 Web query:
`For github.com/uber-go/tally v5.0.0+incompatible:
Please provide links to official release notes/changelog/commits.`
💡 Result:
#158) shows that closing a non-root scope doesn’t report registry / doesn’t close the base reporter; the root scope reports the registry before closing and then closes the base reporter (if it implements io.Closer). [3] This can affect metric emission timing/lifecycle if your integration assumes Close always flushes/removes registry entries immediately for all scopes. On metric naming/cardinality semantics with Prometheus-style reporting: the repository docs warn that when using Prometheus reporters, users must avoid creating metrics from both parent scopes and subscopes that share the same metric name but different tag keys, as metric allocation can panic. [4] And for tag/key normalization differences (which can affect metric names/cardinality), I found a downstream integration note in Temporal’s PR about tally→OpenTelemetry migration stating that tally replaces dashes with underscores in both tag keys and values (while OTEL differs). This PR is not tally’s official migration guide, but it is an example of a semantics difference that could affect metric cardinality and naming if you port from tally. [5] Official release notes / changelog / commits - Official releases page: https://github.com/uber-go/tally/releases [2] - Scope implementation (NewRootScope + ScopeOptions fields and tag copy/sanitize; default separator behavior): https://github.com/uber-go/tally/blob/master/scope.go [1] - Independent subscope closing behavior (commit#158): uber-go/tally@2499bd2 [3] - Prometheus usage caveat about parent/subscope tag-key mismatch (types.go comment): https://github.com/uber-go/tally/blob/88c09fd7917eb50cecb296ead18bd72493190fac/types.go [4] - Temporal PR referencing tally tag normalization behavior during migration: Add backward compatibility configs for tally to otel migration temporalio/temporal#7235 [5] Confidence/limitations I can confidently point to upstream code for the API shape of ScopeOptions/NewRootScope and to upstream commits/comments describing Close and Prometheus allocation caveats. [1][3][4] But I cannot, from the gathered sources, provide a definitive, version-by-version statement about what changed specifically between v3.5.0 and v5.0.0 for default reporting interval, scope caching/pooling, or tag/key generation semantics, nor can I cite a promreporter-specific migration section for v3.5.0→v5.0.0. If you want, I can run one more targeted search round specifically for: (a) v3.5.0 release notes/changelog entry, (b) the v5.0.0 release entry around reporting interval / registry caching / tag sanitization, and (c) promreporter (or prometheus reporter) migration notes or changesets that mention metric naming/cardinality and Close/flush behavior.Citations:
🏁 Script executed:
Repository: kubeservice-stack/common
Length of output: 9723
🌐 Web query:
tally v5.0.0 breaking changes ScopeOptions CachedReporter Separator Close io.Closer💡 Result:
The version v5.0.0+incompatible of the uber-go/tally Go library appears to be problematic or potentially mislabeled [1][2]. Users have reported that attempting to use this version results in build errors, such as redeclarations and undefined methods (e.g., scopes.Inc), suggesting it may not be a stable or intended release in the context of the established v3.x or v4.x versions [1]. Regarding the specific components mentioned: - ScopeOptions, CachedReporter, Separator: These are standard, long-standing parts of the Tally API [3][4]. They are defined in the ScopeOptions struct used to initialize a root scope [3]. - Close and io.Closer: The NewRootScope function returns a Scope and an io.Closer [3][5]. The Closer is intended to be used to gracefully shut down the reporting goroutine [5]. Subscope closing functionality was explicitly enabled via io.Closer in earlier updates (e.g.,
#158) [6], which allowed independent subscope cleanup. If you are encountering build issues with v5.0.0, it is highly recommended to revert to the latest stable release (e.g., v4.x or the latest v3.x, depending on your project requirements) [1]. Note: The search results also surface "Tally Release 5.0" in the context of TallyPrime accounting software [7][8][9]. This is a completely different product from the Go metrics library and is unrelated to the technical API components you listed.Citations:
🌐 Web query:
tally v3.5.0 release notes NewRootScope ScopeOptions CachedReporter Separator💡 Result:
I can confirm what you’re asking maps to the Go library uber-go/tally’s API elements, but there aren’t any public “release notes” text/entry for version 3.5.0 beyond the release commit bumping the library version. 1) Tally v3.5.0 release notes / what changed - The “Release 3.5.0” entry in the repo corresponds to a commit that only changes the Version constant from 3.4.3 to 3.5.0 in version.go [1][2]. 2) Where the mentioned identifiers come from (their meaning in the code) These identifiers are present in tally’s Scope implementation: - ScopeOptions includes fields Reporter, CachedReporter, and Separator (plus Tags/Prefix/DefaultBuckets/SanitizeOptions, etc.) [3]. - NewRootScope takes a ScopeOptions and a reporting interval, and returns (Scope, io.Closer). The README explains the second return value stops the scope’s reporting goroutine [4]. What’s NOT found in v3.5.0 release notes - In the available “Release 3.5.0” record, there’s no changelog text listing behavioral changes to NewRootScope, ScopeOptions, CachedReporter, or Separator—only the version number bump [1][2]. If you want, tell me whether you mean uber-go/tally (Go) or a different “tally” project, and what you consider “release notes” (GitHub release page text vs. CHANGELOG vs. commit diff). Then I can locate the exact notes text for that specific project/version.
Citations:
🌐 Web query:
uber-go tally v4 v5 migration notes prometheus reporter promreporter HTTPHandler Close flush interval semantics💡 Result:
The uber-go/tally library currently lacks a stable, functional v5 release as of June 2026. Users attempting to use v5.0.0 have reported significant build errors and unresolved issues, making v4 the current standard version [1]. Migration to v5 is not recommended until the maintainers resolve these issues [1]. In regard to your questions about the Prometheus reporter, flush interval semantics, and HTTPHandler behavior, the following principles apply to the Tally framework (primarily as implemented in v4): Prometheus Reporter and HTTPHandler The Prometheus reporter in Tally is designed to work with the Prometheus Go client library [2][3]. It provides an HTTPHandler method, which returns an http.Handler that can be used to serve metrics for Prometheus scraping [2]. The reporter acts as a bridge between Tally's metric abstractions and Prometheus collectors [2]. Flush Interval Semantics Tally's flush behavior is driven by the root scope, not individual sub-scopes [4][5]. 1. Root Scope Responsibility: When a root scope is created with a reporting interval, it initializes a goroutine that runs a report loop [5]. 2. Periodic Flushes: This loop triggers a reportRegistry call, which performs the reporting and explicitly calls Flush on the reporter [5]. 3. Scope Closure: When a root scope is closed (Close is called), it performs one final flush to ensure that pending metrics are captured before the reporter is closed [5]. 4. Optimization: Logic exists to prevent redundant flushes, ensuring that Flush is typically called only once per reporting cycle from the root scope, rather than being triggered by every sub-scope [4]. If you are implementing custom reporters, note that the StatsReporter interface requires a Flush method [6]. For standard Tally usage, you do not need to manually manage these intervals; they are configured during the initialization of the root scope [5]. If you encounter unexpected flush behaviors, ensure that you are only calling Close on the root scope, as doing so on sub-scopes may not have the desired effect on global reporting [4][5].
Citations:
Validate uber-go/tally v5.0.0+incompatible scope/reporter lifecycle before merging.
This bump affects runtime metrics behavior because this repo:
promreporter.NewReporter) and root scope (tally.NewRootScopewithCachedReporter+Separator: promreporter.DefaultSeparatorandcfg.FlushInterval)Reporter.HTTPHandler()io.Closerreturned fromNewRootScope(Destroy()callscloser.Close()), so any change in flush/report-loop shutdown semantics can change what’s emitted and when.Also, upstream user reports indicate
github.com/uber-go/tally v5.0.0+incompatiblemay be problematic/mislabeled, and there’s no clearly discoverable v3.5.0→v5.0.0 migration/changelog text covering the runtime semantics this integration relies on.Request: provide an upstream link (release notes/changelog/commits) specifically covering
v3.5.0→v5.0.0behavior for:tally.NewRootScope’s returnedio.Closercontract (final flush + stopping the reporter loop)promreporter): howHTTPHandler()sources metrics and whether separator/prefix/tag handling changedgithub.com/uber-go/tally v5.0.0+incompatible🤖 Prompt for AI Agents