delete_mission
DestructiveIdempotent
Hard-delete a mission from the queue — silent cleanup only.
Use this only when you want to clear the row without teaching the system
anything: duplicates, accidental scrapes, leads the operator doesn't
want surfaced again but doesn't have an opinion on.
Canonical case: the post is gone by the time you get there — deleted
by the poster, 404'd, removed by mods, or stale beyond your reply
window. The lead wasn't wrong, the opportunity just evaporated.
`delete_mission` is the right tool because there's nothing to learn
from the station — its `rl_weight` stays untouched. Using
`reject_mission` here would unfairly penalise a station for an event
it didn't cause.
When to use this vs `reject_mission`:
- `delete_mission`: queue cleanup, no learning. The scoring weight
for the source feed is untouched. Canonical uses: post deleted,
duplicates, accidental scrapes.
- `reject_mission`: the lead was a bad signal and you want the
system to learn from it. Always prefer this when you have any
opinion on WHY the lead was wrong — the RL loop can only sharpen
if you give it the rejection reason.
Default: if a lead looks like noise but you can categorise WHY (spam,
not relevant, too vague, etc.), reach for `reject_mission` first.
Input Schema
TableJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| mission_id | Yes | The mission's id, from get_missions. |