Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Wrong `ObjectStore` key logged when the backup object store can't be retrieved in the instance sidecar

Open Beginner friendly
  • Is something wrong?
#1,142 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
2/5
Estimated time
1-3 hours
Newbie friendliness
88/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Active
Tech stack
go, postgresql
Domain
backend, databases

Research direction

Review internal/cnpgi/instance/backup.go in Backup and internal/cnpgi/instance/metrics.go in Collect. Compare the key passed to GetBarmanObjectKey() with the key recorded in each error log, then verify both paths report the requested backup ObjectStore key when lookup fails.

Written by the indexing model from the issue text.

Description

Description

In the instance sidecar, two code paths fetch the cluster's backup ObjectStore with GetBarmanObjectKey(), but their error log reports GetRecoveryBarmanObjectKey():

internal/cnpgi/instance/backup.go (Backup):

var objectStore barmancloudv1.ObjectStore
if err := b.Client.Get(ctx, configuration.GetBarmanObjectKey(), &objectStore); err != nil {
 contextLogger.Error(err, "while getting object store", "key", configuration.GetRecoveryBarmanObjectKey())
 return nil, err
}

internal/cnpgi/instance/metrics.go (Collect) has the same lines.

So when the lookup fails, the key field names a different object from the one that was requested:

  • on a cluster without a recovery source (the usual case), RecoveryBarmanObjectName is empty, so key has an empty name;
  • on a cluster bootstrapped from an ObjectStore through externalClusters, key names the recovery ObjectStore, which exists, pointing the reader at the wrong object.
Impact

Low, but confusing. The error message itself (for example objectstores.barmancloud.cnpg.io "s3-store" not found, or ... is forbidden) still has the right name, so the information is in the log line. But the structured key field contradicts it, and anything that filters or alerts on key gets the wrong value. Collect runs on every metrics scrape, so a missing or forbidden ObjectStore repeats the misleading line on every scrape.

This is the same kind of problem as #539/#504, which were about the operator pre-hook in reconciler.go. These two lines are on the instance side and weren't covered there.

History

The backup.go line dates from e4735a2 (#83, "separate recovery object store from replica source"). The metrics.go one was added in 33172b6 (#459) with the same lines. Open PR #1076 touches the surrounding code in backup.go but leaves this line as it is.

Proposed fix

Log configuration.GetBarmanObjectKey() in both places, the key that is actually passed to Get. I'm happy to send the PR.

How this was found

While working on #1140 on my fork, I ran an AI code review (Claude Code) over my change. It flagged the mismatched key in backup.go, even though my change didn't touch that line. I then searched the code base for the same pattern, which found the copy in metrics.go, and confirmed both on main by reading the code. I haven't triggered the failing lookup on a live cluster, so the error messages quoted above are examples, not captured output.

I used an AI assistant (Claude) to help find this and draft this issue, as the AI policy asks for disclosure.

Dominant language
Go
Stars
196
Forks
76
Avg merge
4d 13h
Merged PRs (30d)
19

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from cloudnative-pg/plugin-barman-cloud

All issues in cloudnative-pg/plugin-barman-cloud

Similar issues

More Go issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.