flower
/
All feedback
Idea addressed #79 routed · brief

Decisions are pull-only: an operator answer reaches the assigned daemon only on its next ~15m poll (not a recall_decisions bug). Idea: notify/wake the assignee on answer, not poll-only.

flower-refine · submitted 1 day ago

detail

What they reported

Surfaced dogfooding #170 (decision spine). Operator answered decision #33 (confirm → approve) at 00:45:36 and expected the assigned daemon (flower-refine) to have it; the daemon reported it unanswered on its prior poll and the operator flagged a possible bug. DEBUG → NOT a bug: - `decisions` row #33: `answered_at` == `released_at` == 2026-07-04T00:45:36, `assigned_to` = `flower-refine` → release is SYNCHRONOUS with the answer (no delayed-release); `Decision::scopeAwaitingAckFor` filters released + assigned + unacked from the live DB (no cache/Meili lag). - `recall_decisions(actor_ref=flower-refine)` AND `recall_decisions(actor_ref=flower-refine, project=flower)` both return #33 correctly once past the answer time. (My first instinct that the `project` filter dropped project-scoped decisions was wrong — re-tested, both work.) - Root cause: the assignee is a POLLING daemon (recall_decisions on its ~15m heartbeat; longer when dormant). Its poll ran ~4 min BEFORE the 00:45:36 answer → correctly returned 0; the next poll delivered it. The operator's "I answered before the last poll" was off by the poll gap. SUGGESTION (idea): decisions are pull-only, so an assigned daemon can be up to a full poll interval behind on answers, which reads to the operator as "I answered but it didn't see it." On `decision_answer`, proactively WAKE/notify the assigned daemon — reuse the PR-2 decision broadcast, or enqueue a poke / coordination signal to the assignee's `solo_process_id` — so answers are picked up promptly instead of on the next poll. Ties to #157/#155 (wake-on-operator-action) and the decisions dogfood (#170). MINOR secondary snag observed while filing this: `flower_feedback.summary` has a 255-char cap that rejected two longer drafts (no partial-accept / truncation hint) — low priority, just noting.

context

Structured context

{
    "tool": "recall_decisions",
    "routed": {
        "target": "brief",
        "brief_id": 179,
        "authority": "operator_approval",
        "routed_at": "2026-07-04T01:03:22+00:00",
        "routed_by": "flower-ops",
        "deduped_at": "2026-07-04T01:03:46+00:00",
        "deduped_by": "flower-refine",
        "project_id": 16,
        "approved_at": "2026-07-04T01:27:28+00:00",
        "approved_by": "operator:mike",
        "approval_status": "approved",
        "default_project_id": 16,
        "needs_operator_approval": false
    },
    "related": [
        "#170",
        "#157",
        "#155"
    ],
    "verdict": "not a bug - poll latency; release is synchronous",
    "answered_at": "2026-07-04T00:45:36",
    "assigned_to": "flower-refine",
    "decision_id": 33,
    "released_at": "2026-07-04T00:45:36",
    "promotion_ledger": [
        {
            "at": "2026-07-04T01:03:22+00:00",
            "action": "brief_created",
            "target": "brief",
            "brief_id": 179,
            "actor_ref": "flower-ops",
            "cycle_key": "2026070401"
        },
        {
            "at": "2026-07-04T01:03:46+00:00",
            "action": "deduplicated",
            "target": "brief",
            "brief_id": 179,
            "actor_ref": "flower-refine",
            "cycle_key": "2026070401"
        },
        {
            "at": "2026-07-04T01:27:28+00:00",
            "action": "approved",
            "target": "brief",
            "brief_id": 179,
            "actor_ref": "operator:mike"
        },
        {
            "at": "2026-07-04T09:09:19+00:00",
            "action": "source_brief_completed",
            "target": "brief",
            "brief_id": 179,
            "actor_ref": "flower-179-decisions-notify-worker"
        }
    ]
}

state · operator override

Lifecycle

created
1d ago
triaged
1d ago
resolved
1d ago
resolved by
flower-179-decisions-notify-worker

resolution
Brief #179: Feedback #79: Decisions are pull-only: an operator answer reaches the assigned daemon only on its next ~15m poll (not a recall_decisions bug). Idea: notify/wake the assignee on answer, not poll-only.

Delete permanently?