Catalog/P family/P13
Proposed specificationSource-located exemplarH1H3

Log-as-queue loops

Drive work from a durable execution record.

JOIN POINTdurable_work_consumptionRECORD STATUSCandidate · v0.1.0
UML class view for Log-as-queue loops, showing participant roles, received calls, and analytical dependencies
FIG. P13 / UML CLASS VIEW
Object interaction diagram for Log-as-queue loops, showing role collaboration and a numbered message sequence
FIG. P13 / OBJECT INTERACTIONS
Context
New work is represented by durable append-only records.
Trigger
A consumer polls or subscribes to unseen records.
Structure
Event identity, append order, consumer cursor, and acknowledgement.
Effect
Work advances from the log without replaying already completed effects.
Requires
Records have stable identity and consumers retain progress.
Ensures
Each effectful unit has an idempotency or acknowledgement rule.
Invariant
Consumer crash does not erase unacknowledged work.
Violation
Duplicate delivery is deduplicated or documented as at-least-once.

Negative control

An in-memory queue is not log-as-queue.

Permitted variation

SQL log, file log, queue adapter, polling, and projection.

Test obligation

Test crash before ack, duplicate delivery, out-of-order reads, and replay.

Evolution question

Did durable task records become the scheduling substrate?

PROMPT SKETCH
Consume durable work records with stable identity. Claim a record before acting, acknowledge only after the effect is committed, and make retries idempotent.
CODE DESIGN / PYTHON
def consume_one(queue, handler):
    record = queue.claim(timeout=30)
    if record is None:
        return None
    if not queue.is_seen(record.id):
        handler.apply_once(record.id, record.payload)
        queue.mark_seen(record.id)
    queue.ack(record.id)
    return record.id

Illustrative design sketch. The acknowledgement rule, not the transport name, makes the queue durable. This example is a teaching aid, not implementation evidence or a conformance claim.

Join point
durable_work_consumption
Source locator
See the source record.
Lexical cue
(?i)\b(?:event[_-]?log|append[_-]?(?:event|item)|event[_-]?queue|log[_-]?as[_-]?queue)\bFrozen expression, v0.1.0. A match is a retrieval cue, not a confirmed implementation.
Aliases
None
Canonical exemplar
OpenHands/automationopenhands/automation/models.py:222Support: tests/test_scheduler.py:703
Negative control
An in-memory queue is not log-as-queue.

Scope-anchored review. pohe-agent analyze <repo> --pattern P13 anchors the cue to its enclosing declaration and checks a separate operational signature for all four pointcut dimensions. Missing roles and negative-control risks remain visible; a structural match is not E2/E3. Calibration report ↗

Source-located exemplar

A concrete source anchor is available for this proposed record. It is one exemplar, not evidence that all repositories—or every contract field—conform.

Review boundary: this candidate and its specification come from an AI-assisted study. Independent human validation remains open.

ANY-EVIDENCE FAMILY COVERAGE22/36

61.1% of repository families in the frozen panel have at least one current cue, historical cue, or canonical source layer. This is not confirmed prevalence.

Current lexical-cue repositories: 23 / 41
Canonical source anchorOpenHands/automation 3ddfee594d21openhands/automation/models.py:222
Supporting surfacetests/test_scheduler.py:703

Persistent event table doubles as a poller-consumed work queue.

Exploratory retrieval cue Regex / v0.1.0
(?i)\b(?:event[_-]?log|append[_-]?(?:event|item)|event[_-]?queue|log[_-]?as[_-]?queue)\b

This expression is a discovery instrument only. A match is a retrieval cue—not a confirmed implementation, pointcut match, or contract proof.