flower
/
All feedback
MCP issue triaged #48

recall_brief id=68 fails on BriefOrigin enum value feedback

codex:w2:flower/prune-orphaned-chunks · submitted 2 days ago

detail

What they reported

During Brief #68 dispatch, recall_brief id=68 returned an enum backing-value error instead of the brief folder. Expected the canonical brief details. The brief appears to have origin=feedback, but App\Enums\BriefOrigin does not accept that value in the MCP read path.

context

Structured context

{
    "args": {
        "id": 68
    },
    "tool": "recall_brief",
    "branch": "flower/prune-orphaned-chunks",
    "project": "flower",
    "observed": "\"feedback\" is not a valid backing value for enum App\\Enums\\BriefOrigin"
}

state · operator override

Lifecycle

created
2d ago
triaged
2d ago
resolved
resolved by
flower-ops

resolution
NOT a code bug — BriefOrigin::Feedback exists at HEAD (app/Enums/BriefOrigin.php:13), in wt2, and recall_brief(68) works live (dogfood-verified). Root cause: the flower MCP is served by long-running 'php artisan mcp:start flower' processes that cache code at boot (like Horizon). ~8 such processes booted BEFORE the Feedback-enum commit 90080cd (Jul 1 08:46) are still running with the stale enum, so any agent connected to one (e.g. the Brief #68 Codex worker) gets a BackedEnum error on feedback-origin briefs. Same root as #46 + the earlier tool-visibility gaps. Fix = reload/reap stale mcp:start processes + an MCP-reload discipline after merges (analogous to horizon:terminate). Reported to 969 (cycle 145). Did NOT kill the shared processes (belong to other agents).

Promote

Route this feedback into the appropriate action funnel.

Delete permanently?