An attempt can end. The obligation remains.
Start the tutorial · All eight chapters · Choose an API · Documentation
The PyPI distribution name is django-due (pip install django-due).
Python imports remain due. See releasing for the manual release process.
You save a document and queue its publication. The broker is unavailable. Or the worker writes the file and dies before recording success. Or a slow worker returns after a newer revision has already finished.
Due keeps track of what your Django application still owes. It records the obligation in PostgreSQL alongside the product change, uses Celery to attempt it, and recovers work after lost messages and dead workers. Captured ownership tokens and revisions prevent an old worker from settling a newer obligation.
flowchart LR
A[Application transaction] --> B[(PostgreSQL: product + obligation)]
A -. after commit .-> C[Celery worker]
B --> D[Periodic recovery]
D --> C
C --> E[External effect]
E --> F[Fenced local settlement]
F --> B
The message gets work started sooner. The database remembers what remains owed.
When Due is the right tool: strengths, tradeoffs, and alternatives →
The first tutorial uses one deliberately trivial function: sleep, print a greeting, return it. A prepared project supplies setup.
Define the task in examples/hello_due/tasks.py:
import os
from time import sleep
from django.conf import settings
from django.tasks import task
@task(queue_name=settings.CELERY_TASK_DEFAULT_QUEUE)
def greet(name: str, seconds: int = 1) -> str:
print(f"Starting greeting for {name} in process {os.getpid()}", flush=True)
sleep(seconds)
message = f"Hello, {name}!"
print(message, flush=True)
return messageThen submit it from application code or a Django shell:
from examples.hello_due.tasks import greet
result = greet.enqueue("Ada") # Returns immediately; a worker runs the function.
# After the worker finishes:
result.refresh()
print(result.return_value) # Hello, Ada!Submit a job before starting its worker. Read the saved result. Then kill a worker during a slow task, restart it, and let Due recover that same job. Each step shows the code, expected output and the behavior it demonstrates. The runnable example has a test that performs the real worker kill and waits for recurring recovery.
Import production types and startup helpers from due.django.public; common contract and fault
helpers live in due.django.conformance. API choices, imports and file map →
The setup guide explains how to add Due to your Django project. The eight-chapter tutorial then introduces each capability with small operations and observable results:
- Run a task and recover it after worker death.
- Capture input and guard completion with
ReplaySafeEffect. - Keep a mutable external view current with
Projection. - Move or cancel a deadline with
ScheduledAction. - Preserve an uncertain outcome with
DurableExternalOperation. - Resolve it by reading a receipt with
ObservedExternalOperation. - Recover cleanup with
IndependentCompensationand coordinate calls withOwnedDurableWorkCapability. - Compose stages, try completion inline and bind application contract tests.
Then follow Acme Printworks from a Django task to proof publication, portal repair, print ordering and cleanup. Its runnable app includes application contracts. Build those contracts alongside your first native capability: the real commands, provider faults and customer-visible observations make recovery promises testable.
| Failure | Due's response |
|---|---|
| Commit succeeds; queue publication is lost | Recovery finds the work and reserves another delivery. |
| The broker delivers the same message twice | Only the captured owner can execute and settle it. |
| A worker dies or returns after its lease expires | Recovery handles the expiry; stale settlement is rejected. |
| Desired inputs change during execution | Revisions fence old settlement; the current target stays owed. |
| A non-repeatable request times out | Its outcome stays UNKNOWN until correlated evidence resolves it. |
| One recovery row always raises | Other identities progress; the failure is reported and held with backoff. |
| Retries are exhausted | Work remains visibly stopped for an explicit application decision. |
A local lease cannot cancel an external request. Due does not promise exactly-once external execution. Your application defines replay safety, provider idempotency, evidence, and success. Guarantees and limits →
commit product + obligation --> notify worker --> execute --> fenced settlement
| X lost
+------ recurring recovery --------> execute --> fenced settlement
Follow a real obligation through message loss and process death →
Use Due when a business obligation must survive the attempt that tried to fulfill it. Celery remains the transport; your application retains its own models, transactions and product logic.
| What your application owes | Start with |
|---|---|
| A safely repeatable effect | ReplaySafeEffect |
| An external view of changing desired state | Projection |
| An action at a movable or cancellable deadline | ScheduledAction |
| A non-repeatable operation, such as a provider request with an uncertain outcome | DurableExternalOperation |
| Periodic observation of an uncertain operation | ObservedExternalOperation |
| Cleanup owed even if the original worker dies | IndependentCompensation |
| Fenced completion on a row with an existing lifecycle | Completion leases |
The same work-table runtime also supports dependent wakes, discovery from persisted facts, execution gates, continuations, status mirrors and captured inputs. Capability guide and executable examples →
Alpha, Django-backed. Extracted from Gigaverse's work-table primitive; the API may change before 1.0. Only work-table composition is public. Native-table composition is excluded. Verification scope and limits →
Using Django Tasks? Due includes an optional backend for django.tasks.
Keep @task, .enqueue() and TaskResult while adding transactional admission,
crash recovery, delayed tasks and named queues. Setup and guarantees →
Start with your library's migration guide. Each guide covers the benefits of adopting Due, a concrete migration, behavior to preserve, cutover and rollback, and whether a compatibility layer would help. Guides cover Procrastinate, DBOS, RQ, Django Tasks, Celery and the other Python libraries in the background-work ecosystem overview.
Requires Python 3.14, PostgreSQL and a Django 6 application. Celery needs a broker and a running worker plus a recurring recovery scheduler (normally Celery Beat). The integration suite uses PostgreSQL 17 and Redis 7.
Install the published package and commit the resolved version in your lockfile:
uv add 'django-due[redis]'The documentation under latest follows main. Check your installed version
against the release notes before using an API added after that release.
Use the task tutorial and its prepared example. They use source to include the consolidated imports added after 0.10.0. For an existing application, follow the Django Tasks reference or native integration reference. Both need registration in every process, workers and recurring recovery.
This quickstart runs the minimal document-publication application. The separate Books application adapts Procrastinate’s Django books demo into a Due workflow and documents its upstream provenance.
git clone https://github.com/gigaverse-app/due.git
cd due
uv sync --all-packages --locked
docker compose up -d
export DJANGO_SETTINGS_MODULE=examples.settings
uv run python -m django migrate
# Separate terminals, with the same settings:
uv run celery -A examples.celery_app:app worker --loglevel=INFO -Q due
uv run celery -A examples.celery_app:app beat --loglevel=INFOCreate a document from another terminal:
DJANGO_SETTINGS_MODULE=examples.settings uv run python -m django shell -c \
'from examples.documents.models import Document; from examples.documents.effects import request_publication; document = Document.objects.create(); print(request_publication(document.pk, "Hello from Due").pk)'The worker writes an immutable revision object under /tmp/due-documents and
publishes its key on the document row. Configure DUE_DATABASE_URL,
DUE_BROKER_URL, DUE_OUTPUT_DIR and DUE_QUEUE as needed. Compose credentials
are for local development only; both service ports bind to localhost.
For a browser application with two independently recoverable stages, run the books indexing demo. See the example catalog for setup and contribution conventions.
With the local services running:
uv run pytest integration_tests/integration/test_celery_worker.py -vThis test commits a document and its publication obligation while withholding the initial notification. It then starts a separate Celery prefork worker, sends the recovery task through Redis, and checks the file and product state in PostgreSQL. Read the complete failure history.
For application-bound recovery, replay, revision, admission and real process-death checks:
uv run pytest integration_tests/conformance -p due.django.conformance.reporting \
--due-work-summary --due-work-profile-report=profiles.json --durable-work-report=effects.jsonpytest-obligation generates
the applicable tests from a contract bound to Due's actual coordinator. CI
requires executed passing evidence for the claimed profiles; an empty or filtered
report fails. These proofs cover the bound example, not arbitrary application
callbacks. Enroll your own capability with effect_contract_suite and
EffectExamples: authoring guide,
API and module map,
executable example,
verification scope.
uv run python -m django due_status
uv run python -m django due_status publish_document --limit 10The read-only command reports exhausted, terminal-failed and unknown work, unresolved attempts, and deferred recovery identities. It never authorizes a replay. Operations and monitoring →
Due's guarantees are checked the same way an adopter checks theirs, and so is its code.
Every week CI runs all of Due's conformance suites on main, the library's and the example applications',
with pytest-obligation: lost messages, dead workers, stale
workers and retries, each against a real PostgreSQL. This is that run's report, kept current by a pull request
whenever the evidence changes.
Other pytest tests and workflow steps are not included in these counts.
Application inventory and skipped tests
17 applications with results · 0 applications not run Checks skipped: 0.
Application inventory was not supplied; uncollected suites cannot be listed.
All collected applications, most actionable first. Expand the evidence below for reasons and tickets.
| Application | Passed | Failed | Blocked | Gaps | Rejected |
|---|---|---|---|---|---|
| index_book | 48 | 0 | 0 | 0 | 0 |
| publish_book | 43 | 0 | 0 | 0 | 0 |
| project_catalog | 54 | 0 | 0 | 0 | 0 |
| Due replay-safe work table | 87 | 0 | 0 | 0 | 0 |
| celery: a worker runs 'publish_document' through Celery | 1 | 0 | 0 | 0 | 0 |
| publish_document | 50 | 0 | 0 | 0 | 0 |
| calculate_number | 49 | 0 | 0 | 0 | 0 |
| print_order | 49 | 0 | 0 | 0 | 0 |
| publish_at_deadline | 47 | 0 | 0 | 0 | 0 |
| checkout_order | 55 | 0 | 0 | 0 | 0 |
| uuid_work_test | 46 | 0 | 0 | 0 | 0 |
| composed_inline_chunk_self_test | 117 | 0 | 0 | 0 | 0 |
| composed_chunk_self_test | 117 | 0 | 0 | 0 | 0 |
| batch_self_test | 106 | 0 | 0 | 0 | 0 |
| inline_chunk_self_test | 114 | 0 | 0 | 0 | 0 |
| member_sync_self_test | 43 | 0 | 0 | 0 | 0 |
| chunk_self_test | 106 | 0 | 0 | 0 | 0 |
index_book · evidence and decisions
Contract suite: integration_tests/conformance/test_book_contracts.py:6
⚪ Deliberate exclusions
- Uncertain outcomes are handled (C) · Not applicable (application decision). Application reason: Replay-safe mode requires the separately generated actual external replay proof.
- Results eventually settle correctly (E) · Not applicable (application decision). Application reason: Indexing captures the submission once; operator retry preserves that input and its identity.
- Owed work is discovered from stored facts (F) · Not applicable (application decision). Application reason: No canonical discovery is registered.
- Execution respects its gate (G) · Not applicable (application decision). Application reason: The production capability has no execution gate.
These are scope decisions, not demonstrated defects. Review their reasons when the application changes.
Hypothesis · No generated scenario bindings collected
No optional schedule-exploration cases were collected for this suite. Other Hypothesis use inside application callbacks is not assessed here.
🟢 6 supported guarantees
- Unfinished work gets recovered
- Worker ownership is bounded
- Needed records are retained
- Repeating work is harmless
- Intent and work are saved together
- Retries have a limit
Suite (application code): integration_tests.conformance.test_book_contracts.TestBookIndexing
publish_book · evidence and decisions
Contract suite: integration_tests/conformance/test_book_contracts.py:11
⚪ Deliberate exclusions
- Uncertain outcomes are handled (C) · Not applicable (application decision). Application reason: Replay-safe mode requires the separately generated actual external replay proof.
- Results eventually settle correctly (E) · Not applicable (application decision). Application reason: Publication captures the upstream result key; later metadata and repeated settlement cannot replace it.
- Owed work is discovered from stored facts (F) · Not applicable (application decision). Application reason: No canonical discovery is registered.
- Execution respects its gate (G) · Not applicable (application decision). Application reason: The production capability has no execution gate.
- Intent and work are saved together (I) · Not applicable (application decision). Application reason: Publication admission writes one successor row; the upstream handoff is covered by index_book process histories and the interrupted-settlement journey.
These are scope decisions, not demonstrated defects. Review their reasons when the application changes.
Hypothesis · No generated scenario bindings collected
No optional schedule-exploration cases were collected for this suite. Other Hypothesis use inside application callbacks is not assessed here.
🟢 5 supported guarantees
- Unfinished work gets recovered
- Worker ownership is bounded
- Needed records are retained
- Repeating work is harmless
- Retries have a limit
Suite (application code): integration_tests.conformance.test_book_contracts.TestBookPublication
project_catalog · evidence and decisions
Contract suite: integration_tests/conformance/test_catalog_contract.py:10
⚪ Deliberate exclusions
- Uncertain outcomes are handled (C) · Not applicable (application decision). Application reason: Replay-safe mode requires the separately generated actual external replay proof.
- Results eventually settle correctly (E) / IN_FLIGHT · Not applicable (application decision). Application reason: This catalog overwrites one provider key; late-write repair and captured revisions own convergence, not a monotonic merge or dependency gate.
- Results eventually settle correctly (E) / EVIDENCE_CONFLUENCE · Not applicable (application decision). Application reason: This catalog overwrites one provider key; late-write repair and captured revisions own convergence, not a monotonic merge or dependency gate.
- Owed work is discovered from stored facts (F) · Not applicable (application decision). Application reason: No canonical discovery is registered.
- Execution respects its gate (G) · Not applicable (application decision). Application reason: The production capability has no execution gate.
These are scope decisions, not demonstrated defects. Review their reasons when the application changes.
Hypothesis · No generated scenario bindings collected
No optional schedule-exploration cases were collected for this suite. Other Hypothesis use inside application callbacks is not assessed here.
🟢 7 supported guarantees
- Unfinished work gets recovered
- Worker ownership is bounded
- Needed records are retained
- Results eventually settle correctly
- Repeating work is harmless
- Intent and work are saved together
- Retries have a limit
Suite (application code): integration_tests.conformance.test_catalog_contract.TestCatalogProjection
Due replay-safe work table · evidence and decisions
Contract contract setup: integration_tests/conformance/test_contract.py:14
⚪ Deliberate exclusions
- Uncertain outcomes are handled (C) · Not applicable (application decision). Application reason: This example is replay-safe; evidence-required operations have their own regression tests.
- Results eventually settle correctly (E) · Not applicable (application decision). Application reason: This example has an immutable target; projection revision tests exercise mutable targets.
- Owed work is discovered from stored facts (F) · Not applicable (application decision). Application reason: This example admits explicit obligations and declares no fact-derived discovery.
- Execution respects its gate (G) · Not applicable (application decision). Application reason: This example has no prerequisite gate; eligibility has separate regression tests.
- Repeating work is harmless (H) · Not applicable (application decision). Application reason: This example's external call returns a value without a remote mutation.
These are scope decisions, not demonstrated defects. Review their reasons when the application changes.
Hypothesis · No generated scenario bindings collected
No optional schedule-exploration cases were collected for this suite. Other Hypothesis use inside application callbacks is not assessed here.
🟢 5 supported guarantees
- Unfinished work gets recovered
- Worker ownership is bounded
- Needed records are retained
- Intent and work are saved together
- Retries have a limit
Suite (application code): integration_tests.conformance.test_contract.TestWorkTable
celery: a worker runs 'publish_document' through Celery · evidence and decisions
Contract contract setup: integration_tests/conformance/test_document_celery_worker.py:62
⚪ Deliberate exclusions
- Unfinished work gets recovered (A) · Not claimed by application. Application reason: what the worker loses is recovered by Due's recovery of 'publish_document', whose own contract proves its recovery; these histories run it after the worker restarts and check that every failure converges
- Worker ownership is bounded (B) · Not claimed by application. Application reason: a task's lease is the broker's visibility timeout or connection, not a fenced claim Celery can check
- Uncertain outcomes are handled (C) · Not claimed by application. Application reason: with task_acks_late a task whose worker died may run again; whether it reached its service is its own
- Needed records are retained (D) · Not applicable (application decision). Application reason: stored results are the record of settled work, not work still owed
- Results eventually settle correctly (E) · Not applicable (application decision). Application reason: one worker settles each delivery; no two results race to write it
- Owed work is discovered from stored facts (F) · Not applicable (application decision). Application reason: the obligation is the message itself, not a fact derived from product state
- Execution respects its gate (G) · Not claimed by application. Application reason: Celery's worker contract has no application readiness predicate; dependencies and product gates need their own ExecutionGate binding, including release with its notification lost.
- Repeating work is harmless (H) · Not claimed by application. Application reason: a task can run more than once (with task_acks_late, a redelivery after its worker was lost), so rerunning it must be safe, but that is a property of each task's function, not of Celery
- Intent and work are saved together (I) · Not claimed by application. Application reason: Celery's worker receives already admitted work; it cannot make an application's product transaction atomic with enqueue. Bind Profile I on the application's command contract.
- Retries have a limit (J) · Not claimed by application. Application reason: a task's retries are its own (self.retry, autoretry_for); a redelivery after a lost worker is not counted as one
These are scope decisions, not demonstrated defects. Review their reasons when the application changes.
Hypothesis · No generated scenario bindings collected
No optional schedule-exploration cases were collected for this suite. Other Hypothesis use inside application callbacks is not assessed here.
⚪ 0 supported guarantees
Suite (application code): integration_tests.conformance.test_document_celery_worker.TestPublicationThroughCelery
publish_document · evidence and decisions
Contract suite: integration_tests/conformance/test_document_contract.py:11
⚪ Deliberate exclusions
- Uncertain outcomes are handled (C) · Not applicable (application decision). Application reason: Replay-safe mode requires the separately generated actual external replay proof.
- Results eventually settle correctly (E) / MONOTONIC_RESULTS · Not applicable (application decision). Application reason: File revisions have separate immutable keys; only a fenced pointer is settled.
- Results eventually settle correctly (E) / IN_FLIGHT · Not applicable (application decision). Application reason: File revisions have separate immutable keys; only a fenced pointer is settled.
- Results eventually settle correctly (E) / EVIDENCE_CONFLUENCE · Not applicable (application decision). Application reason: File revisions have separate immutable keys; only a fenced pointer is settled.
- Owed work is discovered from stored facts (F) · Not applicable (application decision). Application reason: No canonical discovery is registered.
- Execution respects its gate (G) · Not applicable (application decision). Application reason: The production capability has no execution gate.
These are scope decisions, not demonstrated defects. Review their reasons when the application changes.
Hypothesis · No generated scenario bindings collected
No optional schedule-exploration cases were collected for this suite. Other Hypothesis use inside application callbacks is not assessed here.
🟢 7 supported guarantees
- Unfinished work gets recovered
- Worker ownership is bounded
- Needed records are retained
- Results eventually settle correctly
- Repeating work is harmless
- Intent and work are saved together
- Retries have a limit
Suite (application code): integration_tests.conformance.test_document_contract.TestDocumentPublication
calculate_number · evidence and decisions
Contract suite: integration_tests/conformance/test_number_contract.py:18
⚪ Deliberate exclusions
- Uncertain outcomes are handled (C) · Not applicable (application decision). Application reason: Replay-safe mode requires the separately generated actual external replay proof.
- Results eventually settle correctly (E) / MONOTONIC_RESULTS · Not applicable (application decision). Application reason: Arithmetic has no mutable remote state; only the fenced product result is published.
- Results eventually settle correctly (E) / IN_FLIGHT · Not applicable (application decision). Application reason: Arithmetic has no mutable remote state; only the fenced product result is published.
- Results eventually settle correctly (E) / EVIDENCE_CONFLUENCE · Not applicable (application decision). Application reason: Arithmetic has no mutable remote state; only the fenced product result is published.
- Owed work is discovered from stored facts (F) · Not applicable (application decision). Application reason: No canonical discovery is registered.
- Execution respects its gate (G) · Not applicable (application decision). Application reason: The production capability has no execution gate.
These are scope decisions, not demonstrated defects. Review their reasons when the application changes.
Hypothesis · No generated scenario bindings collected
No optional schedule-exploration cases were collected for this suite. Other Hypothesis use inside application callbacks is not assessed here.
🟢 7 supported guarantees
- Unfinished work gets recovered
- Worker ownership is bounded
- Needed records are retained
- Results eventually settle correctly
- Repeating work is harmless
- Intent and work are saved together
- Retries have a limit
Suite (application code): integration_tests.conformance.test_number_contract.TestNumberCalculation
print_order · evidence and decisions
Contract suite: integration_tests/conformance/test_order_contract.py:6
⚪ Deliberate exclusions
- Needed records are retained (D) · Not applicable (application decision). Application reason: Registered policy retains work and evidence indefinitely.
- Results eventually settle correctly (E) · Not applicable (application decision). Application reason: A submitted print order is immutable and cannot become a different physical order.
- Owed work is discovered from stored facts (F) · Not applicable (application decision). Application reason: No canonical discovery is registered.
- Execution respects its gate (G) · Not applicable (application decision). Application reason: The production capability has no execution gate.
- Repeating work is harmless (H) · Not claimed by application. Application reason: Production requires definite provider evidence; another call can duplicate an occurrence.
These are scope decisions, not demonstrated defects. Review their reasons when the application changes.
Hypothesis · No generated scenario bindings collected
No optional schedule-exploration cases were collected for this suite. Other Hypothesis use inside application callbacks is not assessed here.
🟢 5 supported guarantees
- Unfinished work gets recovered
- Worker ownership is bounded
- Uncertain outcomes are handled
- Intent and work are saved together
- Retries have a limit
Suite (application code): integration_tests.conformance.test_order_contract.TestPrintOrder
publish_at_deadline · evidence and decisions
Contract suite: integration_tests/conformance/test_scheduled_contract.py:6
⚪ Deliberate exclusions
- Uncertain outcomes are handled (C) · Not applicable (application decision). Application reason: Replay-safe mode requires the separately generated actual external replay proof.
- Needed records are retained (D) · Not applicable (application decision). Application reason: Registered policy retains work and evidence indefinitely.
- Results eventually settle correctly (E) / MONOTONIC_RESULTS · Not applicable (application decision). Application reason: A pending deadline is replaced or cancelled; immutable revision files and a fenced product pointer need no merge or dependency gate.
- Results eventually settle correctly (E) / IN_FLIGHT · Not applicable (application decision). Application reason: A pending deadline is replaced or cancelled; immutable revision files and a fenced product pointer need no merge or dependency gate.
- Results eventually settle correctly (E) / EVIDENCE_CONFLUENCE · Not applicable (application decision). Application reason: A pending deadline is replaced or cancelled; immutable revision files and a fenced product pointer need no merge or dependency gate.
- Owed work is discovered from stored facts (F) · Not applicable (application decision). Application reason: No canonical discovery is registered.
- Execution respects its gate (G) · Not applicable (application decision). Application reason: The production capability has no execution gate.
These are scope decisions, not demonstrated defects. Review their reasons when the application changes.
Hypothesis · No generated scenario bindings collected
No optional schedule-exploration cases were collected for this suite. Other Hypothesis use inside application callbacks is not assessed here.
🟢 6 supported guarantees
- Unfinished work gets recovered
- Worker ownership is bounded
- Results eventually settle correctly
- Repeating work is harmless
- Intent and work are saved together
- Retries have a limit
Suite (application code): integration_tests.conformance.test_scheduled_contract.TestScheduledPublication
checkout_order · evidence and decisions
Contract suite: integration_tests/conformance/test_widget_contract.py:6
⚪ Deliberate exclusions
- Uncertain outcomes are handled (C) · Not applicable (application decision). Application reason: Replay-safe mode requires the separately generated actual external replay proof.
- Needed records are retained (D) · Not applicable (application decision). Application reason: Registered policy retains work and evidence indefinitely.
- Results eventually settle correctly (E) · Not applicable (application decision). Application reason: A checkout captures one submission key; catalog edits and retries never replace it.
- Owed work is discovered from stored facts (F) · Not applicable (application decision). Application reason: No canonical discovery is registered.
- Repeating work is harmless (H) · Not applicable (application decision). Application reason: DatabaseEffect commits its callback with the work fence; the separate delivery replay proof checks that boundary, not raw external-call idempotency.
These are scope decisions, not demonstrated defects. Review their reasons when the application changes.
Hypothesis · No generated scenario bindings collected
No optional schedule-exploration cases were collected for this suite. Other Hypothesis use inside application callbacks is not assessed here.
🟢 5 supported guarantees
- Unfinished work gets recovered
- Worker ownership is bounded
- Execution respects its gate
- Intent and work are saved together
- Retries have a limit
Suite (application code): integration_tests.conformance.test_widget_contract.TestWidgetCheckout
uuid_work_test · evidence and decisions
Contract suite: package/tests/uuid_work/test_contract.py:86
⚪ Deliberate exclusions
- Needed records are retained (D) · Not applicable (application decision). Application reason: Registered policy retains work and evidence indefinitely.
- Results eventually settle correctly (E) · Not applicable (application decision). Application reason: The publication captures its payload once; changing owner fields cannot revise that immutable occurrence.
- Owed work is discovered from stored facts (F) · Not applicable (application decision). Application reason: No canonical discovery is registered.
- Execution respects its gate (G) · Not applicable (application decision). Application reason: The production capability has no execution gate.
- Repeating work is harmless (H) · Not claimed by application. Application reason: Production requires definite provider evidence; another call can duplicate an occurrence.
- Intent and work are saved together (I) · Not applicable (application decision). Application reason: The owner already exists; admission commits one new work row atomically.
These are scope decisions, not demonstrated defects. Review their reasons when the application changes.
Hypothesis · No generated scenario bindings collected
No optional schedule-exploration cases were collected for this suite. Other Hypothesis use inside application callbacks is not assessed here.
🟢 4 supported guarantees
- Unfinished work gets recovered
- Worker ownership is bounded
- Uncertain outcomes are handled
- Retries have a limit
Suite (application code): test_contract.TestUUIDOperationContract
composed_inline_chunk_self_test · evidence and decisions
Contract suite: package/tests/bulk/test_composed_work_contract.py:33
⚪ Deliberate exclusions
- Needed records are retained (D) · Not applicable (application decision). Application reason: Registered policy retains work and evidence indefinitely.
- Results eventually settle correctly (E) / STALE_SNAPSHOTS · Not applicable (application decision). Application reason: A fixed batch refuses new inputs; no desired revision can supersede its captured membership.
- Results eventually settle correctly (E) / IN_FLIGHT · Not applicable (application decision). Application reason: This immutable cohort has no competing desired-state writer; receipt actors are covered by evidence confluence.
- Owed work is discovered from stored facts (F) · Not applicable (application decision). Application reason: No canonical discovery is registered.
- Execution respects its gate (G) · Not applicable (application decision). Application reason: The production capability has no execution gate.
- Repeating work is harmless (H) · Not claimed by application. Application reason: Production requires definite provider evidence; another call can duplicate an occurrence.
- Intent and work are saved together (I) · Not applicable (application decision). Application reason: The producer inserts business intent and coordination in one row; the rollback control proves they cannot split.
These are scope decisions, not demonstrated defects. Review their reasons when the application changes.
Hypothesis · Not run
Generated schedule exploration uses the application's scenario bindings.
- Application scenario
bulk-partial-receipts: Disabled or filtered out - Application scenario
bulk-receipts-across-subset-retry: Disabled or filtered out
These counts are scenario checks, not generated examples. Example counts, shrinking statistics and replay histories are not recorded in this report; inspect the pytest log for a failing history.
🟢 5 supported guarantees
- Unfinished work gets recovered
- Worker ownership is bounded
- Uncertain outcomes are handled
- Results eventually settle correctly
- Retries have a limit
Suite (application code): tests.bulk.test_composed_work_contract.TestComposedInlineReceiptContract
composed_chunk_self_test · evidence and decisions
Contract suite: package/tests/bulk/test_composed_work_contract.py:18
⚪ Deliberate exclusions
- Needed records are retained (D) · Not applicable (application decision). Application reason: Registered policy retains work and evidence indefinitely.
- Results eventually settle correctly (E) / STALE_SNAPSHOTS · Not applicable (application decision). Application reason: A fixed batch refuses new inputs; no desired revision can supersede its captured membership.
- Results eventually settle correctly (E) / IN_FLIGHT · Not applicable (application decision). Application reason: This immutable cohort has no competing desired-state writer; receipt actors are covered by evidence confluence.
- Owed work is discovered from stored facts (F) · Not applicable (application decision). Application reason: No canonical discovery is registered.
- Execution respects its gate (G) · Not applicable (application decision). Application reason: The production capability has no execution gate.
- Repeating work is harmless (H) · Not claimed by application. Application reason: Production requires definite provider evidence; another call can duplicate an occurrence.
- Intent and work are saved together (I) · Not applicable (application decision). Application reason: The producer inserts business intent and coordination in one row; the rollback control proves they cannot split.
These are scope decisions, not demonstrated defects. Review their reasons when the application changes.
Hypothesis · Not run
Generated schedule exploration uses the application's scenario bindings.
- Application scenario
bulk-partial-receipts: Disabled or filtered out - Application scenario
bulk-receipts-across-subset-retry: Disabled or filtered out
These counts are scenario checks, not generated examples. Example counts, shrinking statistics and replay histories are not recorded in this report; inspect the pytest log for a failing history.
🟢 5 supported guarantees
- Unfinished work gets recovered
- Worker ownership is bounded
- Uncertain outcomes are handled
- Results eventually settle correctly
- Retries have a limit
Suite (application code): tests.bulk.test_composed_work_contract.TestComposedSeparateReceiptContract
batch_self_test · evidence and decisions
Contract suite: package/tests/bulk/test_contract.py:116
⚪ Deliberate exclusions
- Needed records are retained (D) · Not applicable (application decision). Application reason: Registered policy retains work and evidence indefinitely.
- Results eventually settle correctly (E) / STALE_SNAPSHOTS · Not applicable (application decision). Application reason: A fixed batch refuses new inputs; no desired revision can supersede its captured membership.
- Results eventually settle correctly (E) / IN_FLIGHT · Not applicable (application decision). Application reason: This immutable cohort has no competing desired-state writer; receipt actors are covered by evidence confluence.
- Owed work is discovered from stored facts (F) · Not applicable (application decision). Application reason: No canonical discovery is registered.
- Execution respects its gate (G) · Not applicable (application decision). Application reason: The production capability has no execution gate.
- Repeating work is harmless (H) · Not claimed by application. Application reason: Production requires definite provider evidence; another call can duplicate an occurrence.
- Intent and work are saved together (I) · Not applicable (application decision). Application reason: The owner exists before admission; admission commits one new work row atomically.
These are scope decisions, not demonstrated defects. Review their reasons when the application changes.
Hypothesis · Not run
Generated schedule exploration uses the application's scenario bindings.
- Application scenario
bulk-partial-receipts: Disabled or filtered out - Application scenario
bulk-receipts-across-subset-retry: Disabled or filtered out
These counts are scenario checks, not generated examples. Example counts, shrinking statistics and replay histories are not recorded in this report; inspect the pytest log for a failing history.
🟢 5 supported guarantees
- Unfinished work gets recovered
- Worker ownership is bounded
- Uncertain outcomes are handled
- Results eventually settle correctly
- Retries have a limit
Suite (application code): tests.bulk.test_contract.TestBulkOperationContract
inline_chunk_self_test · evidence and decisions
Contract suite: package/tests/bulk/test_inline_work_contract.py:29
⚪ Deliberate exclusions
- Needed records are retained (D) · Not applicable (application decision). Application reason: Registered policy retains work and evidence indefinitely.
- Results eventually settle correctly (E) / STALE_SNAPSHOTS · Not applicable (application decision). Application reason: A fixed batch refuses new inputs; no desired revision can supersede its captured membership.
- Results eventually settle correctly (E) / IN_FLIGHT · Not applicable (application decision). Application reason: This immutable cohort has no competing desired-state writer; receipt actors are covered by evidence confluence.
- Owed work is discovered from stored facts (F) · Not applicable (application decision). Application reason: No canonical discovery is registered.
- Execution respects its gate (G) · Not applicable (application decision). Application reason: The production capability has no execution gate.
- Repeating work is harmless (H) · Not claimed by application. Application reason: Production requires definite provider evidence; another call can duplicate an occurrence.
- Intent and work are saved together (I) · Not applicable (application decision). Application reason: The producer inserts business intent and coordination in one row; the rollback control proves they cannot split.
These are scope decisions, not demonstrated defects. Review their reasons when the application changes.
Hypothesis · Not run
Generated schedule exploration uses the application's scenario bindings.
- Application scenario
bulk-partial-receipts: Disabled or filtered out - Application scenario
bulk-receipts-across-subset-retry: Disabled or filtered out
These counts are scenario checks, not generated examples. Example counts, shrinking statistics and replay histories are not recorded in this report; inspect the pytest log for a failing history.
🟢 5 supported guarantees
- Unfinished work gets recovered
- Worker ownership is bounded
- Uncertain outcomes are handled
- Results eventually settle correctly
- Retries have a limit
Suite (application code): tests.bulk.test_inline_work_contract.TestInlineOperationContract
member_sync_self_test · evidence and decisions
Contract suite: package/tests/bulk/test_replay_safe_contract.py:121
⚪ Deliberate exclusions
- Uncertain outcomes are handled (C) · Not applicable (application decision). Application reason: Replay-safe mode requires the separately generated actual external replay proof.
- Needed records are retained (D) · Not applicable (application decision). Application reason: Registered policy retains work and evidence indefinitely.
- Results eventually settle correctly (E) · Not applicable (application decision). Application reason: A cohort's member keys are captured at admission; a later sync admits a new cohort.
- Owed work is discovered from stored facts (F) · Not applicable (application decision). Application reason: No canonical discovery is registered.
- Execution respects its gate (G) · Not applicable (application decision). Application reason: The production capability has no execution gate.
- Intent and work are saved together (I) · Not applicable (application decision). Application reason: The owner exists before admission; admission commits one new work row atomically.
These are scope decisions, not demonstrated defects. Review their reasons when the application changes.
Hypothesis · No generated scenario bindings collected
No optional schedule-exploration cases were collected for this suite. Other Hypothesis use inside application callbacks is not assessed here.
🟢 4 supported guarantees
- Unfinished work gets recovered
- Worker ownership is bounded
- Repeating work is harmless
- Retries have a limit
Suite (application code): tests.bulk.test_replay_safe_contract.TestReplaySafeBulkContract
chunk_self_test · evidence and decisions
Contract suite: package/tests/bulk/test_self_work_contract.py:13
⚪ Deliberate exclusions
- Needed records are retained (D) · Not applicable (application decision). Application reason: Registered policy retains work and evidence indefinitely.
- Results eventually settle correctly (E) / STALE_SNAPSHOTS · Not applicable (application decision). Application reason: A fixed batch refuses new inputs; no desired revision can supersede its captured membership.
- Results eventually settle correctly (E) / IN_FLIGHT · Not applicable (application decision). Application reason: This immutable cohort has no competing desired-state writer; receipt actors are covered by evidence confluence.
- Owed work is discovered from stored facts (F) · Not applicable (application decision). Application reason: No canonical discovery is registered.
- Execution respects its gate (G) · Not applicable (application decision). Application reason: The production capability has no execution gate.
- Repeating work is harmless (H) · Not claimed by application. Application reason: Production requires definite provider evidence; another call can duplicate an occurrence.
- Intent and work are saved together (I) · Not applicable (application decision). Application reason: The producer inserts business intent and coordination in one row; the rollback control proves they cannot split.
These are scope decisions, not demonstrated defects. Review their reasons when the application changes.
Hypothesis · Not run
Generated schedule exploration uses the application's scenario bindings.
- Application scenario
bulk-partial-receipts: Disabled or filtered out - Application scenario
bulk-receipts-across-subset-retry: Disabled or filtered out
These counts are scenario checks, not generated examples. Example counts, shrinking statistics and replay histories are not recorded in this report; inspect the pytest log for a failing history.
🟢 5 supported guarantees
- Unfinished work gets recovered
- Worker ownership is bounded
- Uncertain outcomes are handled
- Results eventually settle correctly
- Retries have a limit
Suite (application code): tests.bulk.test_self_work_contract.TestSelfContainedOperationContract
What do these numbers mean?
- Failures: an executed assertion failed unexpectedly or was an application-declared expected failure. Expected failures still permit successful CI; the visible breakdown distinguishes them.
- Rejected bindings: repair the connection to production code; these checks provide no supporting evidence.
- Blocked checks: checks could not establish a result, including missing execution, setup/cleanup errors, binding-debt or unclassified expected failures, and unexpected passes requiring declaration review.
- Coverage gaps: guarantees not assessed, missing scenarios, or with declared gaps. Each affected guarantee counts once. Deliberate exclusions are shown separately.
Pass/fail/blocked/rejected counts partition unique checks. Gaps count guarantees, not extra tests. Declined and not-applicable declarations remain separate and do not establish passing coverage. Graphics color contract results: passing checks and zero issues are green, failures and rejected bindings are red, blocked checks and gaps are amber. Missing reports never show green zeroes. The workflow status above is separate from these contract counts.
Elapsed time covers the pytest session. Summed check time includes setup, execution and cleanup; parallel work overlaps. Application totals include discovered declarations and reported suites. Skipped checks count known deselections and explicit pytest skips; incomplete selected checks are not skips. Uncollected applications have unknown check counts. Zero recorded outcomes do not certify passing coverage.
Application names, quoted reasons and diagnostic values come from application code. Guarantee labels come from pytest-obligation. Results cover collected suites only; passing checks do not rate every test's quality.
Test step (reported): success
Source: weekly complete CI run on main
A pre-commit hook and the required dry-lint check block code that re-implements a function Due already has.
Duplication that predates adoption is an accepted backlog that only shrinks: the weekly audit records each
pair a refactor removes. See CONTRIBUTING.md.
Reviewed duplication debt · Counts from the committed baselines.
| Accepted pairs | Remaining | Retired | Dismissed |
|---|---|---|---|
| Functions | 18 | 11 | 0 |
| Models | Not initialized | — | — |
Accepted backlog · Weekly audit
Retired means a side was removed, or (functions only) the judge now finds the pair separate. It is not a count of refactors. Dismissals stay separate; an uninitialized model baseline is unknown.
| You want to… | Read |
|---|---|
| Run a task and recover it after worker failure | First task tutorial |
| Learn each capability step by step | All eight tutorial chapters |
| Configure Due in a Django project | Setup guide |
| Learn native admission and completion hooks | Native work lesson |
| Find the high-level API and imports | API guide and file map |
| Add richer product guarantees | Printworks tutorial |
| Decide whether Due fits your application | Strengths and tradeoffs, alternatives |
| Integrate the runtime | Django and Celery wiring, capabilities |
| Move an existing application onto Due | Migration settings and stable wire names, library migration guides |
| Prove your application's obligations | Conformance walkthrough, checked immutable inputs, executable document adopter |
| Find an interface or understand scope | Conformance API, field reference and module boundaries, provider-seam factories |
| Understand a passing result | Verification scope, architecture and limits |
| Operate and recover work | Operations, failed-tick evidence |
| Edit the library inside an adopter checkout | Package ownership and subtree development |
| Migrate the backend harness | Backend adoption and ownership |
uv sync --all-packages --locked
uv run pre-commit install
uv run pre-commit run --all-files
docker compose up -d --wait
(cd package && ../.venv/bin/python -m pytest --due-work-check-fixtures)
uv run --no-sync pytest --due-work-require-assessed --due-work-profile-report=profiles.json
uv build --project package --out-dir distPre-commit uses the Ruff and Pyrefly versions in uv.lock. CI also tests the
minimum Django version, checks migrations, and installs the wheel without test
dependencies. See CONTRIBUTING.md for the complete workflow.
Integration · Architecture · Conformance · Recovery walkthrough · Verification · Apache-2.0
Pull requests run only the test lanes a change can affect, planned by CI-esta from the workflows, behind CI-esta's required-check gates; every run gets a CI-esta timing report. Due's conformance lane runs the pytest-obligation tests generated from its contracts.
See the CI toolkit integration for lane selection, validated environment caches, required gates and real dependency critical-path reports.