chore(deps): bump github.com/uber-go/tally from 3.5.0+incompatible to 5.0.0+incompatible#154
Conversation
|
|
Up to standards ✅🟢 Issues
|
| Metric | Results |
|---|---|
| Complexity | 0 |
| Duplication | 0 |
NEW Get contextual insights on your PRs based on Codacy's metrics, along with PR and Jira context, without leaving GitHub. Enable AI reviewer
TIP This summary will be updated as you push new changes.
Bumps [github.com/uber-go/tally](https://github.com/uber-go/tally) from 3.5.0+incompatible to 5.0.0+incompatible. - [Release notes](https://github.com/uber-go/tally/releases) - [Commits](uber-go/tally@v3.5.0...v5.0.0) --- updated-dependencies: - dependency-name: github.com/uber-go/tally dependency-version: 5.0.0+incompatible dependency-type: direct:production update-type: version-update:semver-major ... Signed-off-by: dependabot[bot] <support@github.com>
82cf31d to
9eabab0
Compare
📝 WalkthroughWalkthroughThis PR updates two Go module dependencies: ChangesDependency Management
Estimated code review effort🎯 1 (Trivial) | ⏱️ ~2 minutes Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Comment |
|
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@go.mod`:
- Line 20: Provide upstream authoritative links (release notes, changelog, or
specific commits/PRs) that document behavioral changes from v3.5.0→v5.0.0 of
github.com/uber-go/tally affecting our integration: specifically confirm the
io.Closer contract returned by tally.NewRootScope (does it still perform a final
flush and stop reporter loops on Close/Destroy), any changes to
promreporter.NewReporter and Reporter.HTTPHandler behavior (how metrics are
sourced/served, and whether Separator/promreporter.DefaultSeparator or
tag/prefix handling changed), and any changes to flush/report interval timing
semantics (CachedReporter behavior and cfg.FlushInterval). Reference these
symbols in your findings: tally.NewRootScope, promreporter.NewReporter,
Reporter.HTTPHandler, CachedReporter, Separator/promreporter.DefaultSeparator,
cfg.FlushInterval, and Destroy/Closer, and include direct URLs to the upstream
release notes/commits/PRs that explicitly state the behavior differences.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro Plus
Run ID: 9f07c6bc-3068-4565-a61e-3aac8b6461ac
⛔ Files ignored due to path filters (1)
go.sumis excluded by!**/*.sum
📒 Files selected for processing (1)
go.mod
| github.com/redis/go-redis/v9 v9.19.0 | ||
| github.com/stretchr/testify v1.11.1 | ||
| github.com/uber-go/tally v3.5.0+incompatible | ||
| github.com/uber-go/tally v5.0.0+incompatible |
There was a problem hiding this comment.
🧩 Analysis chain
🌐 Web query:
`For github.com/uber-go/tally v5.0.0+incompatible:
- Are tally.NewRootScope and tally.ScopeOptions (Prefix, Tags, CachedReporter, Separator) API-compatible with v3.5.0?
- Did default reporting interval, scope caching/pooling, or tag/key generation semantics change between v3.5.0 and v5.0.0?
- Are there migration notes for promreporter integrations that could affect metric names, cardinality, or lifecycle/Close behavior?
Please provide links to official release notes/changelog/commits.`
💡 Result:
- API compatibility of tally.NewRootScope and tally.ScopeOptions (v3.5.0 vs v5.0.0) Based on the current upstream source for ScopeOptions and NewRootScope, the fields/shape you named exist with the same top-level names: ScopeOptions has Prefix, Tags, CachedReporter, Separator (and Reporter), and NewRootScope signature is NewRootScope(opts ScopeOptions, interval time.Duration) (Scope, io.Closer). [1] However, I could not retrieve the exact v3.5.0 (tag/commit) source in the material gathered here to conclusively prove there were no field additions/behavioral changes specifically between v3.5.0 and v5.0.0. What we can say with evidence is that the named options exist and NewRootScope takes the same parameter types and returns (Scope, io.Closer) in the upstream code. [1] 2) Changes in default reporting interval, scope caching/pooling, or tag/key generation semantics (v3.5.0 vs v5.0.0) I did not find authoritative release-notes text in the gathered results that explicitly compares v3.5.0 vs v5.0.0 for any of the following: default reporting interval, scope caching/pooling, or tag/key generation semantics. What I can cite from upstream source is that ScopeOptions uses DefaultSeparator when Separator is empty and that Tags are copied/sanitized at scope creation (so mutation of the map after scope construction is not reflected). [1] Additionally, the repository releases page contains an entry explicitly mentioning “Set default reporting interval” (but the snippet does not identify the exact version boundary between v3.5.0 and v5.0.0). [2] So: there is evidence that separator defaults and tag sanitization/copying are part of the scope creation semantics, but there is not enough evidence in the provided search results to say those semantics changed specifically between v3.5.0 and v5.0.0. 3) Migration notes for promreporter integrations that could affect metric names, cardinality, or lifecycle/Close behavior I did not find promreporter-specific migration notes in the gathered results. But there is evidence of lifecycle/Close semantics changes in tally in general: the commit introducing independent subscope closing through io.Closer (
#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:
- 1: https://github.com/uber-go/tally/blob/master/scope.go
- 2: https://github.com/uber-go/tally/releases
- 3: uber-go/tally@2499bd2
- 4: https://github.com/uber-go/tally/blob/88c09fd7917eb50cecb296ead18bd72493190fac/types.go
- 5: Add backward compatibility configs for tally to otel migration temporalio/temporal#7235
🏁 Script executed:
#!/bin/bash
set -euo pipefail
rg -n "NewRootScope|ScopeOptions|CachedReporter|Separator|promreporter|prometheus|Close\(" -S pkg/metrics || true
ls -la pkg/metrics || true
if [ -f pkg/metrics/metrics.go ]; then sed -n '1,220p' pkg/metrics/metrics.go; fi
if [ -f pkg/metrics/metrics_test.go ]; then sed -n '1,260p' pkg/metrics/metrics_test.go; fiRepository: 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:
- 1: Using new v5.0.0 tag produces errors and unbuildable code uber-go/tally#272
- 2: https://pkg.go.dev/github.com/uber-go/tally@v3.5.10+incompatible
- 3: https://github.com/uber-go/tally/blob/master/scope.go
- 4: https://github.com/uber-go/tally/blob/e30762037067267e4459646e120f88af38cf0bb9/scope.go
- 5: https://github.com/uber-go/tally
- 6: uber-go/tally@2499bd2
- 7: https://help.tallysolutions.com/release-notes-tallyprime-5/
- 8: https://help.tallysolutions.com/release-notes-tally-prime-developer-release-5/
- 9: https://help.tallysolutions.com/article/ts9rel54/ts9/release_notes.htm/?strInvokedFromSupportCentreFlag=1&strSCIframeName=
🌐 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:
- 1: uber-go/tally@485eecc
- 2: https://github.com/uber-go/tally/blob/485eecc4af34effec05a1f06aa6fb9c8e09a9750/version.go
- 3: https://github.com/uber-go/tally/blob/master/scope.go
- 4: https://github.com/uber-go/tally/blob/master/README.md
🌐 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:
- 1: Using new v5.0.0 tag produces errors and unbuildable code uber-go/tally#272
- 2: https://github.com/uber-go/tally/blob/master/prometheus/README.md
- 3: https://pkg.go.dev/github.com/uber-go/tally/prometheus
- 4: Flush reporter from root scope only uber-go/tally#108
- 5: https://github.com/uber-go/tally/blob/a80396bb6850d098eea5088ac37f5d208cf3b034/scope.go
- 6: https://pkg.go.dev/github.com/uber-go/tally/v4/prometheus
Validate uber-go/tally v5.0.0+incompatible scope/reporter lifecycle before merging.
This bump affects runtime metrics behavior because this repo:
- builds a Prometheus reporter (
promreporter.NewReporter) and root scope (tally.NewRootScopewithCachedReporter+Separator: promreporter.DefaultSeparatorandcfg.FlushInterval) - serves metrics via
Reporter.HTTPHandler() - shuts down via the
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+incompatible may 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.0 behavior for:
tally.NewRootScope’s returnedio.Closercontract (final flush + stopping the reporter loop)- Prometheus reporter behavior (
promreporter): howHTTPHandler()sources metrics and whether separator/prefix/tag handling changed - flush/report interval timing semantics
github.com/uber-go/tally v5.0.0+incompatible
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@go.mod` at line 20, Provide upstream authoritative links (release notes,
changelog, or specific commits/PRs) that document behavioral changes from
v3.5.0→v5.0.0 of github.com/uber-go/tally affecting our integration:
specifically confirm the io.Closer contract returned by tally.NewRootScope (does
it still perform a final flush and stop reporter loops on Close/Destroy), any
changes to promreporter.NewReporter and Reporter.HTTPHandler behavior (how
metrics are sourced/served, and whether Separator/promreporter.DefaultSeparator
or tag/prefix handling changed), and any changes to flush/report interval timing
semantics (CachedReporter behavior and cfg.FlushInterval). Reference these
symbols in your findings: tally.NewRootScope, promreporter.NewReporter,
Reporter.HTTPHandler, CachedReporter, Separator/promreporter.DefaultSeparator,
cfg.FlushInterval, and Destroy/Closer, and include direct URLs to the upstream
release notes/commits/PRs that explicitly state the behavior differences.



Bumps github.com/uber-go/tally from 3.5.0+incompatible to 5.0.0+incompatible.
Release notes
Sourced from github.com/uber-go/tally's releases.
... (truncated)
Commits
53c9870Update branch version to 5.0.0b94293fRefactor metric handling and update imports for consistency2440a73Implement optimized key generation and pooling mechanismsadabb7aSimplify codebase and resolve goroutine leaksd07a05cadd comprehensive performance and regression test suite3453d78Optimize reporter performance and fix concurrency issues1240ca4Enhance Scope Reporting with Parallel Processing and String Interning21914b2Refactor Metrics Storage to Use sync.Map for Improved Concurrencybdca539Implement Scope Pooling Mechanism for Enhanced Memory Efficiency0f713afImplement Subscope Eviction Mechanism for Improved Memory ManagementSummary by CodeRabbit