arctic trench Feb 9, 2026, 9:54 AM

#

Ok

fervent lark Feb 9, 2026, 10:07 AM

#

arctic trench Ok

also for the graph i do know why you don't like it

#

on darkmode the yellow like turd than like purely yellow xd

arctic trench Feb 9, 2026, 10:07 AM

#

I forgot to explain why

#

But basically, when I first saw that, I couldn't understand what it was showing; it was difficult to get it at first sight.

fervent lark Feb 9, 2026, 10:09 AM

#

ah

arctic trench Feb 9, 2026, 10:11 AM

#

I'm having some classes about data science and one of the topics is exacly about the graph choices when you want show a data

Graphs is manly desing to express a lot of information with minimum or none explanation

fervent lark Feb 9, 2026, 10:12 AM

#

yup

arctic trench Feb 9, 2026, 10:12 AM

#

Graph titles is a great help like
Productivity X Time

#

Subtitles

#

Etc

#

Labels, legends

fervent lark Feb 9, 2026, 10:14 AM

#

mhm

fervent lark Feb 9, 2026, 10:23 AM

#

arctic trench Graph titles is a great help like Productivity X Time

i think its a bit better right?

Screenshot_2026-02-09_at_12.21.18_PM.png

arctic trench Feb 9, 2026, 11:17 AM

#

Much better

#

@fervent lark which rust version we are using

#

While I was verifying the code, some errors appeared.

fervent lark Feb 9, 2026, 12:17 PM

#

arctic trench <@822874616947146793> which rust version we are using

latest im pretty sure

#

ah

#

oopsie

#

ye i forgot to merge upload chages

arctic trench Feb 9, 2026, 12:27 PM

#

fervent lark ye i forgot to merge upload chages

ferrisHmm

fervent lark Feb 9, 2026, 12:27 PM

#

they are u[

#

up*

#

you can update the project

#

ig though i would advise you seeing more the docs rn, leave the rust side for a bit

arctic trench Feb 9, 2026, 12:29 PM

#

ok, i was just see the new changes by curiosity

#

right now i'm working

fervent lark Feb 9, 2026, 12:30 PM

#

ah ok

#

then no problem

fervent lark Feb 9, 2026, 1:41 PM

#

here is something interesting

#

#

idk if its me

#

but isn't the bar for the "apache airlfow" a different color than "celery"

#

yet for some reason

#

the apache airflow bar is brighter than the celery one

#

the other colors trick my eyes into seeing the apache airflow brighter than it actually is

#

if i extract them and put them somewhere else, the illusion breaks

#

wait

#

finished

#

though it annoys me it ain't centered

#

nvm found the issue

#

#

my dumbass notices issues and proceeds to delete and reupload

#

and looks slightly better in dark mode

#

#

at least its more wood than just shit

#

btw uh you used AI in the report?

#

just out of curiousity

arctic trench Feb 9, 2026, 2:52 PM

#

Just in one part

#

On the part that talks about the alt tag missing in the graph image

#

And of course, I used AI to verify if my reasoning was justified.

arctic trench Feb 9, 2026, 2:57 PM

#

arctic trench And of course, I used AI to verify if my reasoning was justified.

Now that I remember, the part where I mention the phrase between parentheses, I questioned with my perspective, and the IA rewrote it to a more robust phrase.

#

In my opinion, that's the correct use of AI.
In the end, IA is just a very intelligent text autocomplete.

fervent lark Feb 9, 2026, 3:08 PM

#

arctic trench On the part that talks about the alt tag missing in the graph image

ye slightly noticed it

fervent lark Feb 9, 2026, 3:08 PM

#

arctic trench Now that I remember, the part where I mention the phrase between parentheses, I ...

true

#

just know i don't want AI do the piloting

fervent lark Feb 9, 2026, 3:09 PM

#

arctic trench And of course, I used AI to verify if my reasoning was justified.

ideally you shouldn't let it critique

#

since it inserts some bias

#

which you may follow

arctic trench Feb 9, 2026, 3:17 PM

#

Did you have problems in the past because some contributors used AI wrong?

jolly frost Feb 9, 2026, 3:57 PM

#

arctic trench Did you have problems in the past because some contributors used AI wrong?

Based on the experience of other companies

fervent lark Feb 9, 2026, 4:13 PM

#

arctic trench Did you have problems in the past because some contributors used AI wrong?

honestly haven't worked in the industry, a bit of a shocker ik

#

but im just observing things from afar

#

and rationalize both on what stuff works and doesn't, while also seeing the results

arctic trench Feb 9, 2026, 5:46 PM

#

fervent lark

Just for a test, add a very light text shadow to the colored text, maybe it can improve the text visibility.

fervent lark Feb 9, 2026, 7:53 PM

#

arctic trench Just for a test, add a very light text shadow to the colored text, maybe it can ...

sadly i don't have this kind of control

fervent lark Feb 10, 2026, 12:08 PM

#

im gonna restructure massively how errors are handled

#

since rn its a mess

#

anyhow doesn't work

#

this includes reworking some chapters (mostly in the workflows section)

#

rn its painful to do error handling

#

which is something i hate

#

il have to define my own error trait as it seems

#

it would be clever to sort of merge anyhow with thiserror into my own solution

#

they will be supported

#

its just that im trying to think for every case

#

compatibility, ease of use, ergonomical error handling

#

the idea is a sort of json schema

fervent lark Feb 10, 2026, 4:54 PM

#

i got the structure of the error

#

pub enum ChronoGrapherErrorType {
    Unknown,
    Custom(String),
    TaskFrameFailure,
    TaskScheduleFailure,
    SchedulerStrategyFailure,
}

pub enum ChronoGrapherErrorSource {
    Unknown,
    ErrorSTD(Arc<dyn std::error::Error + Send + Sync + 'static>),
    ChronoGrapherCore(Box<ChronoGrapherError>)
}

pub struct ChronoGrapherError {
    message: String,
    metadata: BTreeMap<String, Arc<dyn Any + Send + Sync>>,
    backtrace: std::backtrace::Backtrace,
    kind: ChronoGrapherErrorType,
    source: ChronoGrapherErrorSource
}

impl ChronoGrapherError {
    pub fn message(&self) -> &str {
        self.message.as_str()
    }

    pub fn backtrace(&self) -> &std::backtrace::Backtrace {
        &self.backtrace
    }

    pub fn kind(&self) -> &ChronoGrapherErrorType {
        &self.kind
    }

    pub fn get_dyn(&self, key: &str) -> Option<Arc<dyn Any + Send + Sync>> {
        Some(
            self.metadata.get(key)?
                .clone()
        )
    }

    pub fn get<T: Send + Sync + 'static>(&self, key: &str) -> Option<Arc<T>> {
        Some(
            self.get_dyn(key)?
                .downcast::<T>()
                .ok()?
        )
    }
}

impl<T: std::error::Error + Send + Sync + 'static> From<T> for ChronoGrapherError {
    fn from(value: T) -> Self {
        Self {
            message: value.to_string(),
            metadata: BTreeMap::new(),
            backtrace: std::backtrace::Backtrace::capture(),
            kind: ChronoGrapherErrorType::Unknown,
            source: ChronoGrapherErrorSource::ErrorSTD(Arc::new(value))
        }
    }
}

#

something like so

fervent lark Feb 10, 2026, 8:11 PM

#

hmmm...

#

This is gonna be a hard problem

#

its still difficult

#

@arctic trench you have any idea on how to solve this?

#

if i had a Result<AnyOK, ChronoGrapherError>

#

where AnyOK is just my value for ok

#

i would have to do neted match and if statements

#

error handling is something we have to particularily get right

#

ye macros exist, but this doesn't seem like a macros problems

#

so far this error structure helps with gathering info about the error

arctic trench Feb 10, 2026, 9:06 PM

#

fervent lark <@554493803927568384> you have any idea on how to solve this?

hummm

#

@fervent lark Man, I suggest we make something simple at the start.

And try to build, for example, a simple web server using Chronographer and Rocket/Axios, of course not right now.

This way, we can gather some “real” scenarios using tasks and a scheduler.
I recommend it because premature abstraction is a common mistake in software engineering; we didn't gather some real examples of usage.

arctic trench Feb 10, 2026, 11:07 PM

#

fervent lark ```rust pub enum ChronoGrapherErrorType { Unknown, Custom(String), T...

One more thing, You don't think use trait instead of enum for errors is better?

#

To respect the O of SOLID principle

fervent lark Feb 11, 2026, 9:29 AM

#

arctic trench One more thing, You don't think use trait instead of enum for errors is better?

well, i could use the error trait

#

though we have some problems per say

#

the error handling is something we can't just leave out

fervent lark Feb 11, 2026, 9:30 AM

#

arctic trench <@822874616947146793> Man, I suggest we make something simple at the start. And...

its tied to real world scenarios, yes ik about premature abstraction, but this is something we can't ignore, i've seen the pain even when writing the guidebook that its not good currently

#

i do want to try and make real-world stuff with ChronoGrapher, though error handling, the shared data API, the macros have to be finished and stabilized

#

then we can get to

#

also urgent, @jolly frost and @arctic trench since the API docs are up, should we rewrite the docs?

#

is it a good time to?

#

well not rn, in parallel we will handle the error handling problem

arctic trench Feb 11, 2026, 9:47 AM

#

fervent lark also urgent, <@1119720414021685402> and <@554493803927568384> since the API docs...

Let's firts finalizy one feature per time before rewrite the docs

fervent lark Feb 11, 2026, 9:49 AM

#

true

fervent lark Feb 11, 2026, 9:49 AM

#

arctic trench Let's firts finalizy one feature per time before rewrite the docs

let's focus then on error hadling

fervent lark Feb 11, 2026, 9:55 AM

#

arctic trench Let's firts finalizy one feature per time before rewrite the docs

dumb approach, while being assisted in some of the architectural thinking aspect, deepseek reccomended an approach where errors have multiple contexts, this would have to do more closely with TaskFrames more than any other system, when a TaskFrame fails, the error bubbles up right? One idea is for every parent TaskFrame to provide their own context of what happened, forming a context tree

This context tree can be inspected, when displayed it will display the entire tree, which helps a bit on debugging side, but on the error handling side you could downcast errors or ig match contexts to deduce what happened? (Im thinking about it still)

How would this approach solve the issue?

#

its really a puzzling problem

arctic trench Feb 11, 2026, 10:16 AM

#

What is the need of the task tree?

fervent lark Feb 11, 2026, 10:16 AM

#

arctic trench What is the need of the task tree?

context tree*

#

well

#

it contains information

#

on how the error happened

#

how it bubbled up

#

like say FallbackTaskFrame would bubble the error up to RetriableTaskFrame with its own context that both the primary & fallback failed

#

then the RetriableTaskFrame would continously try (suppose now its the final retry), the error still persists so it throws on top its own context that says "the error still persists even with N retries..."

#

and so on

#

i don't think im thinking about the problem clearly tbh

jolly frost Feb 11, 2026, 10:21 AM

#

fervent lark dumb approach, while being assisted in some of the architectural thinking aspect...

Yeah, good idea, smth similar to my idea with error history

fervent lark Feb 11, 2026, 10:22 AM

#

jolly frost Yeah, good idea, smth similar to my idea with error history

ye

jolly frost Feb 11, 2026, 10:23 AM

#

But won't this affect a bit performance?

fervent lark Feb 11, 2026, 10:23 AM

#

ye true

#

a lot of memory

#

for errors

jolly frost Feb 11, 2026, 10:24 AM

#

fervent lark also urgent, <@1119720414021685402> and <@554493803927568384> since the API docs...

yeah

fervent lark Feb 11, 2026, 10:24 AM

#

tbh ditch the idea

jolly frost Feb 11, 2026, 10:25 AM

#

hm

jolly frost Feb 11, 2026, 10:28 AM

#

fervent lark tbh ditch the idea

it's actually good

#

but rn it's kinda big

#

so we need to remove some stuff

fervent lark Feb 11, 2026, 10:28 AM

#

mhm

jolly frost Feb 11, 2026, 10:28 AM

#

to make it more lightweight

#

well

#

we need to allocate data only if smth returns an error

fervent lark Feb 11, 2026, 10:58 AM

#

ok so

#

#rust-help-2 message

#

now i know what to do

#

il rework TaskFrames

fervent lark Feb 11, 2026, 7:22 PM

#

Good news

#

Il be completely free around 2 weeks

#

this means we have to stay focused especially those 2 weeks

#

which means @arctic trench @jolly frost, il be able to carry more some of the weights you had

fervent lark Feb 11, 2026, 8:10 PM

#

hm might join https://itch.io/jam/brackeys-15, its been a while since i've entered a game jam

arctic trench Feb 11, 2026, 9:11 PM

#

ok, talking about it, next week during some days i will be free too, just until Tuesday, but i will be free

fervent lark Feb 11, 2026, 9:11 PM

#

ok

fervent lark Feb 12, 2026, 7:20 AM

#

hmm we're gonna have some issues

#

the TaskHook events

#

these are fixable though, by just appending a generic for the error shape

#

i think...

#

though not sure how it would feel ergonomically speaking

#

ig they can execute different side-effects per error

#

impl<E: Error + Send + Sync + 'static> TaskHook<OnFallbackEvent<E>> for MyTaskHook {
    async fn on_event(
        &self,
        ctx: &TaskHookContext,
        payload: &<OnFallbackEvent<E> as TaskHookEvent>::Payload,
    ) {
        // ...
    }
}

#

this is for the case they want to trigger the same code for any error

fervent lark Feb 12, 2026, 8:23 AM

#

ngl since those past days were stressful

#

am i take a small break

arctic trench Feb 12, 2026, 9:37 AM

#

fervent lark am i take a small break

Ok ferrisGlasses

fervent lark Feb 12, 2026, 9:43 AM

#

actually meh

fervent lark Feb 12, 2026, 9:44 AM

#

arctic trench Ok<:ferrisGlasses:451162415850323999>

btw for the critics you managed (not trying to force you, just want to get an idea of progression)

fervent lark Feb 12, 2026, 10:58 AM

#

Hmmm, for error handling i do fear things will get complicated

#

the idea is each TaskFrame appends its own newtype struct, its just a marker wrapping the error (for the most part)

#

Retriable, Fallback, Threshold and Delay do this wrapping

#

these newtypes will allow you to get information about the error and how the workflow behaved

#

now for the error matching side, suppose we have the error type DelayTaskFrameError<FallbackTaskFrameError<RetriableTaskFrameError<T>>> as a result where T is an enum let's just say

#

users could just do

#

match res {
   Ok(()) => {...}
   Err(err) => {
       match err.0.0.0 {
          T::Variant1 => {...}
          T::Variant2 => {...}
          T::Variant3 => {...}

          // <...>
       }
   }
}

#

that .0.0.0 bothers me a lot actually

#

one idea to minimize could be to define a sort of proceedual macro prune! which does this unwrapping for us

#

or actually wait

#

but then

#

you have the implementation side

#

#[async_trait]
impl TaskFrame for MyTaskFrame {
    type Error: Error + Send + Sync;

    async fn execute(&self, ctx: &TaskContext<Self::Error>) -> Result<(), Self::Error> {
         // ...
    }
}

#

this is the simplest

#

its good

#

but

#

what if i want to define hook events which have as payload the error

#

i would have to make them generic

#

and idk honestly

fervent lark Feb 12, 2026, 11:17 AM

#

fervent lark ```rust match res { Ok(()) => {...} Err(err) => { match err.0.0.0 {...

also for this, nvm

#

i can implement Deref

#

match res {
   Ok(()) => {...}
   Err(err) => {
       match &***err {
          T::Variant1 => {...}
          T::Variant2 => {...}
          T::Variant3 => {...}

          // <...>
       }
   }
}

#

much cleaner

arctic trench Feb 12, 2026, 11:25 AM

#

fervent lark also for this, nvm

😂 , ok, just to inform you, unfortunately, I still don't understand all this, but as I say, I'm studying Rust, and even if it's just some minutes a day, I will take those topics that you mentioned to study too.

#

But one thing: if the error handle implementations go this way, for every task error variant, will I need to create an "impl" to handle each type of error?

fervent lark Feb 12, 2026, 11:28 AM

#

arctic trench But one thing: if the error handle implementations go this way, for every task e...

i mean if you want to specifically handle and extract specific information out of the error, then ye you need to match per variant

#

you can leave some if needed by just err => {...} or _ => {...} if you wanna fully ignore the error

arctic trench Feb 12, 2026, 11:29 AM

#

humm, ok ok

fervent lark Feb 12, 2026, 11:37 AM

#

also i propose a new change, il create an issue

#

https://github.com/GitBrincie212/ChronoGrapher/issues/129

GitHub

[ARCH] Rewriting ParallelTaskFrame, SequentialTaskFrame and SelectT...

What area has an architectural problem? Please describe. Three areas, specifically ParallelTaskFrame, SequentialTaskFrame and SelectTaskFrame with additionally the GroupExecBehaviour stuff. Why doe...

zenith urchin Feb 12, 2026, 3:26 PM

#

Hey everyone, does anybody know if the current master working properly or am I missing something?
I have tried to add chronographer = '0.0.1a' to new project. It threw an error about index not being present, so project is not defined under the cargo. Then I used chronographer = { git = "https://github.com/GitBrincie212/ChronoGrapher.git", branch = "master" } to add the project to the Cargo.toml. However, now, I cannot use Chronographer even though I followed the guidelines. I am talking about the Hello ChronoGrapherexample. Also, in the first Workflow example, we generate a random number, it would be nice to add cargo add rand as well I know it is a small thing and they can look at the errors and figure it out, but just for completeness.
So overall, is master branch a complete branch because I cannot run basics. I haven't gone deep into the codebase yet.

fervent lark Feb 12, 2026, 3:41 PM

#

zenith urchin Hey everyone, does anybody know if the current master working properly or am I m...

oh its still heavily WIP

#

it hasn't even been published

#

and

#

also

#

the macro syntax so far is conceptual

#

possible to implement but not ready

#

there is a lot to work in and let's just say it will be finished around April as it seems

#

maybe even later

zenith urchin Feb 12, 2026, 3:54 PM

#

Oh okay I was reading the guidelines and implementing in the meantime, but then I will just go through it and try to implement some Beginner ticket 👍 . To coordinate better, I will inform you which ticket I am planning to take or I can take some ticket that is urgent as well.

fervent lark Feb 12, 2026, 3:56 PM

#

zenith urchin Oh okay I was reading the guidelines and implementing in the meantime, but then ...

ye do mention me

#

like ping

#

so i can respond fast

zenith urchin Feb 12, 2026, 3:56 PM

#

oki

fervent lark Feb 12, 2026, 3:56 PM

#

zenith urchin Oh okay I was reading the guidelines and implementing in the meantime, but then ...

for guidelines, how far you've read?

#

and in website form right?

#

not just reading the markdown

zenith urchin Feb 12, 2026, 3:57 PM

#

not far I have read until Problem space on workflow. Yup, run the pnpm run dev

fervent lark Feb 12, 2026, 3:57 PM

#

good

fervent lark Feb 12, 2026, 3:58 PM

#

zenith urchin not far I have read until Problem space on workflow. Yup, run the pnpm run dev

but still could be valuable feedback, how you perceived the guidebook so far?

#

what you liked vs hated about it

zenith urchin Feb 12, 2026, 4:01 PM

#

Until now, I really liked the focusing on codesnippets with blur. It would have been nice to have clickable references for codebase. For example, you meantioned TaskFrames I know how to look into the TaskFrames and where it is, but would have been easier to just click it and navigate. I think overall it is a really nice website 👍

fervent lark Feb 12, 2026, 4:03 PM

#

i see

#

ok good thing @arctic trench perspective seems to hold

#

for the clickable references for codebases wdym exactly?

fervent lark Feb 12, 2026, 4:05 PM

#

zenith urchin Until now, I really liked the focusing on codesnippets with blur. It would have ...

btw you don't mention like the structure, how the concepts are presented, i get its minimal overview, but still would like to know for feedback

#

so i can improve upon

zenith urchin Feb 12, 2026, 4:06 PM

#

fervent lark for the clickable references for codebases wdym exactly?

For example, navigating to this link: https://github.com/GitBrincie212/ChronoGrapher/blob/87e0e9422fd226d9e7e9c473a38c5d8173d7dd7f/core/src/task/frames.rs#L294

You can define lines for github pages, so it can be useful to do references for some people that want to have deeper understanding

fervent lark Feb 12, 2026, 4:06 PM

#

i see

zenith urchin Feb 12, 2026, 4:07 PM

#

fervent lark btw you don't mention like the structure, how the concepts are presented, i get ...

I can give you better feedback about this when I am done reading Guidelines. I also want to see consistency on the Guidelines etc. So will get back to you

fervent lark Feb 12, 2026, 4:07 PM

#

ah sure sure

fervent lark Feb 12, 2026, 4:08 PM

#

zenith urchin I can give you better feedback about this when I am done reading Guidelines. I a...

guidelines are more long on purpose, this part isn't meant to be narrative, like learning more so rules

#

whereas the chapters on the guidebook are ~1k words in length

zenith urchin Feb 12, 2026, 4:09 PM

#

okay keep this in mind while reading as well as giving feedback. Thanks

fervent lark Feb 12, 2026, 5:02 PM

#

imma delete the API docs, its just too distracting

#

plus would be rewritten anyways

fervent lark Feb 12, 2026, 8:23 PM

#

i feel like this is wrong yet the compiler doesn't complain at all

#

&TaskFrameContext<dyn ErasableTaskFrame>

#

when

#

pub struct TaskFrameContext<T: TaskFrame> {...}

#[async_trait]
pub trait TaskFrame: 'static + Send + Sync + Sized {
    type Error: Error + Send + Sync;

    async fn execute(&self, ctx: &TaskFrameContext<Self>) -> Result<(), Self::Error>;
}

trait ErasableTaskFrame: 'static + Send + Sync {
    async fn erased_execute(&self, ctx: &TaskFrameContext<dyn ErasableTaskFrame>) -> Result<(), Box<dyn Error + Send + Sync>>;
}

impl<T: TaskFrame<Error: Into<T::Error>>> ErasableTaskFrame for T {
    async fn erased_execute(&self, ctx: &TaskFrameContext<dyn ErasableTaskFrame>) -> Result<(), Box<dyn Error + Send + Sync>> {
        self.execute(ctx).await.map_err(Into::into)
    }
}

#

idk why, i just can't prove it

#

https://klipy.com/gifs/dexter-doakes-6

Klipy

Doakes' Suspicious Stares in Dexter

▶ Play video

fervent lark Feb 12, 2026, 8:42 PM

#

oh god

#

boi, was i right

#

im dying inside

#

slowly and surely i cut it to 70 errors

#

now 39

#

man im in pain

#

man i just wish i avoided Arc and used references

fervent lark Feb 13, 2026, 10:02 AM

#

10 more errors to go

fervent lark Feb 13, 2026, 10:19 AM

#

and now 6

fervent lark Feb 13, 2026, 11:37 AM

#

man this is kinda complex

#

I feel like making errors typed was the wrong approach

#

Sure they seem to improve error handling

#

but Task is being erased when fed to the Scheduler

#

for the workflow parts it kinda works

fervent lark Feb 13, 2026, 1:05 PM

#

a lot of changes will happen

#

in the scheduler side

#

in the Tasks

#

for error handling

#

ferrisForgor

#

and i should be careful about it, as to not leak any Scheduler stuff on to the Task side

fervent lark Feb 13, 2026, 2:11 PM

#

@jolly frost

#

imma need you on this one

#

same with @arctic trench

#

both your attentions here

jolly frost Feb 13, 2026, 2:12 PM

#

ferrisHmm

arctic trench Feb 13, 2026, 2:12 PM

#

ferrisHmm

fervent lark Feb 13, 2026, 2:12 PM

#

ferrisHmm

#

:>

#

i've made a significant change

#

pub trait SchedulerConfig: Sized + 'static {
    type TaskIdentifier: TaskIdentifier;
    type Error: Error + Send + Sync + 'static; // NEW
    type SchedulerClock: SchedulerClock<Self>;
    type SchedulerTaskStore: SchedulerTaskStore<Self>;
    type SchedulerTaskDispatcher: SchedulerTaskDispatcher<Self>;
    type SchedulerEngine: SchedulerEngine<Self>;
}

#

schedulers now can enforce a specific error they have in mind

#

to handle

#

this error is for Tasks

#

the problem is

#

it leads to cascading effects

#

what i mean is

#

i want the EngineNotifier to be aware of the Error type

#

pub struct EngineNotifier<C: SchedulerConfig> {
    id: C::TaskIdentifier,
    notify: tokio::sync::mpsc::Sender<(C::TaskIdentifier, Option<C::Error>)>,
}

#

so it can send it reliabily

#

previously i erased them under an Any

#

now bc it has to know

#

this leaks through SchedulerStrategy

#

forcing it to know the SchedulerConfig and thus forcing the Task to know the config

#

like so

#

#[async_trait]
pub trait ScheduleStrategy<C: SchedulerConfig>: 'static + Send + Sync {
    async fn handle(&self, task: Arc<ErasedTask>, notifier: EngineNotifier<C>);
}

#

we could keep the erasing if we want and check but i feel like its dirty

#

how would you approach this, make the ScheduleStrategy without generic the config

#

while still being able to send the errors

#

we may have to rethink this

#

the Task architecture specifically

jolly frost Feb 13, 2026, 2:23 PM

#

hm

jolly frost Feb 13, 2026, 2:25 PM

#

fervent lark we could keep the erasing if we want and check but i feel like its dirty

why do you think its dirty

fervent lark Feb 13, 2026, 2:25 PM

#

jolly frost why do you think its dirty

well, it moves the concern to runtime

#

the ScheduleStrategy can return any error

fervent lark Feb 13, 2026, 2:34 PM

#

jolly frost why do you think its dirty

what do you propose

fervent lark Feb 13, 2026, 2:34 PM

#

fervent lark well, it moves the concern to runtime

the problem is also tied to performance a bit, as downcasting will be extremely frequent

#

its a hot path the SchedulerStrategy

#

one idea

#

could be to shift the SchedulerStrategy to the scheduler side

#

as opposed to living inside the Task

#

and maybe even remove it entirely, in favor of the SchedulerTaskDispatcher doing this

arctic trench Feb 13, 2026, 2:41 PM

#

Maybe better

fervent lark Feb 13, 2026, 2:41 PM

#

arctic trench Maybe better

maybe better what?

arctic trench Feb 13, 2026, 2:42 PM

#

Your ideia, maybe beter
I was thinking in define a trait for engine and config

#

But, well, your idea is better

fervent lark Feb 13, 2026, 2:42 PM

#

ok then

#

btw

#

@arctic trench

#

how is the critique goin?

arctic trench Feb 13, 2026, 3:12 PM

#

I will continue tomorrow, this week i was working on a vital fix where i currently work

This next 4 days i will create the critics for all docs

fervent lark Feb 13, 2026, 3:14 PM

#

ah i see

#

ok then

fervent lark Feb 13, 2026, 3:33 PM

#

btw fun fact

#

the codebase was 8-9k LOCs right

#

with the docs removed

#

its 4.3k LOCs

#

kinda crazy to see how much docs there were

#

and how small it is

fervent lark Feb 13, 2026, 3:51 PM

#

its actually smaller

#

3.4k LOCs

#

insanely small if you ask me

fervent lark Feb 13, 2026, 4:43 PM

#

btw im removing the default CHRONOGRAPHER_SCHEDULER

#

the chronographer::main macro will handle this

#

#[chronographer::main]
async fn main(scheduler: DefaultAnyhowScheduler) {
    // CODE
}

#

the DefaultAnyhowScheduler is just a type alias really

#

this code expands to:

#[tokio::main]
async fn main() {
  scheduler: DefaultAnyhowScheduler = DefaultAnyhowScheduler::default();
  // CODE
  scheduler.start().await;
  loop {} // or better yet the ctrl c signal
}

#

also new simpler diagram

fervent lark Feb 13, 2026, 7:08 PM

#

there's a lot of stuff todo

fervent lark Feb 14, 2026, 9:27 AM

#

im working on enhancing TaskHooks, the idea is their payload can now have a lifetime

#

when needed

#

this is to prevent DynArcError everywhere as an error

#

and instead use Box

fervent lark Feb 14, 2026, 10:51 AM

#

slowly but surely

#

i got it to 2 errors

fervent lark Feb 14, 2026, 11:12 AM

#

fun fact, ChronoGrapher's core is 34KB

#

kinda nuts

jolly frost Feb 14, 2026, 11:15 AM

#

ferrisHmm

fervent lark Feb 14, 2026, 12:32 PM

#

jolly frost <:ferrisHmm:857440844171575326>

lol

#

though how

#

imma commit all changes btw

arctic trench Feb 14, 2026, 12:35 PM

#

@fervent lark I'm reading the documentation in the “Installation & Theory” section.
The setting up of the project and the “Hello World” subsection are perfect, but starting at the “What Are Tasks?” subsection, we have some dangerous conceptual projects when we talk about the software development (in web development more specifically).
Although I will arrange the ideas and critiques, I believe that certain structures should be significantly altered if the information presented below is what I'm imagining.

fervent lark Feb 14, 2026, 12:36 PM

#

arctic trench <@822874616947146793> I'm reading the documentation in the “Installation & Theor...

mhm

#

i see

#

you probably mean the CHRONOGRAPHER_SCHEDULER warning

arctic trench Feb 14, 2026, 12:36 PM

#

no

#

is about that idea:
"Tasks contain the Business Logic and Scheduling Logic, the former ..."

#

🤣

fervent lark Feb 14, 2026, 12:38 PM

#

xd

arctic trench Feb 14, 2026, 12:38 PM

#

no need to worry

fervent lark Feb 14, 2026, 12:38 PM

#

ye ik lol

arctic trench Feb 14, 2026, 12:38 PM

#

fell free to tell

fervent lark Feb 14, 2026, 12:39 PM

#

arctic trench is about that idea: "**Tasks contain the Business Logic** and Scheduling Logic, ...

ok once you finish the critique, do elabrorate heavily on this

#

i am interested to know

fervent lark Feb 14, 2026, 12:59 PM

#

PUSHED

#

-# 37 commits jessus f_ckin christ

jolly frost Feb 14, 2026, 1:00 PM

#

ig we need to make windows a bit larger

fervent lark Feb 14, 2026, 1:00 PM

#

jolly frost ig we need to make windows a bit larger

i don't think the size is the problem

jolly frost Feb 14, 2026, 1:00 PM

#

fervent lark i don't think the size is the problem

it is actually

fervent lark Feb 14, 2026, 1:01 PM

#

hm how so?

#

click area?

arctic trench Feb 14, 2026, 1:02 PM

#

jolly frost ig we need to make windows a bit larger

I agree, and one thing: look at my screen; the texts of the Bento Grid are too small. For me, who doesn't have visual problems, I can read it nicely, but what about the users? And even the ones who don't have it, will they have the patience to read it?

jolly frost Feb 14, 2026, 1:03 PM

#

fervent lark hm how so?

#

like this

fervent lark Feb 14, 2026, 1:03 PM

#

jolly frost

a bit smaller, could work out though

fervent lark Feb 14, 2026, 1:03 PM

#

arctic trench I agree, and one thing: look at my screen; the texts of the Bento Grid are too s...

ye ig upping the size of the bento grid text won't hurt

jolly frost Feb 14, 2026, 1:03 PM

#

fervent lark a bit smaller, could work out though

it's already small

#

we have so much space

fervent lark Feb 14, 2026, 1:04 PM

#

jolly frost it's already small

honestly i might add other frameworks for like js/ts

#

thats why im concerned

#

and rust

#

don't forget abt rust

#

though i do have an idea

#

since we're adding minimization

#

what if we just have some frameworks already minimized

#

and show the most prominent frameworks

jolly frost Feb 14, 2026, 1:05 PM

#

yeah

#

good idea

fervent lark Feb 14, 2026, 1:05 PM

#

could work out

#

also jessus

#

we reached 1k commits

jolly frost Feb 14, 2026, 1:06 PM

#

and this should be animated

jolly frost Feb 14, 2026, 1:06 PM

#

fervent lark we reached 1k commits

nicee

fervent lark Feb 14, 2026, 1:06 PM

#

jolly frost and this should be animated

good idea

#

like a carousel

#

going top to bottom and wrapping around

jolly frost Feb 14, 2026, 1:07 PM

#

💔

jolly frost Feb 14, 2026, 1:07 PM

#

fervent lark like a carousel

yes

fervent lark Feb 14, 2026, 1:08 PM

#

jolly frost 💔

ye im like the powerhouse

jolly frost Feb 14, 2026, 1:08 PM

#

1 commit 😭

#

time to fix this

fervent lark Feb 14, 2026, 1:08 PM

#

xd

#

nah wait wait

#

#

you have 18

#

not 1

jolly frost Feb 14, 2026, 1:09 PM

#

fervent lark not 1

fervent lark Feb 14, 2026, 1:09 PM

#

oh

#

xd

jolly frost Feb 14, 2026, 1:10 PM

#

fervent lark you have 18

still kinda bad

fervent lark Feb 14, 2026, 1:10 PM

#

eh at least acknowledge the good side

#

you're helping out

#

like even if its small

#

you do help out

#

as opposed to some others who promised to help but never did anything, AHEM
-# no not you bagu if you are reading this, i haven't assigned you yet concrete task, so its justifiable

arctic trench Feb 14, 2026, 1:12 PM

#

ferrisCluelesser

fervent lark Feb 14, 2026, 1:12 PM

#

arctic trench <:ferrisCluelesser:1135976750036291745>

neither to you coder lmao

#

im in pain, like holy sh#t i've been doing so so much stuff

#

https://klipy.com/gifs/april-fools-joke-2

Klipy

April Fools Joke: 'It's Fine' Meme

▶ Play video

arctic trench Feb 14, 2026, 1:13 PM

#

fervent lark neither to you coder lmao

no no, i just that way man, I am very demanding of myself.

jolly frost Feb 14, 2026, 1:13 PM

#

fervent lark im in pain, like holy sh#t i've been doing so so much stuff

yeah

fervent lark Feb 14, 2026, 1:15 PM

#

fervent lark as opposed to some others who promised to help but never did anything, **AHEM** ...

hell even some guy that wasn't planning to help, did something, SOMETHING even if tiny thing

#

like he wasn't planning to be a contributor, just one off fixes

#

but its SOMETHING, like some respect i have

#

i hate more than anything false promises of helping out and never doing it (and no not just low-quality but like actual production),

#

also

#

@jolly frost

#

i have some TODO areas

#

i want you to work on those

#

specifically the CollectionTaskFrame and inside the DependencyTaskFrame

#

once those are done and i tweak a bit the API guidelines, @zenith urchin we may need your help in the API documentation

#

for fully writing it

jolly frost Feb 14, 2026, 1:24 PM

#

fervent lark i want you to work on those

Okay

fervent lark Feb 14, 2026, 1:45 PM

#

i feel like btw ChronoGrapher has slightly improved

#

in performance

#

imma test it

#

nvm seems the opposite happeneed weirdly enough

jolly frost Feb 14, 2026, 1:52 PM

#

fervent lark in performance

Later we will need to add code speed test to gh actions

fervent lark Feb 14, 2026, 1:55 PM

#

ye

#

honestly one thing i really want is to get the speed to 1 million empty-ish tasks per second

#

and even faster

#

i want ChronoGrapher to be extremely fast

fervent lark Feb 14, 2026, 1:59 PM

#

fervent lark i want ChronoGrapher to be extremely fast

the more incetives i give companies to switch the better:

Super small package size (34KB vs Megabytes)
Top dog flexibility / extensibility, litterally unmatched
Scales extremely well with you from a home laptop to a distributed service
Integrates with most stuff
Documented down to the minute detail with superrior quality
Extremely fast, handling millions of tasks in one machine with lowest communication overhead
Competitive durability with Temporal

#

if i give them all these reasons

#

i mean its irresistible to switch

#

the only reason you'd ever stick with other solutions is if you are already committed to one and can't afford to change, you're lazy to do so or the ecosystem and maturity is supperior (though ChronoGrapher will reach there at some time)

jolly frost Feb 14, 2026, 2:11 PM

#

fervent lark the only reason you'd ever stick with other solutions is if you are already comm...

we need to cook a tool which can migrate all temporal code to chronographer

fervent lark Feb 14, 2026, 2:12 PM

#

jolly frost we need to cook a tool which can migrate all temporal code to chronographer

chronographer is so different than temporal

#

that a tool can't just migrate it

#

interesting...

#

jolly frost Feb 14, 2026, 2:13 PM

#

hm

fervent lark Feb 14, 2026, 2:13 PM

#

a lot of Arc drops

#

which is definitely a culprit that slows things down

#

here is the entire stacktrace

#

core::ptr::drop_in_place<alloc::sync::Arc<chronographer::scheduler::task_store::ephemeral::EphemeralSchedulerTaskStore<chronographer::scheduler::DefaultSchedulerConfig<alloc::sync::Arc<dyn core::error::Error+core::marker::Sync+core::marker::Send>>>>> [/.../rustlib/src/rust/library/core/src/ptr/mod.rs] <chronographer::scheduler::engine::default::DefaultSchedulerEngine as chronographer::scheduler::engine::SchedulerEngine<C>>::main::{{closure}} [/.../Chronographer/core/src/scheduler/engine/default.rs] <core::pin::Pin<P> as core::future::future::Future>::poll [/.../rustlib/src/rust/library/core/src/future/future.rs] chronographer::scheduler::Scheduler<C>::start::{{closure}}::{{closure}} [/.../Chronographer/core/src/scheduler.rs]

#

From what i gather

#

i have a hypothesis

#

nvm

#

or wait

#

i think this is responsible:

    async fn retrieve(&self) -> Option<(Arc<ErasedTask<C::Error>>, SystemTime, C::TaskIdentifier)> {
        let early_lock: EarlyMutexLock<'_, C> = self.earliest_sorted.lock().await;
        let rev_item = early_lock.peek()?;
        let task = self.tasks.get(&rev_item.1)?;
        Some((task.value().clone(), rev_item.0, rev_item.1.clone()))
    }

#

and more specifically the coordination between the engine and the store

#

which is

#

            async {
                loop {
                    if let Some((task, time, id)) = store.retrieve().await {
                        tokio::select! {
                            _ = clock.idle_to(time) => {
                                store.pop().await;
                                if !store.exists(&id).await { continue; }
                                let sender = EngineNotifier::new(
                                    id,
                                    scheduler_send.clone()
                                );
                                dispatcher.dispatch(task, sender).await;
                                continue;
                            }

                            _ = notifier.notified() => {
                                continue;
                            }
                        }
                    }
                }
            }

#

the hypothesis is because these tasks were small

#

they were executed very fast

#

causing a lot of Arc<T> instances to be dropped (decremented)

jolly frost Feb 14, 2026, 2:24 PM

#

most likely

arctic trench Feb 14, 2026, 2:24 PM

#

@fervent lark

📎 Installation__Theory.pdf

#

here my critics

#

📎 docs_content_docs_clean-architecture.md

fervent lark Feb 14, 2026, 2:25 PM

#

In the theory section of “Installation and Theory,
” I found some very dangerous conceptual
ideas.

I love how you say "very dangerous" like its the end of the world

#

lol

arctic trench Feb 14, 2026, 2:25 PM

#

sorry

fervent lark Feb 14, 2026, 2:26 PM

#

no no its ok

#

Hmmm

#

If we are talking about a web project, using a schedule/task framework like Chronograph and
coupling the business logic with the project dependencies/tools is the worst thing possible
that they can do to their projects maintainability.
Starting with the project tests, unit/integration tests start to become difficult to perform
because of the strong coupling between them.
Furthermore, it is very common to reuse those logics in other places in the project, like, for
example, commands; use it in form classes, or even use another task logic.
I notice that in some of those situations, chronographs have some solutions, but if the base
idea of the following sections/implementations is like this:

#

explain this more

#

whats exactly the problem

#

in simple words

#

is it a guidebook problem or architectural problem

arctic trench Feb 14, 2026, 2:28 PM

#

architectural problem

fervent lark Feb 14, 2026, 2:29 PM

#

mhm

#

continue

arctic trench Feb 14, 2026, 2:29 PM

#

fervent lark whats exactly the problem

oh

#

you mean, why is bay couple?

#

like, couple the logic with the framework?

#

i didn't get your question

fervent lark Feb 14, 2026, 2:31 PM

#

arctic trench you mean, why is bay couple?

more like get to the problem

#

what is you want to explain

#

this uses AI 100%

#

as i notice

#

ye like i get grammar checking and stuff

#

but

arctic trench Feb 14, 2026, 2:33 PM

#

no, kkkk, the project structure and the markdown is

fervent lark Feb 14, 2026, 2:34 PM

#

some "impacts" feel arbirtary, no rhyme or reason just list a drawback that is unrealistic just to sound realistic which i do notice AI does occasionally

arctic trench Feb 14, 2026, 2:35 PM

#

humm

#

i haave a extension in my browser

#

how does gramatical check

#

https://languagetool.org/

LanguageTool

Free AI Grammar Checker - LanguageTool

Instantly check grammar, punctuation, and spelling errors with LanguageTool's AI-powered grammar checker. Enhance your writing in over 30 languages with ease.

#

i use to avoid those errors, maybe that

fervent lark Feb 14, 2026, 2:35 PM

#

ye

#

use that for grammatical errors

arctic trench Feb 14, 2026, 2:36 PM

#

well

#

about the problem

#

i will try dive into again

fervent lark Feb 14, 2026, 2:36 PM

#

i sort of get what you're saying

#

in summary you say ChronoGrapher forces business logic to be part of scheduling, even when its not supposed to be

#

right?

arctic trench Feb 14, 2026, 2:37 PM

#

exactly

fervent lark Feb 14, 2026, 2:38 PM

#

ok for that i disagree completely, and i can prove why

#

this more feels like a guidebook mistake more than an architectural one

#

but

#

ChronoGrapher provides them a way to schedule, now how users organize their code is something up to the user

#

in a web framework, you can break up the business logic to small chunks

#

and on the ChronoGrapher do those

#

like write

jolly frost Feb 14, 2026, 2:40 PM

#

fervent lark this more feels like a guidebook mistake more than an architectural one

yeah

fervent lark Feb 14, 2026, 2:41 PM

#

#[task(schedule = interval(2s))]
async fn MyMantainenceTask(ctx: &TaskContext) -> Result<(), MY_ERROR> {
     check_db(...).await?;
     health_check(..).await?;
     cancel_orders(..).await?;
     // ...
}

#

these are functions defined elsewhere

#

but

#

they are used in scheduling

#

its not like you will define the health checks there, or the cancel order code there

#

@arctic trench am i right? Could be mistaking or misunderstanding something

arctic trench Feb 14, 2026, 2:45 PM

#

humm

#

how that conect with this?

fervent lark Feb 14, 2026, 2:46 PM

#

arctic trench how that conect with this?

wdym?

arctic trench Feb 14, 2026, 2:46 PM

#

Business logic there

#

like, the TaskFrames implementation who store the bussines logic?

fervent lark Feb 14, 2026, 2:47 PM

#

ig... Hmmm

#

seems like a guidebook mistake

#

more specifically the misuse of the word "Business Logic"

#

when i initially said it, i didn't meant to make it sound like the entire website's code is there but more so the code that executes

#

so thats the culprit

arctic trench Feb 14, 2026, 2:48 PM

#

so in the end, it was just my mistake

fervent lark Feb 14, 2026, 2:48 PM

#

arctic trench so in the end, it was just my mistake

eh not really

#

its kind of mixed

#

you did word it a bit too cryptic

#

but

#

ultimately the critique if its that, its justifiable

#

imma fix this one, since ye this can be misleading

fervent lark Feb 14, 2026, 2:49 PM

#

arctic trench Business logic there

probably i should rename it to "Execution Logic" right?

arctic trench Feb 14, 2026, 2:50 PM

#

yeah

#

It would be more appropriate.

fervent lark Feb 14, 2026, 2:51 PM

#

ok then

arctic trench Feb 14, 2026, 2:51 PM

#

i will redo the critis

fervent lark Feb 14, 2026, 2:51 PM

#

ye

#

il publish the changes

#

so you can review them

#

also

#

i noticed something

fervent lark Feb 14, 2026, 2:52 PM

#

arctic trench i will redo the critis

you weren't consistent vs the previous critique

#

if its finished, there is like no score

#

no breakdown of each part, what gets right vs what wrong

#

its just one argument

arctic trench Feb 14, 2026, 2:53 PM

#

ok

fervent lark Feb 14, 2026, 2:54 PM

#

i suggest fetching the new changes btw il make

fervent lark Feb 14, 2026, 2:54 PM

#

arctic trench how that conect with this?

since i do notice this is the older diagram

arctic trench Feb 14, 2026, 2:54 PM

#

fervent lark i suggest fetching the new changes btw il make

ok

fervent lark Feb 14, 2026, 2:55 PM

#

ok pushed

#

update the project rq

arctic trench Feb 14, 2026, 2:55 PM

#

Ok

fervent lark Feb 14, 2026, 2:57 PM

#

and honestly your critique is the topic i was discussing about "AI Use", you shouldn't follow it blindly even if it may seem correct at a first glance, ask yourself "Am i hearing bullshit or is it a genuine problem", challenge the ideas it makes and so on

arctic trench Feb 14, 2026, 3:05 PM

#

ok

fervent lark Feb 14, 2026, 3:06 PM

#

fervent lark ```rust core::ptr::drop_in_place<alloc::sync::Arc<chronographer::scheduler::task...

@jolly frost actually, im noticing something

#

perhaps a memory leak

#

these Arc drops are applied towards the end in bulk

jolly frost Feb 14, 2026, 3:15 PM

#

fervent lark perhaps a memory leak

lol

#

good that you noticed

#

hm

fervent lark Feb 14, 2026, 3:17 PM

#

ye as confirmed there are a lot of allocations happening

#

which seem to be staying

#

so this hypothesis is aligned

#

to confirm this

#

il look if the memory grows

#

since i've allocated like 200k tasks, the memory should be cconstant-ish

#

not grow

arctic trench Feb 14, 2026, 3:42 PM

#

@fervent lark

#

impresive the fact that just the identation can break this.

fervent lark Feb 14, 2026, 3:44 PM

#

lol

#

oops ig

fervent lark Feb 14, 2026, 4:00 PM

#

ok so

#

the CPU usage is

#

it seems to spike a lot

#

and grow slowly

#

interesting...

#

#

memory usage drops?

#

and towards the end spikes up

#

this has to be investigated more

#

Arc on strong count always indicates 2

#

one thing btw we should change are the arguments and return values

#

like man

#

they are fixed

#

and very specific

#

which forces a specific design and not something i want

fervent lark Feb 14, 2026, 5:20 PM

#

i think i know why the sudden Arc drop happened

#

its the Tasks no longer be referenced

#

so they just drop like flies (get the pun)

#

which is kinda normal

fervent lark Feb 14, 2026, 5:40 PM

#

one thing i notice btw is a lot of Vec pushes and pops

#

@jolly frost honestly for the timewheel

#

howz goin

#

we will need probably hierarchical timing wheel

jolly frost Feb 15, 2026, 2:03 AM

#

fervent lark we will need probably hierarchical timing wheel

Okay

placid drum Feb 15, 2026, 6:47 AM

#

hey @fervent lark i was going though code base, is docs updated ?

fervent lark Feb 15, 2026, 9:07 AM

#

placid drum hey <@822874616947146793> i was going though code base, is docs updated ?

well for guidebooks its sorta up to date

#

but for API docs currently no, we are considering a heavy rewrite

placid drum Feb 15, 2026, 9:09 AM

#

okay

placid drum Feb 15, 2026, 9:16 AM

#

fervent lark but for API docs currently no, we are considering a heavy rewrite

https://github.com/GitBrincie212/ChronoGrapher/issues/90 is this open ?

fervent lark Feb 15, 2026, 9:20 AM

#

ig but someone has kinda already worked on it

#

plus i don't find it useful in the core

fervent lark Feb 15, 2026, 9:22 AM

#

placid drum https://github.com/GitBrincie212/ChronoGrapher/issues/90 is this open ?

perhaps this one would be better https://github.com/GitBrincie212/ChronoGrapher/issues/93

GitHub

[SUGGEST] Global Scheduler Interceptors (GSIs) · Issue #93 · GitB...

Is your feature request related to a problem? Please describe. Currently, ChronoGrapher allows for multiple Scheduler instances, this allows for flexibility but it starts to show a crack. That crac...

placid drum Feb 15, 2026, 9:23 AM

#

fervent lark perhaps this one would be better https://github.com/GitBrincie212/ChronoGrapher/...

okay i will take look

fervent lark Feb 15, 2026, 9:25 AM

#

though perhaps it might be better a topic we could discuss, on how best to structure it and make it powerful

placid drum Feb 15, 2026, 9:28 AM

#

fervent lark though perhaps it might be better a topic we could discuss, on how best to struc...

ya we should discuss but i havnt go thorugh whole code base so dont know much

fervent lark Feb 15, 2026, 9:29 AM

#

placid drum ya we should discuss but i havnt go thorugh whole code base so dont know much

well the idea of the feature is the Scheduler could inject its own stuff on top of Tasks being scheduled

#

while you specifically register a Task with the workflow timeout -> fallback -> retry

#

GSIs could add their own TaskHooks

#

their own workflows on top

#

and could fully change the Task itself

placid drum Feb 15, 2026, 9:31 AM

#

make sense

fervent lark Feb 15, 2026, 9:31 AM

#

though i was thinking for it to be more powerful

#

though

#

actually the more i think about it

#

the more i should keep it this way

#

for performance reasons

#

and rename it to a better name or smth

placid drum Feb 15, 2026, 9:33 AM

#

when you say powerful what actually you want ?

fervent lark Feb 15, 2026, 9:33 AM

#

placid drum when you say powerful what actually you want ?

Well it would be able to do more than just modify Tasks

#

could control some of the behaiviour in the Scheduler

placid drum Feb 15, 2026, 9:36 AM

#

hmm i will think about it and discuss with you right now just check code base, i understand how things going on high i want understand deep before i do anything

fervent lark Feb 15, 2026, 9:37 AM

#

placid drum hmm i will think about it and discuss with you right now just check code base, i...

you could read the guidebook a bit

#

though it uses a macro syntax not yet implemented

placid drum Feb 15, 2026, 9:37 AM

#

fervent lark you could read the guidebook a bit

is it in docs ?

fervent lark Feb 15, 2026, 9:37 AM

#

its own website

#

docs/

#

then run pnpm run dev to see it

fervent lark Feb 15, 2026, 9:38 AM

#

fervent lark you could read the guidebook a bit

so far it explains a bit about workflows and TaskHooks

placid drum Feb 15, 2026, 9:39 AM

#

thanks

fervent lark Feb 15, 2026, 9:39 AM

#

np

#

just know some areas are a teeny tiny bit oudated (new error handling approach)

#

plus

#

it uses the proc-macro syntax not yet made

fervent lark Feb 15, 2026, 9:40 AM

#

placid drum thanks

i reccomend giving them a read and telling your thoughts about it

#

both it and the contribution guidelines

placid drum Feb 15, 2026, 9:42 AM

#

fervent lark i reccomend giving them a read and telling your thoughts about it

yes ofc

fervent lark Feb 15, 2026, 9:54 AM

#

placid drum yes ofc

i've published some changes

#

reccomend pulling them

#

also the guidebook guidelines are fully finished

#

Screenshot_2026-02-15_at_11.55.44_AM.png

#

Screenshot_2026-02-15_at_11.55.53_AM.png

#

Screenshot_2026-02-15_at_11.56.05_AM.png

#

Screenshot_2026-02-15_at_11.56.15_AM.png

#

Screenshot_2026-02-15_at_11.56.21_AM.png

#

Screenshot_2026-02-15_at_11.56.34_AM.png

#

Screenshot_2026-02-15_at_11.56.42_AM.png

#

Screenshot_2026-02-15_at_11.56.47_AM.png

#

ye, its a lot...

#

around 2.5k words

#

also if you think its AI, well its partially only there for polishing like grammar mistakes and incossitencies

#

generally the draft was fully written by me

#

@jolly frost what'd you think?

placid drum Feb 15, 2026, 10:22 AM

#

fervent lark around 2.5k words

thanks

jolly frost Feb 15, 2026, 10:26 AM

#

fervent lark <@1119720414021685402> what'd you think?

move checklist to the end

#

repeatedly states the same purpose of the guidebook in multiple ways

#

=>

#

#

Where is :

jolly frost Feb 15, 2026, 10:43 AM

#

jolly frost move checklist to the end

^

fervent lark Feb 15, 2026, 11:00 AM

#

jolly frost repeatedly states the same purpose of the guidebook in multiple ways

damn good eye

#

on like :

fervent lark Feb 15, 2026, 11:01 AM

#

jolly frost ^

The structure is a heading btw

jolly frost Feb 15, 2026, 11:01 AM

#

Ik

fervent lark Feb 15, 2026, 11:01 AM

#

but then it wouldn't make sense to drop the structure down

fervent lark Feb 15, 2026, 11:02 AM

#

jolly frost

is this your change

#

or not?

jolly frost Feb 15, 2026, 11:02 AM

#

fervent lark is this your change

Yeah

fervent lark Feb 15, 2026, 11:02 AM

#

ah i see

fervent lark Feb 15, 2026, 11:03 AM

#

jolly frost ^

for the checklist, hmmm

#

idk, we could keep it there or move it at the end

#

actually move it at the end

#

rename it to Guidebook Checklist

fervent lark Feb 15, 2026, 11:03 AM

#

jolly frost Where is `:`

add the : yourself

jolly frost Feb 15, 2026, 11:05 AM

#

fervent lark but then it wouldn't make sense to drop the structure down

why

fervent lark Feb 15, 2026, 11:06 AM

#

jolly frost why

keep it this way

#

the checklist drop it down to the complete bottom

jolly frost Feb 15, 2026, 11:06 AM

#

yeah

#

and structure goes after "explaining your topic effectively"

fervent lark Feb 15, 2026, 11:07 AM

#

?

#

Structure is the heading

#

of all 3

#

if we move structure

#

we move all the subheadings

jolly frost Feb 15, 2026, 11:07 AM

#

oh

fervent lark Feb 15, 2026, 11:09 AM

#

also how is like the guidebook guidelines? In terms of what it says

#

strictness, tips for technical writing and so on

#

@placid drum i forgot to tell you, anything you might need me for explaination since rn API docs are missing

#

im here

jolly frost Feb 15, 2026, 11:12 AM

#

fervent lark also how is like the guidebook guidelines? In terms of what it says

good actually

fervent lark Feb 15, 2026, 11:17 AM

#

jolly frost good actually

how so?

#

its kinda vague

placid drum Feb 15, 2026, 11:24 AM

#

fervent lark im here

okay i will ask you if i am stuck

fervent lark Feb 15, 2026, 11:25 AM

#

placid drum okay i will ask you if i am stuck

btw il provide you some important details you should know

fervent lark Feb 15, 2026, 11:30 AM

#

placid drum okay i will ask you if i am stuck

Never confuse TaskHooks as just Event Listeners, they are more than that, they can be full on State Managaers (via listening to TaskHook<()> or the alias NonObserverTaskHook), Post-Error Handlers (similar to error handlers, but they cannot save the error, usually they do external activity to midigate the error, they are a sort of event listener niche), Markers (a niche to state managers, just by their presence, one can deduce information about)
TaskHooks are even more powerful than just event listening and the above stuff, there are patterns such as Hook-To-Hook communication, registering internal TaskHooks in TaskFrames for tracking, modifying data in TaskHooks, running different code based on one or multiple TaskHooks and so on...
TaskFrames can be stacked with one and the other, THE ORDERING MATTERS, its the same as decorating where if you switch the ordering, the entire behaiviour of the workflow part changes, for example retry -> fallback ≠ fallback -> retry
The Scheduler contains a config generic, this is more than just a fancy way to not write many generics for the individual Scheduler composites (which are SchedulerTaskDispatcher, SchedulerEngine, SchedulerTaskStore and SchedulerClock). Each composite has access to this config object and with it, they can do lots of stuff such as:
- Running different (perhaps even more optimized code) for specific config shapes (they could detect if a specific composite is present).
- Support only a specific config shape

#

and another thing to mention, the design philosophy of ChronoGrapher which you should follow is "Minimalism Over Bloat, Emergent Over Predefined, Simplicity Over Complexity (*)", the third principle has an asterisk to it, as usually its best to prioritize flexibility / extensibility (i.e. Power), but not too much, an equilibrium is required

#

is it helpful?

placid drum Feb 15, 2026, 11:36 AM

#

fervent lark is it helpful?

yes

#

its very helpful

fervent lark Feb 15, 2026, 11:37 AM

#

ok then

#

also some contribution guidelines are long, they are more made for correctness rather than just accessibility

#

just don't let it scare you, take things a step at a time

placid drum Feb 15, 2026, 11:38 AM

#

fervent lark just don't let it scare you, take things a step at a time

ya i will need time to get comfortable with this

arctic trench Feb 15, 2026, 2:36 PM

#

@fervent lark one question: will chronographer suport sync tasks?
in the examples only have async so i was question me if it will have.

use chronographer::prelude::*;

#[task(schedule = interval(2s))]
async fn MyTask(ctx: &TaskContext) -> Result<(), TaskError> {
    println!("Hello ChronoGrapher!");
    Ok(())
}

#[chronographer::main]
async fn main(scheduler: DefaultAnyhowScheduler) {
    let task_inst = MyTask::instance();
    let _ = scheduler.schedule(task_inst).await;
}

arctic trench Feb 15, 2026, 4:33 PM

#

I almost finalized the critics, but this time I will avoid as much as possible going through the embarrassment that I passed yesterday.

#

ferrisCluelesser

fervent lark Feb 15, 2026, 5:30 PM

#

arctic trench <@822874616947146793> one question: will chronographer suport sync tasks? in th...

well

#

sync tasks wwill require some trickery

#

maybe like using one async instance instead of multiple

#

honestly is it really important to support it?

arctic trench Feb 15, 2026, 5:32 PM

#

If you try run a code that is sync into async context, it will trigger a error in rust?

#

At least, in python, this happen

#

But for other languages, could exist a trick to for exemple, run a sync function who came from other language as async

arctic trench Feb 15, 2026, 5:33 PM

#

arctic trench If you try run a code that is sync into async context, it will trigger a error i...

But, what about rust?

fervent lark Feb 15, 2026, 5:35 PM

#

arctic trench But, what about rust?

the idea would be to just run a block operation on async

#

or smth

#

though again, ask yourself, is this something really critical

#

most applications when it comes to the need of scheduling are async

#

like lots of I/O operations, lots of networking, lots of concurrent work

#

this is the perfect enviorement for async to thrive

fervent lark Feb 15, 2026, 5:57 PM

#

oh god... @arctic trench the keyboard warrior

arctic trench Feb 15, 2026, 5:57 PM

#

🤣 🤣 🤣

#

Just a moment

fervent lark Feb 15, 2026, 5:57 PM

#

XD ye ye ik

#

take ur time

arctic trench Feb 15, 2026, 5:58 PM

#

I writte this in my cell

#

Phone*

fervent lark Feb 15, 2026, 5:58 PM

#

https://tenor.com/view/holy-moly-gif-2379897567703251318

Tenor

#

dedication

arctic trench Feb 15, 2026, 6:01 PM

#

Let's suppose that I have a web application that is not async, basically a microservice that trains ML models.

This app will have a simple interface in web app service to manage its models for other microservices.

And I will need a scheduler/task runner to perform the background tasks like gathering data and training the model.

In Python, for example, the scikit-learn and PyTorch libraries are synced.

In the case of Rust, we know the async ecosystem is more mature because it appeared in the language's early stages.

Looking right now for ML libs for Rust, I found the smartcore lib, similar to scikit-learn from Python, and it doesn't have async APIs; it's completely synchronous.

For this example, I would have problems using the Chronographer because I will need to adapt the SmartCore APIs to allow async execution, normally doing something like sync to async.```rust
use tokio::task;

async fn run_sync_code() {
let result = task::spawn_blocking(|| {
expensive_sync_operation()
}).await.unwrap();
}

Searching here about async operations in Rust, I found that if you try to run an expensive CPU-bound operation in an async context, the operation will block the main thread.

This will have performance implications.

#

Just to have context, you know how the Event Loop works?
In this case, i know for Node.js, but i belive libs like tokio works the same

fervent lark Feb 15, 2026, 6:05 PM

#

oh ye

#

ok then you're right

arctic trench Feb 15, 2026, 6:08 PM

#

But is too complex convert the tasks from users into async?
Like, would be no possible verify if the task is sync and if true, run it inside the task::spawn_blocking?

fervent lark Feb 15, 2026, 6:08 PM

#

arctic trench But is too complex convert the tasks from users into async? Like, would be no po...

ye it would be a bit of a hassle to convert ChronoGrapher to sync

arctic trench Feb 15, 2026, 6:08 PM

#

No no

#

No chronographer

#

The function tasks only

fervent lark Feb 15, 2026, 6:09 PM

#

oh like make ChronoGrapher handle both async and sync tasks

arctic trench Feb 15, 2026, 6:09 PM

#

Yeah

fervent lark Feb 15, 2026, 6:10 PM

#

not the entirity

#

hmm

#

could be doable

arctic trench Feb 15, 2026, 6:10 PM

#

Well

fervent lark Feb 15, 2026, 6:10 PM

#

but depends

#

keyword is doable

#

it will be hard

#

i don't think its worth it

#

seems worth it but i highly doubt it is

#

this is something we will see with the userbase of ChronoGrapher

#

if they do demand it

#

then we will try

arctic trench Feb 15, 2026, 6:12 PM

#

Well, then, in this case, how our users would avoid the the example i showed?

fervent lark Feb 15, 2026, 6:12 PM

#

and not like one to two users but like a couple

fervent lark Feb 15, 2026, 6:12 PM

#

arctic trench Well, then, in this case, how our users would avoid the the example i showed?

we could make the dispatcher hold a thread pool

#

or smth

#

and distribute tasks there

arctic trench Feb 15, 2026, 6:14 PM

#

What is smth?

fervent lark Feb 15, 2026, 6:21 PM

#

smth = something

arctic trench Feb 15, 2026, 6:27 PM

#

Humm, i will take a look at the tokio docs, to see how the event loop works

#

And currently in chronographer, you alocate new threads to execute the tasks?

fervent lark Feb 15, 2026, 6:43 PM

#

arctic trench And currently in chronographer, you alocate new threads to execute the tasks?

well right now nope

#

tokio i think does it

#

automatically

#

perhaps

#

idk

#

if not, well a worker pool will benifit both async and sync (as it will be easier for compatibility)

arctic trench Feb 15, 2026, 6:49 PM

#

humm, men, i don't know, but any way, i will search a little here, after that i pass what i found

#

my critics

📎 Installation__Theory_-_Final.pdf

#

I remember that something was missing, and I was planning to add it later, but…
I forgot what it was ferrisCluelesser

fervent lark Feb 15, 2026, 6:53 PM

#

arctic trench my critics

anyhow and thiserror are optional, and i clearly state We reccomend so its a reccomendation and not enforcement

#

plus this can be backed up by

#

this allows for better error handling...

arctic trench Feb 15, 2026, 6:53 PM

#

humm, and what about the --features flag?

fervent lark Feb 15, 2026, 6:53 PM

#

hold on reading

#

good point

#

about the features

#

might work out better

#

ye ChronoGrapher would benifit from making them features

#

But, if I'm not mistaken, Scheduler takes a config as one of its properties, right?
So, how can this config be customized too?

Yes it does, but the config is a trait

#

we could maybe use a macro to automate the boilerplate if needed

#

but slightly

#

not fully

fervent lark Feb 15, 2026, 6:56 PM

#

arctic trench humm, and what about the --features flag?

also for the article element, you wondering the TLDR?

#

like what its goal?

arctic trench Feb 15, 2026, 6:57 PM

#

yeah

fervent lark Feb 15, 2026, 6:57 PM

#

first TL;DR is an abbriviation of "Too Long ; Didn't Read"

#

its a summary

arctic trench Feb 15, 2026, 6:57 PM

#

ahhh

#

nvm

fervent lark Feb 15, 2026, 6:57 PM

#

it doesn't pack much info

#

its just says what we've done

#

for the frameworks, yeah definitely

#

we will need

#

i do agree the In Hurry section should be added

#

i do agree with the integrations coming before workflows

#

thats a good critique

arctic trench Feb 15, 2026, 7:00 PM

#

thanks

#

now, i have a lot of pages to do in tasks to workflows

fervent lark Feb 15, 2026, 7:01 PM

#

ye

#

almost...

#

do not critique the last 2 chapters

#

Advanced Workflow Primitives and Summary & Practical Patterns

#

honestly il get to work on those a bit

arctic trench Feb 15, 2026, 7:02 PM

#

ok

fervent lark Feb 15, 2026, 7:03 PM

#

yup those

#

do look into the handling failure and basic use of retries

#

il change Fallback Patterns & Usage a bit, wwork on Advanced Retries & Fallbacks and finish it

#

the fallback chapter i realize teaches a very bad pattern

#

#[taskframe]
async fn myfallback(ctx: &TaskContext) -> Result<(), TaskError> {
    // Real code is more complex than this demo
    println!("Simulating fallback logic, attempting to fix this issue");
    let mut rng = rand::thread_rng();

    // Fallbacks can fail too, and SHOULD leak through their errors
    rng.gen() <= 0.8
}

#

ye...

#

It teaches the user to do things randomly and lazily in fallbacks

arctic trench Feb 15, 2026, 7:05 PM

#

ok

fervent lark Feb 15, 2026, 7:05 PM

#

hmmm

#

il rewrite the docs a bit due to the TaskError

arctic trench Feb 15, 2026, 7:05 PM

#

men, would not be better reformulate the docs only you fully finish this error handle part?

fervent lark Feb 15, 2026, 7:06 PM

#

arctic trench men, would not be better reformulate the docs only you fully finish this error h...

the error handling part is sorta finished

#

like only some areas to adjust

#

and its done

arctic trench Feb 15, 2026, 7:06 PM

#

humm, ok

fervent lark Feb 15, 2026, 7:09 PM

#

also speaking of error handling

#

anyhow can't really plug in nicely

#

    type Error: Error + Send + Sync;

#

it requires the Error trait

#

hmm

arctic trench Feb 15, 2026, 7:16 PM

#

@fervent lark , did you read this section?
https://tokio.rs/tokio/tutorial#when-not-to-use-tokio

Tutorial | Tokio - An asynchronous Rust runtime

Tokio is a runtime for writing reliable asynchronous applications with Rust. It provides async I/O, networking, scheduling, timers, and more.

#

maybe, our aswer for our problems would be here

fervent lark Feb 15, 2026, 7:18 PM

#

arctic trench maybe, our aswer for our problems would be here

ye though they are incompatible with each other

#

sorta

#

but like i tried before

arctic trench Feb 15, 2026, 7:30 PM

#

fervent lark ye though they are incompatible with each other

why?

fervent lark Feb 15, 2026, 7:30 PM

#

eh i tried it before

#

and i had issues

#

@arctic trench @jolly frost do want a comment

#

should i remove the error bound?

#

and just have it Send + Sync?

arctic trench Feb 15, 2026, 7:40 PM

#

Man, to be frank, I'm not the most indicated person to suggest it; I'm still learning.

#

What is this error bound ?

fervent lark Feb 15, 2026, 7:42 PM

#

from std

fervent lark Feb 16, 2026, 10:25 AM

#

fervent lark ```rust type Error: Error + Send + Sync; ```

will be quite hard to get it right

#

though its important

fervent lark Feb 16, 2026, 10:46 AM

#

fervent lark ```rust type Error: Error + Send + Sync; ```

im going mentally insane over this shit

placid drum Feb 16, 2026, 12:47 PM

#

fervent lark im going mentally insane over this shit

how tf did you do 1k commits??

fervent lark Feb 16, 2026, 12:48 PM

#

placid drum how tf did you do 1k commits??

insanity

#

~~and being locked in a white room for 24 hours a day~~

#

nah jk

placid drum Feb 16, 2026, 12:48 PM

#

creazy do you have job or somthing ?

fervent lark Feb 16, 2026, 12:48 PM

#

placid drum how tf did you do 1k commits??

mind you, this is the core. THE CORE

fervent lark Feb 16, 2026, 12:49 PM

#

placid drum creazy do you have job or somthing ?

im the Unemployment Final Boss

#

never heard of a job

#

/j

placid drum Feb 16, 2026, 12:49 PM

#

fervent lark im the Unemployment Final Boss

are you not looking for one ?

fervent lark Feb 16, 2026, 12:50 PM

#

placid drum are you not looking for one ?

no no i have, sort of, though don't want to disclose that detail

#

private reasons

placid drum Feb 16, 2026, 12:50 PM

#

fervent lark no no i have, sort of, though don't want to disclose that detail

say so i thought how tfk recruiters can be this blind

fervent lark Feb 16, 2026, 12:53 PM

#

lol

placid drum Feb 16, 2026, 12:58 PM

#

what i understand from codebase is we create Task using TaskFrame and scheduler taskfream which where we execute what we schedule and there TaskConfig and Scheduler which use to help us to decide when to and how to excute task

fervent lark Feb 16, 2026, 12:59 PM

#

TaskConfig?

#

you mean SchedulerConfig

placid drum Feb 16, 2026, 1:01 PM

#

ya task config is struct that have frame and schedule which task trigger

fervent lark Feb 16, 2026, 1:02 PM

#

its Task

#

not TaskConfig

#

you used chatgpt or smth?

placid drum Feb 16, 2026, 1:03 PM

#

pub struct TaskConfig<T1: TaskFrame, T2: TaskTrigger> {
    frame: T1,
    schedule: T2,
}

#

? isnt this correct i read in /src/task.rs

#

also what is concept of erasedTask ? and like somewhere impl a hook but also you make non emittable or NonObserver i dont recall it properly why ?what is analogy behind it?

fervent lark Feb 16, 2026, 1:10 PM

#

placid drum ```rust pub struct TaskConfig<T1: TaskFrame, T2: TaskTrigger> { frame: T1, ...

well ye but like the name is different

fervent lark Feb 16, 2026, 1:10 PM

#

placid drum also what is concept of erasedTask ? and like somewhere impl a hook but also you...

an erased task is just a type alias to Task with dyn TaskFrame (kinda) and dyn TaskTrigger

fervent lark Feb 16, 2026, 1:11 PM

#

placid drum also what is concept of erasedTask ? and like somewhere impl a hook but also you...

() is a special event, the reason it exists is so you can implement a TaskHook while never listening to any kind of event

#

its not emittable

#

and NonObserverTaskHook is supposed to be an alias to it

fervent lark Feb 16, 2026, 1:12 PM

#

placid drum ```rust pub struct TaskConfig<T1: TaskFrame, T2: TaskTrigger> { frame: T1, ...

oh wait now i get what you mean by TaskConfig

#

#[derive(TypedBuilder)]
#[builder(build_method(into = Task<T1, T2>))]
pub struct TaskConfig<T1: TaskFrame, T2: TaskTrigger> {
    frame: T1,
    schedule: T2,
}

#

this one

placid drum Feb 16, 2026, 1:12 PM

#

fervent lark you used chatgpt or smth?

i tired but its gives ambiguous ans so just drop the plan

placid drum Feb 16, 2026, 1:12 PM

#

fervent lark ```rust #[derive(TypedBuilder)] #[builder(build_method(into = Task<T1, T2>))] pu...

yes

fervent lark Feb 16, 2026, 1:13 PM

#

its just a builder thing

#

honestly though

#

it might be reworked

#

for like a better syntax

#

or actually removed, better, as it doesn't require a builder really

placid drum Feb 16, 2026, 1:14 PM

#

i guess naming can better i guess its little confusing

fervent lark Feb 16, 2026, 1:15 PM

#

placid drum i guess naming can better i guess its little confusing

honestly, it will be removed

#

as no point using a builder

placid drum Feb 16, 2026, 1:16 PM

#

so should i read whole codebase for like what should i do ?

#

like you said its gonna have some changes like i can do some small task and learn codebase while doing task.

fervent lark Feb 16, 2026, 1:35 PM

#

placid drum so should i read whole codebase for like what should i do ?

ig read it to get an idea

#

then with the tasks

#

you will get more familiarity

placid drum Feb 16, 2026, 1:37 PM

#

fervent lark you will get more familiarity

ya i guess i should do some implementation and playaround

fervent lark Feb 16, 2026, 1:39 PM

#

ye

fervent lark Feb 16, 2026, 1:39 PM

#

placid drum ya i guess i should do some implementation and playaround

one thing you could help btw is error handling

#

its a pain in the ass

#

don't think about erasing the error (kinda), fully erasing the error has been done before and lets just say

#

the error handling side wasn't for sure having fun with downcasting

fervent lark Feb 16, 2026, 2:01 PM

#

placid drum ya i guess i should do some implementation and playaround

btw the idea currently is to have an associated type for the error

#

that implements the Error trait bound

#

and is Send + Sync

#

in practice the Error trait bound is problematic

#

anyhow cannot be supported, it can slightly but it requires you to basically convert it to a box dyn error

#

its not a smooth process and kinda defeats the purpose of using anyhow imo

#

another idea was to like use Into<Box<dyn Error + Send + Sync>> for anything convertible to it

#

but then i ran to conflicting implementations since anyhow "could" implement error in the future

placid drum Feb 16, 2026, 2:07 PM

#

i understand what you are saying but not quite i guess i need more time to adapt to rust give 1-2 weeks

#

i never build something this complex in rust

fervent lark Feb 16, 2026, 2:17 PM

#

mhm

zenith urchin Feb 16, 2026, 11:26 PM

#

Hi @fervent lark as we talked, here is my feedback for the docs. I tried to give as much as helpful feedback.

Maybe because of my pc but rendering at the beginning is causing browser to stuck.
The ordering of retries and fallbacks is pinned ( Shouldn't this be "are" pinned? )
For the workflow(retry(3, 2s)) whereas task interval was already 2s. We may get the workflow::delay::default as the time of the task. Since people will do the same time most of the time except people who are aware what they are doing, it might help to reduce boilerplate.
Again this will be about workflow, I liked the timeout macro, but as far as I understood from the docs, as default it is infinite. When you define timeout(5s) then only it timeout. This is nice, but instead of infinite non-defined. Wouldn't it be nice to timeout using the task interval like let's say task interval is T * retry * retry_time as default or only T for timeout, retry, Fallback order. For infinite tasks, we can define timeout(None) or something like that.
One question, can I define workflow like (timeout(10s), retry(3, 2s) , timeout(1s)) ?
Advanced Fallbacks felt like it is cut off at the end. I think you could explain it little bit in more detail which can display specific error handling for each fallback. I think we are aiming to implement specific logic for handling errors at least.
It would be nice to have counting_logic to have Fn(ctx: _ThresholdCtx, err: Error) -> bool , so you can define your own counting logic or even advance to counting logic depending on called retries, timeouts etc.
I am not sure if I missed it, but I dont think I saw fallback(...) ordering affect is it like first come first serve?

I will continue reading docs later. Introspecting Workflow and Contributing left.

fervent lark Feb 17, 2026, 9:28 AM

#

sure thing

fervent lark Feb 17, 2026, 9:35 AM

#

zenith urchin Hi <@822874616947146793> as we talked, here is my feedback for the docs. I trie...

Hmmm, will need more context about it, very weird your rendering causes the browser to be stuck such as hardware, the browser you use and so on. Could be your PC perhaps you had many stuff loaded, have you tried running only the website without any other applications to see if its really the problem
Yeh probably typo
One idea would be to have the ability to reference global variables
We will see about that, not sure tbh, we could, would need a bit more explaination
Yes you can define that and thats the power of ChronoGrapher versus other workflow orchestrators really,the timeouts act to different sections, the timeout(1s) acts to every retry whereas timeout(10s) is a global deadline for the entire workflow
Yes its a work in progress, the idea would be to explain the multiple fallbacks patterns where you declare smaller fallbacks each handling their own sets of errors, if it can't handle it, then it errors out (which propegates to the next fallback and the cycle repeats til we went with all fallbacks)
There is, i do plan on having for threshold, its just not documented
Hmm, this might be part of the WIP docs of advanced retries and fallbacks

#

thanks a lot for the feedback, if you can go the extra mile and rate:

How effectively it taught you stuff per chapter
How professional it was per chapter
The cogntive load per chapter
What you enjoyed about it
How much friction it posed to you

if you noticed any quality drops and even a total score out of 10, would be heavily appreciated

fervent lark Feb 17, 2026, 11:26 AM

#

sometimes i wish Error was more standarized, and everything would be convertible to it

#

really painful

placid drum Feb 17, 2026, 11:45 AM

#


#[derive(Debug, Error)]
#[error("Something went wrong")]
pub struct ErrorIsWrong;


#[tokio::main]
async fn main() {
    let schduler = Scheduler::<DefaultSchedulerConfig<ErrorIsWrong>>::default();

    let exec_frame = DynamicTaskFrame::new(|_ctx| async {
        println!("Trying task.....");
        // Ok(())
        Err(Arc::new(std::io::Error::new(ErrorKind::Other, "uh oh")) as ErrorIsWrong)
    });

    let task = Task::simple(TaskScheduleCron::new("* * * * *".to_string()), exec_frame);

    let _ = schduler.schedule(&task).await;

    schduler.start().await;

    loop {}
}

if i do this it will not let me throw the error like it should do its showing typecasting error but this too bad way to do errors like if i am defining error isnt it suppose get used there something like this ?

#

@fervent lark

fervent lark Feb 17, 2026, 11:50 AM

#

hm wait

fervent lark Feb 17, 2026, 11:50 AM

#

placid drum ```rust #[derive(Debug, Error)] #[error("Something went wrong")] pub struct Err...

it will throw an error?

#

wdym

#

the SchedulerEngine will print the error

#

and shutdown the task

placid drum Feb 17, 2026, 11:52 AM

#

fervent lark it will throw an error?

no compiler will throw error it will not let compile code

fervent lark Feb 17, 2026, 11:52 AM

#

what error specifically from the compiler

placid drum Feb 17, 2026, 11:53 AM

#

like Non-primitive cast: Arc<std::io::error::Error> as ErrorIsWrong [E0605]

fervent lark Feb 17, 2026, 11:54 AM

#

hmm

jolly frost Feb 17, 2026, 11:59 AM

#

hm

placid drum Feb 17, 2026, 12:00 PM

#

Err(ErrorDyn)
if use this instead

Trying task.....
Scheduler engine received an error for Task with identifier (4a79773e-9597-4c08-b95c-6dd48419ab9d):
ErrorIsWrong
so what i am saying is that isnt it uneccary to defined
let schduler = Scheduler::<DefaultSchedulerConfig<ErrorIsWrong>>::default();
here ?

fervent lark Feb 17, 2026, 12:06 PM

#

placid drum Err(ErrorDyn) if use this instead Trying task..... Scheduler engine received a...

its nesscarry

#

also

placid drum Feb 17, 2026, 12:06 PM

#

fervent lark its nesscarry

so it will throw on schedule error ?

fervent lark Feb 17, 2026, 12:06 PM

#

ye hold on let me explain it clearly

#

pub trait SchedulerConfig: Sized + 'static {
    type TaskIdentifier: TaskIdentifier;
    type TaskError: TaskError;
    type SchedulerClock: SchedulerClock<Self>;
    type SchedulerTaskStore: SchedulerTaskStore<Self>;
    type SchedulerTaskDispatcher: SchedulerTaskDispatcher<Self>;
    type SchedulerEngine: SchedulerEngine<Self>;
}

This is the config

#

a bit modified in my enviorement

#

but still same-ish

#

    type TaskError: TaskError;

#

this is the task error

#

the reason its something in the configuration is because workflow parts will probably need to know the errors

#

same with the Scheduler stuff

#

the idea is TaskError is any kind of error you expect your tasks to throw

#

defining it, allows you to handle the errors via match

#

the idea is to contrain the error per Scheduler

#

one scheduler might be built for ErrorA the other scheduler for ErrorB

placid drum Feb 17, 2026, 12:11 PM

#

fervent lark one scheduler might be built for ``ErrorA`` the other scheduler for ``ErrorB``

when it will be thrown like is it for type only ?

fervent lark Feb 17, 2026, 12:12 PM

#

🤔

#

?

#

you confuse me

placid drum Feb 17, 2026, 12:12 PM

#

lol

#

let me explain my doubt

fervent lark Feb 17, 2026, 12:13 PM

#

ye do explain it clearly

placid drum Feb 17, 2026, 12:15 PM

#

we are using error per schedule, my question is that

when we use somthing like this


<DefaultSchedulerConfig<ErrorIsWrong>>

is it just used to satisfy the type or will i get thrown as i use this
#[error("Something went wrong")]

fervent lark Feb 17, 2026, 12:17 PM

#

wdym is it just used to satisfy the type or will i get thrown as i use this?

#

can you explain it more clearly

#

be very specific about stuff generally, since rn its kinda vague

placid drum Feb 17, 2026, 12:22 PM

#

now i get it like we defining in ```
<DefaultSchedulerConfig<ErrorIsWrong>>

 like this because we expect task error to be type this. i thought it is different for task and schedule

fervent lark Feb 17, 2026, 12:22 PM

#

ok?

placid drum Feb 17, 2026, 12:22 PM

#

ya

fervent lark Feb 17, 2026, 12:23 PM

#

placid drum now i get it like we defining in ``` <DefaultSchedulerConfig<ErrorIsWrong>> ``` ...

DefaultSchedulerConfig btw is for the default scheduler components

#

it just requires a generic

#

because different enviorements have different error types

#

so i can't remove it

placid drum Feb 17, 2026, 12:24 PM

#

yess, i was confuse there, i thought why cant we just remove it then i saw code it like we expect task to throw error same as generic type

#

is it correct ?

fervent lark Feb 17, 2026, 12:25 PM

#

yes

#

we can't really remove it, for the reason mentioned above, so we keep it as a generic

placid drum Feb 17, 2026, 12:26 PM

#

fervent lark we can't really remove it, for the reason mentioned above, so we keep it as a ge...

it is actually great we know before hand that our task is gonna thore same error as we define

fervent lark Feb 17, 2026, 12:27 PM

#

yup

placid drum Feb 17, 2026, 12:28 PM

#

fk it i never meant to chat damn!

fervent lark Feb 17, 2026, 12:28 PM

#

?

placid drum Feb 17, 2026, 12:28 PM

#

nah just frustrated over spell mistake

fervent lark Feb 17, 2026, 12:28 PM

#

placid drum nah just frustrated over spell mistake

its sorta ok, though sometimes they do confuse me, i mean for casual stuff i won't mind

#

for something you want to tell about ChronoGrapher, then ye i need a bit more specificity

placid drum Feb 17, 2026, 12:29 PM

#

fervent lark its sorta ok, though sometimes they do confuse me, i mean for casual stuff i won...

thanks tho

placid drum Feb 17, 2026, 12:29 PM

#

fervent lark for something you want to tell about ChronoGrapher, then ye i need a bit more sp...

i will try my best to be specific.

fervent lark Feb 17, 2026, 12:30 PM

#

np

placid drum Feb 17, 2026, 12:30 PM

#

also what do you mean you need error standardization ?

placid drum Feb 17, 2026, 12:31 PM

#

fervent lark sometimes i wish ``Error`` was more standarized, and everything would be convert...

.

fervent lark Feb 17, 2026, 12:33 PM

#

placid drum also what do you mean you need error standardization ?

anyhow is a different error type than the typical std error implementations

#

it doesn't implement the error trait

placid drum Feb 17, 2026, 12:37 PM

#

so you want something uses std error implementations

fervent lark Feb 17, 2026, 12:37 PM

#

no

fervent lark Feb 17, 2026, 12:37 PM

#

placid drum so you want something uses std error implementations

but like i wish errors weren't a pain in the ass to manage

placid drum Feb 17, 2026, 12:39 PM

#

fervent lark but like i wish errors weren't a pain in the ass to manage

any solution you thought ?

fervent lark Feb 17, 2026, 12:39 PM

#

well i had thought of multiple

#

like providing a conversion trait which can convert to the error types

#

the above however as turns it out, it can't work

#

another was enum storing std errors, anyhow errors... etc. But turned to be a bad API design

#

so the third solution was:

#

this one

#

pub trait TaskError: Debug + Display + Send + Sync + 'static {
    fn as_any(&self) -> &(dyn Any + Send + Sync);
}

#

a bit pain for the users managing TaskHooks

#

but i can't prevent it

placid drum Feb 17, 2026, 12:42 PM

#

fervent lark a bit pain for the users managing TaskHooks

i havnt reach that part but if you are saying it might be correct.

fervent lark Feb 17, 2026, 12:46 PM

#

placid drum i havnt reach that part but if you are saying it might be correct.

a worthwhile part to check

#

its arguably one areas ChronoGrapher has excelled in

#

Pushed new changes btw

#

@jolly frost

#

slowly ChronoGrapher seems to be finishing

#

its core

#

@placid drum if you think the core itself is complex, wait til about persistence and distributed systems

#

these are super difficult

placid drum Feb 17, 2026, 12:54 PM

#

fervent lark <@876294882631770112> if you think the core itself is complex, wait til about pe...

let see for me all complex are complex

fervent lark Feb 17, 2026, 12:54 PM

#

placid drum let see for me all complex are complex

persistence is incredibly hard, like i've tried to deal with it, i've even got a theory for it which could prove much better than other competitors

#

but

#

its still hard

placid drum Feb 17, 2026, 12:56 PM

#

fervent lark persistence is incredibly hard, like i've tried to deal with it, i've even got a...

i wanted to built sync engine for ws only which will be light weight only and build node freamwork on top-off it

#

then i saw this project, it same thing i wanted like i wanted somthing in node that schedule task but excute python. well i cant explain any further i am really bad at this thing

fervent lark Feb 17, 2026, 1:01 PM

#

placid drum then i saw this project, it same thing i wanted like i wanted somthing in node t...

so like have one Task in JS, another in Python and another in Java and it would work in harmony?

#

if you mean that, well it was considered as a feature, like you could listen to events defined in Python from Java

#

but ultimately its something complex and maybe not really in need

placid drum Feb 17, 2026, 1:15 PM

#

fervent lark so like have one Task in JS, another in Python and another in Java and it would ...

ya like python is good for cpu bound task compare to node and node for io compare to python

#

otherwise we need queue/db to share task details

#ChronoGrapher - One Unified Scheduler, Unlimited Power

PUSHED

Pushed new changes btw