canonical / canonical/postgresql-k8s-operator
use _extract_error_message in more error paths
- Dominant language
- Python
- Stars
- 15
- Forks
- 34
- Avg merge
- 1d 3h
- Merged PRs (30d)
- 41
Description
## Problem
PR #1243 introduces `_extract_error_message` for surfacing pgBackRest error details to the user, but only uses it in `_initialise_stanza` and `check_stanza`. Several other error paths still use the generic `{e!s}` (ExecError string representation) or have no error handling at all, giving users unhelpful messages.
The VM charm (`canonical/postgresql-operator`) already uses `_extract_error_message` in all of these locations.
## Affected branches
- **`main`** — after PR #1243 is merged, these gaps will exist on `main`
- **`16/edge`** — does not have `_extract_error_message` at all yet (same gaps plus no error extraction anywhere)
## Affected methods
1. **`_on_create_backup_action`** (backup failure) — uses `f"Failed to backup PostgreSQL with error: {e!s}"` instead of `_extract_error_message(e.stderr)`
2. **`_list_backups`** — no error handling for `ExecError` from `pgbackrest info`; exception propagates raw
3. **`_generate_backup_list_output`** — same as above, no error handling; caller in `_on_list_backups_action` also uses `{e!s}`
4. **`_is_primary_pgbackrest_service_running`** (server-ping failure) — uses `f"...with error {e!s}"` instead of `_extract_error_message(e.stderr)`
## Expected behavior
All pgBackRest error paths should extract meaningful ERROR/WARN lines from stderr and surface them to the user, either in juju status, action results, or log messages.
## References
- PR #1243 (introduces `_extract_error_message` on branch `include-pgbackrest-error-details`)
- VM charm equivalent: `canonical/postgresql-operator` `main` and `16/edge` branches use `_extract_error_message` in all 8+ call sites
Contributor guide
Research direction
Start by reviewing PR #1243 and the affected methods: _on_create_backup_action, _list_backups, _generate_backup_list_output, and _is_primary_pgbackrest_service_running. Compare the VM charm’s main and 16/edge implementations, then verify that each pgBackRest failure extracts ERROR/WARN lines from stderr in status, action results, or logs.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- postgresql, python
- Domain
- databases, devops
- Issue type
- Bug
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 42/100