Skip to content

Conversation

@gregoryn22
Copy link
Contributor

@gregoryn22 gregoryn22 commented Dec 6, 2025

Summary

This PR improves the robustness of patch operations sent to Komga by adding validation for URLs and handling invalid totalBookCount values. These changes prevent Komga from rejecting metadata updates due to invalid data.

Changes

1. URL Validation (safeUrlOrNull function)

  • Added a new safeUrlOrNull helper function that validates URLs before sending them to Komga
  • Validates that URLs have a valid http or https scheme
  • Ensures URLs have a non-empty host component
  • Gracefully handles malformed URLs by logging warnings and returning null instead of crashing
  • Applied to both series and book metadata link updates

Why this is needed: Komga rejects URLs that don't have proper schemes or hosts, which can cause metadata update operations to fail. This validation ensures only valid URLs are sent to Komga.

2. Invalid totalBookCount Handling

  • Added validation to filter out totalBookCount values that are <= 0 before sending to Komga
  • Invalid values are now omitted from the patch request instead of causing the entire operation to fail

Why this is needed: Komga rejects totalBookCount values that are zero or negative, which can cause metadata updates to fail. By filtering out invalid values, we ensure the patch operation succeeds even when providers return invalid data.

Impact

  • Prevents failures: Metadata update operations will no longer fail due to invalid URLs or totalBookCount values
  • Better error handling: Invalid data is logged and gracefully handled instead of causing crashes
  • Improved reliability: The adapter is more resilient to malformed data from metadata providers

Testing

The changes have been tested with:

  • Series metadata updates containing various URL formats
  • Book metadata updates with links
  • Series with invalid totalBookCount values (0, negative numbers)

Files Changed

  • komf-mediaserver/src/commonMain/kotlin/snd/komf/mediaserver/komga/KomgaMediaServerClientAdapter.kt

…rClientAdapter

- Add safe URL handling for links to prevent unsafe URLs
- Enhance URL validation to ensure only valid http/https schemes and non-empty hosts are accepted
@gregoryn22 gregoryn22 closed this Dec 6, 2025
@gregoryn22 gregoryn22 reopened this Dec 6, 2025
@gregoryn22 gregoryn22 changed the title fix: handle Kodansha schema change and Yen Press empty series gracefully fix/Improve Komga patch operation robustness Dec 6, 2025
@Snd-R
Copy link
Owner

Snd-R commented Dec 7, 2025

Can you give an example of an url that fails for you? Most of the issues were caused by url encoding and were fixed by using snd.komf.util.Url.toStingEncoded() function
Also, Komga api accepts schemes other than http/https but I don't think it really matters

If you want to actually validate an url it's better to use io.ktor.http.parseUrl() function and use the Url.toStingEncoded() from the utils file to actually ensure that string is url encoded

@gregoryn22
Copy link
Contributor Author

thanks for the pointers! here's a URL that blew up on the komga side that led to me tracking this down:

https://ebookjapan.yahoo.co.jp/search/?keyword=ブスなんて言わないで&useTitle=1&vctrackinfo=088169131102349414230306173348|vcptn=ZAYj_AADLAZStfLtCoICrQqCADd03w&dealerid=40001&utm_source=asp&utm_medium=vc&utm_campaign=amount

Komga responds with
"message": "Illegal character in query at index 111: https://ebookjapan.yahoo.co.jp/search/?keyword=ブスなんて言わないで&useTitle=1&vctrackinfo=088169131102349414230306173348|vcptn=ZAYj_AADLAZStfLtCoICrQqCADd03w&dealerid=40001&utm_source=asp&utm_medium=vc&utm_campaign=amount"

So in that case the unencoded | in the query string is what triggers the error.

i've also hit cases where komga rejects the url with a 400

"violations":[{"fieldName":"links[9].url","message":"must be a valid URL"}]

In those situations the provider is sending things like “link placeholders” or odd strings that look like URLs but don’t meet Komga’s validation rules. My goal with this PR is just to make sure a single bad link from a provider doesn’t cause the entire metadata PATCH to fail

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.

2 participants