Aglet

Prioritize API filter encoding failures

A filter that returns too many records can be more urgent than one that returns none, while a date boundary may alter a report without an obvious error. Weigh result scope, downstream decisions, shared encoder reach, and recovery cost before changing query construction.

Decide where the work belongs

  1. Describe result consequence

    For each failing filter, compare expected and returned identifiers and identify the workflow that consumes them. Separate overbroad reads, missed records, and ordering-only changes. Keep a real bounded sample behind the impact instead of relying on a screenshot or count.

  2. Compare correction paths

    Assess an encoder fix, a documented parameter change, a local validation rule, or a temporary unsupported state. Record whether the change affects every caller. Do not silently remove a filter or send a broader query when the result can influence a write or tenant view.

  3. Choose review order

    Queue overbroad results and shared encoders first, then missed narrow searches and display-only quirks. Set owner, fixture, review date, and evidence threshold. If server parsing is unknown, prioritize a contract observation before a permanent compatibility rule.

What to carry forward

Return a filter queue with expected versus returned scope, data consequence, encoder reach, safe containment, and proof needed to reprioritize. Escalate overbroad results. Keep the ranking provisional when parameter semantics or unsupported combinations remain undocumented.

Technical background: RFC Editor reference.

Keep the decision with the work.

Use a Work Item in Aglet to record the problem, the evidence you have, and the next decision. Add an owner and priority, then keep updates in the discussion so the next person can follow the reasoning.

Create an account See the product workflow