Skip to content

Conversation

@anakinzhed
Copy link
Contributor

No description provided.

@cloudflare-workers-and-pages
Copy link

cloudflare-workers-and-pages bot commented Jul 14, 2025

Deploying kolme with  Cloudflare Pages  Cloudflare Pages

Latest commit: 37a5a74
Status: ✅  Deploy successful!
Preview URL: https://55360410.kolme.pages.dev
Branch Preview URL: https://kol-5.kolme.pages.dev

View logs

Copy link
Member

@snoyberg snoyberg left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Left some comments for a change in general direction. When this is ready for another review, let's get @MichaelNelo on this too so I'm not a bottleneck.

@anakinzhed anakinzhed marked this pull request as ready for review July 16, 2025 21:00
@anakinzhed anakinzhed force-pushed the KOL-5 branch 2 times, most recently from 2efdafe to a75f49d Compare October 20, 2025 23:18
@anakinzhed anakinzhed requested a review from snoyberg October 20, 2025 23:26
@anakinzhed anakinzhed marked this pull request as draft November 17, 2025 23:01
@anakinzhed anakinzhed requested review from snoyberg and removed request for snoyberg November 24, 2025 23:13
@anakinzhed
Copy link
Contributor Author

@borsboom, Michael asked me to work with you in this PR.

@anakinzhed anakinzhed requested a review from borsboom November 25, 2025 18:50
@borsboom
Copy link
Member

@anakinzhed I'm still familiarizing myself with the Kolme codebase, and this is a big PR. I'm working to understand the changes and figure out if there's a way we can avoid the stringy errors that are hard to avoid because of the traits that KolmeError derives. It might take me a little while to respond further, but I am working on it.

Copy link
Member

@borsboom borsboom left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not easy to retrofit proper errors into a codebase like this, especially given the need for some errors to be serializable.

Aside from the comments I added to specific changes, I noticed there are still many uses of anyhow::Result which end up being "hidden" by error types implementing From<anyhow::Error> and stringifying them. Removing those, and any imports of anyhow::Result should help find them (as well as just searching the codebase anyhow).

@anakinzhed
Copy link
Contributor Author

@borsboom Sorry for the delay. I believe I’ve addressed all of your comments. Please take a look.

@anakinzhed anakinzhed requested a review from borsboom December 30, 2025 17:48
@borsboom
Copy link
Member

borsboom commented Jan 7, 2026

Great progress!

I notice there are still some places that are returning anyhow::Result (e.g. in packages/kolme/src/core/execute.rs). Where concrete error types are returned, they are being converted to anyhow::Error (e.g. return Err(KolmeExecuteError::…).into();).

Better would be for the functions to return a concrete error (e.g. fn …(…) -> Result<(), KolmeExecuteError>). Any upstream errors should be embedded in KolmeExecuteError, which is made easier using thiserror's #[from] annotation so that the ? operator still works. E.g.

pub enum KolmeExecuteError {#[error("Public key error: {0}")]
    PublicKeyError(#[from] shared::cryptography::PublicKeyError),
}

If at all possible, anyhow should be removed from the dependencies entirely.

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.

4 participants