Add `ExactlyOnceEvaluator`

Open
  • Is something wrong?
#226 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
25/100
Issue type
Feature
Clarity
Needs clarification
Activity status
Quiet
Tech stack
python
Domain
backend, distributed-systems

Research direction

Start by locating the CallableModel evaluator entry points and the existing durable-caching implementation referenced in the issue. Before implementation, resolve the return value, atomicity, and storage-abstraction questions; done means the semantics and pluggable ledger behavior are specified well enough to test exactly-once execution and skipped invocations.

Written by the indexing model from the issue text.

Description

Add an evaluator that enforces exactly-once execution semantics for CallableModels that perform external side effects (sending notifications, posting webhooks, writing to external systems, kicking off downstream jobs, etc.).

This is distinct from durable caching. Durable caching is an optimization — a missing entry simply means recompute. Exactly-once is a correctness guarantee — a missing ledger entry means "the side effect has not happened, run it now," and a present entry means "do not run it again under any circumstances." Clearing the ledger has real-world consequences and should not be casual.

Behavior
  • Maintain a durable ledger of completed (model, context) invocations.
  • On invocation, check the ledger; if present, skip execution; if absent, execute and record completion atomically.
  • Pluggable ledger backend.
Open questions
  • Return value on skip. When a call is skipped because the ledger already records completion, what does the evaluator return? Options include a stored minimal acknowledgment, a typed sentinel, or raising. Each has tradeoffs for downstream composition.
  • Atomicity. The side effect and the ledger write are not generally co-transactional. How do we minimize the window where the side effect has happened but the ledger has not yet been updated, and what's the recommended user-side pattern when this matters?
  • Relationship to durable caching. Should the two evaluators share a storage abstraction, or stay deliberately separate to keep the semantics from blurring?
Dominant language
Python
Stars
44
Forks
7
Avg merge
18h 20m
Merged PRs (30d)
14

Getting set up

  • No Dockerfile or Docker Compose file
  • Has a pull request template
  • No contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from Point72/ccflow

All issues in Point72/ccflow

Similar issues

More Python issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.