mirror of
https://github.com/hanzoai/tasks.git
synced 2026-10-30 14:56:19 +00:00
Lina JodoinandGitHub
a646b2d5ef
I'm sending the review for the mechanism (and an example callsite), and I'll send out a review that makes use of it throughout the scheduler code afterwards. ## What changed? - CHASM scheduler components each parent a new EventLog component, which we'll use to record decision logic details that are normally too spammy for logs. - No plan to expose this through any APIs just yet; it isn't meant to be customer-facing (though, I am thinking about how we can make it easy for dev success to get at) ## Why? - V1 debugging was often done through use of the workflow's event history; without an analogue for V2, it's difficult to get a clear picture of how the logic arrived at a certain output state. - Info logging in the same capacity would likely be too spammy for our observability system. - It's difficult to trace a complete picture for an individual schedule *over time* using just Loki. Schedules are often long-lived, with state transitions taking place in short blips over periods of days or weeks. Being able to get a complete list on demand for a relevant scheduler will greatly improve debugging time. ## How did you test it? - [ ] built - [ ] run locally and tested manually - [ ] covered by existing tests - [x] added new unit test(s) - [ ] added new functional test(s) ## Potential risks - This could increase scheduler state size, however: - V2 already measures notably lighter on storage than V1 (not to mention, no event history data whatsoever) - Log is bounded to max 30 messages per component (usually scheduler, generator, invoker) of max 1000 characters each (e.g., ~100KB), as a safety mechanism - Most messages logged will be small and informational, not large state dumps (e.g., "scheduler unpaused", "generator scheduled for ..."). - Backfillers each get their own log, which shares a Backfiller's lifecycle.