Skip to content

feat(backup): expose incremental_base_backup_id on BackupListReturn (#2069) - #2116

Open
Anai-Guo wants to merge 1 commit into
weaviate:mainfrom
Anai-Guo:fix/backup-list-incremental-base-id-2069
Open

feat(backup): expose incremental_base_backup_id on BackupListReturn (#2069)#2116
Anai-Guo wants to merge 1 commit into
weaviate:mainfrom
Anai-Guo:fix/backup-list-incremental-base-id-2069

Conversation

@Anai-Guo

@Anai-Guo Anai-Guo commented Aug 1, 2026

Copy link
Copy Markdown

Closes #2069.

Problem

Weaviate's GET /backups/{backend} returns incremental_base_backup_id on every item — BackupListResponseItems0 declares it, and Scheduler.List populates it for callers the handler has confirmed as root.

BackupListReturn doesn't declare the field, so executor.list_backups() (BackupListReturn(**entry)) silently drops it. There is currently no way to tell from client.backup.list_backups(...) which base backup an incremental backup was built on — the only alternative is a get_create_status() round trip per backup.

Change

One field on BackupListReturn:

incremental_base_backup_id: Optional[str] = Field(default=None)

The JSON key is snake_case server-side (json:"incremental_base_backup_id,omitempty"), so it matches the field name and needs no alias. Optional[str] with default=None is deliberate rather than a required field: the server omits the key for non-incremental backups, and also for any caller it has not confirmed as root, so its absence must stay non-fatal.

Nothing else changes — no alias on an existing field is touched, and no other model is affected.

Verification

test/test_backup.py (new, no server or network needed):

  • the field is surfaced when the server sends it, alongside the existing fields
  • it defaults to None both when the key is omitted and when it is explicitly null

Run against the real package with only weaviate/backup/backup.py swapped:

before the change   3 failed   (AttributeError: 'BackupListReturn' object has no attribute 'incremental_base_backup_id')
after the change    3 passed

Also confirmed BackupListReturn(**entry) still parses an entry that has no incremental_base_backup_id key — the pre-existing behaviour is unchanged.

Lint, at the versions pinned in .pre-commit-config.yaml / main.yaml, over both changed files:

ruff 0.14.7 check             All checks passed!
ruff 0.14.7 format --diff     2 files already formatted
flake8 7.3.0 (+bugbear 24.12.12, comprehensions 3.17.0, builtins 3.0.0, docstrings 1.7.0, pydoclint 0.7.3)   clean

test/ is outside the pyright matrix (weaviate, integration, integration_embedded) and is covered by the unit-tests job.

Note

I left docs/changelog.rst alone since it only carries released versions and no Unreleased section — happy to add an entry under whichever version you're cutting if you'd prefer it in this PR.

🤖 Generated with Claude Code

GET /backups/{backend} returns incremental_base_backup_id per item (see
BackupListResponseItems0 and Scheduler.List in weaviate/weaviate), but
BackupListReturn does not declare the field, so list_backups() silently
drops it and callers cannot tell which base backup an incremental backup
was built on without a separate get_create_status() call per backup.

Add the field as Optional[str] defaulting to None: the server omits it for
non-incremental backups and only populates it for callers it has confirmed
as root, so its absence must stay non-fatal.
@weaviate-git-bot

Copy link
Copy Markdown

To avoid any confusion in the future about your contribution to Weaviate, we work with a Contributor License Agreement. If you agree, you can simply add a comment to this PR that you agree with the CLA so that we can merge.

beep boop - the Weaviate bot 👋🤖

PS:
Are you already a member of the Weaviate Forum?

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.

Add incrementalBaseBackupId return value for ListBackups

2 participants