Skip to content

Conversation

@ntninja
Copy link
Contributor

@ntninja ntninja commented Feb 12, 2024

Description

The borg job logic expects the profile_name key to be unconditionally present in the params if any data is received on stderr. This causes the BorgVersionJob (which didn’t set this param) to fail if any unexpected output – such as LD_PRELOAD warnings – in generated while running borg --version. This in turn causes Vorta to silently (other than an unrelated looking exception in the console output) fall back to assuming borg 1.1.0 as the borg version.

Related Issue

Please don’t make me create an issue for this…

Motivation and Context

Borg version detection currently silently fails in environments that have LD_PRELOAD set in a way to causes warnings to be emitted.

How Has This Been Tested?

The change is pretty trivial, so I just tested with and without.

Types of changes

  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

  • I have read the CONTRIBUTING guide.
  • My code follows the code style of this project.
  • My change requires a change to the documentation.
  • I have updated the documentation accordingly.
  • I have added tests to cover my changes.
  • All new and existing tests passed.

I provide my contribution under the terms of the license of this repository and I affirm the Developer Certificate of Origin.

Copy link
Collaborator

@real-yfprojects real-yfprojects left a comment

Choose a reason for hiding this comment

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

Thank you for taking the time to create this PR. You can find my commentary below.

@m3nu
Copy link
Contributor

m3nu commented Feb 13, 2024

Was also looking at this. Currently wondering about the test timeouts on Linux. A Github glitch?

@real-yfprojects
Copy link
Collaborator

real-yfprojects commented Feb 14, 2024

A Github glitch?

Not sure what it is, but the line collecting ... collected 166 items was already produced 13min 4min in. So either it was idling for 7 minutes or there is a step in pytest that took this long and doesn't produce any output.

…on stderr

The borg job logic expects the `profile_name` key to be unconditionally present in the params if any data is received on stderr. This causes the BorgVersionJob (which didn’t set this param) to fail if any unexpected output – such as LD_PRELOAD warnings – in generated while running `borg --version`. This in turn causes Vorta to silently (other than an unrelated looking exception in the console output) fall back to assuming borg 1.1.0 as the borg version.
Copy link
Contributor

@m3nu m3nu left a comment

Choose a reason for hiding this comment

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

🔍 Code Review

PR: #1934 - Prevent exception while running BorgVersionJob with unexpected lines on stderr
Branch: patch-1master
Changes: +1 / -0 lines across 1 file

📋 Summary

This PR fixes a KeyError that occurs when BorgVersionJob encounters unexpected stderr output (such as LD_PRELOAD warnings). The fix adds the missing profile_name key that the base class's stderr handling expects.

✅ What's Good

  • Correctly identifies the root cause: borg_job.py:318 accesses self.params["profile_name"] when logging non-JSON stderr output
  • Minimal, targeted fix - only adds what's necessary
  • The BorgVersionJob is unique in not taking a profile (unlike other Borg jobs), so this edge case is easy to miss
  • Value 'default' is consistent with how site_id defaults work in the codebase

📊 Verdict: APPROVE ✅

The fix is straightforward and correctly addresses the issue. The change ensures Borg version detection doesn't silently fail in environments with LD_PRELOAD warnings.


🤖 Reviewed by Claude Code

@m3nu m3nu merged commit d1e2639 into borgbase:master Jan 2, 2026
4 of 5 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants