Create method to pass Arc<Checkpoint> to workers

[nickvikeras]

Description

Backwards compatible change that allows workers to get the Arc rather than the &CheckpointData. Enables parallelization within the worker.

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
sui-docs	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	May 13, 2025 9:43pm

2 Skipped Deployments

Name	Status	Preview	Comments	Updated (UTC)
multisig-toolkit	⬜️ Ignored (Inspect)	Visit Preview		May 13, 2025 9:43pm
sui-kiosk	⬜️ Ignored (Inspect)	Visit Preview		May 13, 2025 9:43pm

[bmwill]

this is "ok", it sort of feels not great but works. lets get @phoenix-o to take a quick look at this too

[nickvikeras]

this is "ok", it sort of feels not great but works.

Just for my understanding, why do you say that? Is your concern about the panic (and hence lack of compile-time interface enforcement)? I couldn't think of a better way to solve that.

Or are you more concerned about exposing the Arc rather than &Checkpoint and opening up the possibility for weirder memory management issues?

[bmwill]

this is "ok", it sort of feels not great but works.

Just for my understanding, why do you say that? Is your concern about the panic (and hence lack of compile-time interface enforcement)? I couldn't think of a better way to solve that.

Or are you more concerned about exposing the Arc rather than &Checkpoint and opening up the possibility for weirder memory management issues?

Oh i don't mean anything by it other than the interface is just a bit more awkward. If we did proper semver releases then we'd be able to do a breaking release but given we just have folks depend on this via git deps its better than we try to preserve compatibility for as long as possible as Phoenix called out. This is the best way to handle the situation as of now though, sorry for not being clearer before.

[bmwill]

One maybe minor nit here would be to have this take a &Arc<CheckpointData> so that you don't need to clone the arc unless the implementor needs to do so

[nickvikeras]

this is "ok", it sort of feels not great but works.

Just for my understanding, why do you say that? Is your concern about the panic (and hence lack of compile-time interface enforcement)? I couldn't think of a better way to solve that.
Or are you more concerned about exposing the Arc rather than &Checkpoint and opening up the possibility for weirder memory management issues?

Oh i don't mean anything by it other than the interface is just a bit more awkward. If we did proper semver releases then we'd be able to do a breaking release but given we just have folks depend on this via git deps its better than we try to preserve compatibility for as long as possible as Phoenix called out. This is the best way to handle the situation as of now though, sorry for not being clearer before.

Ah yeah, that would be ideal but I wasn't sure if it was worth the effort if the long term vision is to unify on the new indexer.