---
title: Auto-cancel queued waivers when drop player is involved in another transaction
type: task
status: draft
description: >-
  When a team's pending waiver claim includes a drop/release player, automatically cancel that
  waiver if the same player is subsequently involved in any other transaction (manual release,
  trade, activation, etc.). Also fixes a silent-skip in waiver processing that today lets the add
  proceed without performing the intended drop.
base_uri: user:task/league/waiver-auto-cancel-on-drop-transaction.md
created_at: '2026-04-29T17:33:43.419Z'
entity_id: 10e51f8e-c420-4dfd-9b0e-24ac9424e90f
owner_identity_uri: █████████████████████████
priority: Low
public_read: true
relations:
  - relates [[user:repository/active/league]]
  - relates [[user:task/league/waiver-failure-reason-codes.md]]
tags:
  - user:tag/league-xo-football.md
  - user:tag/software-task.md
updated_at: '2026-04-29T17:33:43.419Z'
visibility_analyzed_at: '2026-11-05T23:50:36.981Z'
---

When a team's pending waiver claim includes a drop/release player, the pending claim becomes invalid if that drop player is subsequently removed from the team's roster via another transaction (manual release, trade, activation, etc.). Today the platform has two related gaps.

## Gap 1: No proactive cancellation in transaction paths

Release, trade acceptance, and other transaction paths never sweep `waiver_releases` to cancel pending waivers that reference the moved player as a drop target.

- `api/routes/teams/release.mjs:164-174` and `libs-server/process-release.mjs` -- no `waiver_releases` sweep after release.
- `api/routes/leagues/trade.mjs:795-1021` (accept handler) -- cancels conflicting trades, poaching claims, RFA bids, and removes players from cutlists, but performs no queries against `waivers` / `waiver_releases`.
- The waiver claim stays "pending" in an invalid state until processing time.

## Gap 2: Silent skip at processing time

`libs-server/submit-acquisition.mjs:162-168` silently skips a missing drop player (`if (!releasePlayer) { continue }`) rather than failing cleanly. The commented-out `throw new Error('invalid release')` in the same block reveals this was intentionally softened. The waiver may then process and add the player without performing the intended drop -- if the team is not over its roster limit, the add silently succeeds without clearing the expected slot. The waiver does not record a clean failure reason and the user is not notified that the drop did not occur.

## Implementation sketch

- Add `waiver_releases`-based sweeps to `processRelease()` (called from `teams/release.mjs` and trade processing) and to trade acceptance, cancelling any pending waiver whose `waiver_releases` row references the moved player.
- Replace the silent `continue` at `submit-acquisition.mjs:165-167` with either a thrown error that fails the claim with a recorded reason, or an explicit code path that logs the missing-drop condition and records a clear failure message on the waiver.
- Coordinate with `task/league/waiver-failure-reason-codes.md` so the new failure reason uses the eventual enum code.

## Source

Captured from Apple Notes "waivers" ("cancel waivers if you do any transactions with drop player"); validated during Apple Notes triage on 2026-04-29.