Skip to content

fix(karakeep): report the HTTP status when saving an entry fails - #4520

Merged
fguillot merged 1 commit into
miniflux:mainfrom
justadityaraj:fix/karakeep-error-status
Oct 11, 2026
Merged

fguillot merged 1 commit into
miniflux:mainfrom
justadityaraj:fix/karakeep-error-status

Conversation

@justadityaraj

@justadityaraj justadityaraj commented Aug 28, 2026 •

Copy link
Copy Markdown
Contributor

Related to #4477 — Unable to send entries to Karakeep.

Problem

SaveURL checked Content-Type before the HTTP status. HTML error pages from a proxy, redirect, or incorrect endpoint therefore surfaced only as an unexpected content type, hiding the status that explains the failure.

Fix

Remove the one-off content-type gate and follow the integration package's existing status-first pattern. Non-201 responses now report their status; successful responses still have to decode as the expected JSON payload.

Deliberately not done

This improves the diagnostic but does not change private-network policy or deployment configuration. Installations targeting a private Karakeep address may still need INTEGRATION_ALLOW_PRIVATE_NETWORKS=1.

User impact

Failed saves now expose the upstream HTTP status, making proxy, authentication, and endpoint problems actionable instead of reporting only text/html.

Verification

  • go test ./internal/integration/... — all integration packages passed.

  • go vet ./... — passed.

  • go build ./... — passed.

  • git diff --check and gofmt -d — clean.

  • I have tested my changes

  • There are no breaking changes

  • I have thoroughly tested my changes and verified there are no regressions

  • My commit messages follow the Conventional Commits specification

  • I have read and understood the contribution guidelines

SaveURL rejected the response on its Content-Type before it looked at
the status code, so any error the server returned as HTML (a reverse
proxy 502, an auth redirect, a wrong endpoint) surfaced as
"unexpected content type response: text/html; charset=utf-8" with no
mention of the status. Users had nothing to act on.

The check was also the only one of its kind in internal/integration:
every other client, including attachTags in this same file, decides on
the status code alone and lets json.Unmarshal report a body it cannot
read. Drop it so a failed save names its status.
@fguillot
fguillot merged commit 249b340 into miniflux:main Oct 11, 2026
11 checks passed
dsh2dsh added a commit to dsh2dsh/miniflux that referenced this pull request Oct 11, 2026
dsh2dsh added a commit to dsh2dsh/miniflux that referenced this pull request Oct 11, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Development

Successfully merging this pull request may close these issues.

2 participants