capture-core

Custom fork of monolith v2.10.1 to support external cancellation. This fork exists to support Kotlin coroutine cancellation across the JNI/Rust boundary for Linkora's web-capture feature.

capture-core uses forced panics (EXTERNAL_CANCELLATION_PANIC) to instantly halt execution when an external atomic flag is true.

Cancellation Behavior: capture-core exposes the Options struct containing the cancellation token, but strictly only reads the atomic boolean. It never mutates your external state.

Blocking operations inside monolith (recursive walks, loops, etc.) check cancellation periodically during execution since we control that code. External library calls (reqwest, regex, html5ever, etc.) only get checked before the call.

Usage

Add dependency in Cargo.toml:

[dependencies]
monolith = { package = "capture_core", git = "https://github.com/LinkoraApp/capture-core", branch = "base" }

Your function calls happen as usual, same as the original lib. Refer to the original documentation since actual logic isn't changed for HTTP/HTTPS stuff. This fork explicitly supports cancellation, other than that it's the same.

---

Use this fork only if:

1. Your software strictly processes http or https web links. Other protocols like raw file paths or FTP might not work or might be removed later to keep this purely for http/https.
2. You wrap your entry point in std::panic::catch_unwind and downcast to catch the exact cancellation string ( EXTERNAL_CANCELLATION_PANIC).
3. Your build target is explicitly compiled with panic=unwind.
4. There is absolutely no risk of a panic inside a panic (abort) in your project.
5. You run the capture tasks via tokio::task::spawn_blocking (or a dedicated OS thread).
   • monolith uses reqwest which spawns its own tokio runtime for network calls. When you place blocking calls like these inside your own tokio runtime, it creates nested runtimes, and things won't be good with nested runtimes.

This fork remains licensed under the original CC0-1.0 license.