Skip to main content

UX-WF-002 — Make run filters match the Airflow query contract

FieldValue
StatusOpen; source-verified, signed-in deployment check blocked
Architecture stateDeployed behavior; managed runtime contract inactive
SeverityMedium
Affected surfaceWorkflow detail Runs filters
Componentssparqd/oqullus, sparqd/bff-api, sparqd/workflow-backend, Airflow
Associated issueNot opened

Where the problem appears​

Open a workflow detail page and use Base date, Num Runs, or All Run States above the run grid.

Concrete observed case​

The controls are connected to the request, but they do not form one reliable filter contract:

  • One or more selected states are sent as a comma-separated state query parameter. Airflow 2.11's GET /dags/{dag_id}/dagRuns contract does not define a state parameter, so the control cannot be treated as working.
  • Base date is only an upper bound. There is no selectable lower bound even though the component carries an unused start-date value. The selected browser date is changed to local 23:59:59.999 and then converted to UTC, but the UI does not explain the timezone or that Airflow execution_date is a logical date rather than launch time.
  • 365 sends limit=365; All sends limit=1000. Airflow's API page size is capped by server configuration and defaults to 100, so those labels can promise more runs than the response contains.

The deployment check reached the requested realm sign-in page, but no authenticated browser session remained available. The repository's local E2E account targets a different realm and workspace, so its result was discarded. The requested deployment response is therefore not claimed as verified.

Expected condition​

Every visible filter must have a product-owned contract and observable effect. State filtering should use an endpoint that accepts a state list or be applied locally to a deliberately fetched bounded set. Date controls should say which run timestamp and timezone they filter. Run-count choices must not exceed the actual service boundary, and All must use pagination rather than a sentinel large number.

Cause and evidence​

  • Oqullus Runs/index.tsx builds execution_date_gte, execution_date_lte, and comma-separated state parameters and maps All to 1000.
  • Oqullus Detail/index.tsx initializes filterStartDate without a setter and exposes only the end-date picker.
  • BFF's generic Airflow route forwards query parameters unchanged; it does not translate state selection or paginate beyond the Airflow response.
  • The deployed stack source selects Airflow 2.11.0-ci-1.2.0.
  • The Airflow 2.11 stable API reference documents date, ordering, offset, and limit filters for this v1 endpoint but no state filter. Airflow 2.11 retains this v1 contract.

Why it matters​

Users can believe they are looking at only failed or successful runs while the request is invalid or unfiltered. Ambiguous logical-date and browser-timezone behavior can hide a boundary run, while 365 or All can silently return only the server maximum.

Existing controls and workarounds​

Treat state selection as unreliable. Use the visible state of each returned run and narrow by a supported date bound. For more than the service page limit, use Airflow or an operator/API client with explicit pagination.

Alternatives considered​

  1. Recommended: expose a workflow-backend run-list contract with repeatable states, explicit logical-date bounds, cursor or offset pagination, and a documented maximum.
  2. Use Airflow's batch run-list endpoint if its supported state-list behavior matches the deployed version, behind the current access boundary and the workflow authorization boundary after OpenFGA rollout.
  3. Filter locally — acceptable only for the already fetched bounded page and labelled Filter shown runs, not as a complete-history filter.

Component involvement​

  • sparqd/workflow-backend supplies the managed query contract and pagination; workflow authorization is added when OpenFGA is activated.
  • sparqd/bff-api exposes that contract without generic Airflow parameter leakage.
  • sparqd/oqullus owns clear labels, timezone presentation, and filter result states.

Reproduction and verification​

Follow WF-S018.

Resolution conditions​

Close when automated and deployed evidence proves each filter changes the returned set as labelled, multiple states use defined OR semantics, date and timezone semantics are visible, and count options cannot silently truncate.

Validation and blockers​

Oqullus, workflow-backend, BFF, Airflow, product, and UX owners must validate. Signed-in deployment evidence for gj76anadpsc / w-t5e2kcxjd remains open.