Project

General

Profile

Actions

Bug #22785

closed

422 error "ambiguous column created_at in order by"

Added by Peter Amstutz 11 months ago. Updated 11 months ago.

Status:
Resolved
Priority:
Normal
Assigned To:
Category:
API
Target version:
Story points:
-
Release relationship:
Auto

Description

API server sometimes returns a 422 error from group contents when using it to query container requests and containers together in a single request.

This happens when looking at a process listing such as "All processes" and filtering by status such as "Failed" or "Queued", and ordering by a common field such as "created_at".

The problem is that the implementation of filtering by state joins the container_requests table with the containers table and both of them have a created_at field. This results in a SQL error, because we do not disambiguate.

I think the solution is to make sure the order fields are prefixed with the correct table (container_requests in this case).

Note that if #21074 merges first, this almost certainly needs to apply to the Workflows.collection_uuid -> Collections join as well.


Subtasks 1 (0 open1 closed)

Task #22798: Review 22785-ambiguous-columnResolvedPeter Amstutz04/28/2025Actions
Actions #1

Updated by Peter Amstutz 11 months ago

  • Position changed from -950939 to -950927
Actions #2

Updated by Peter Amstutz 11 months ago

  • Description updated (diff)
Actions #3

Updated by Tom Clegg 11 months ago

  • Assigned To set to Tom Clegg
Actions #4

Updated by Tom Clegg 11 months ago

  • Subtask #22798 added
Actions #5

Updated by Peter Amstutz 11 months ago

  • Description updated (diff)
Actions #6

Updated by Tom Clegg 11 months ago

  • Status changed from New to In Progress
Actions #7

Updated by Tom Clegg 11 months ago

22785-ambiguous-column @ 5fafe99323b48aad6433ad0c6bc206d023726195 -- developer-run-tests: #4753

  • All agreed upon points are implemented / addressed. Describe changes from pre-implementation design.
    • ✅ Fixes ambiguous column name in query
  • Anything not implemented (discovered or discussed during work) has a follow-up story.
    • n/a
  • Code is tested and passing, both automated and manual, what manual testing was done is described.
    • ✅ Added a test case that reproduces the bug. If you run tests at 4ac2ff3901 (with the test, but no fix), you get
      Failure:
      Arvados::V1::GroupsControllerTest#test_get_objects_with_ambiguous_column_name_in_order_param [/home/tom/arvados/services/api/test/functional/arvados/v1/groups_controller_test.rb:362]:
      Expected response to be a <2XX: success>, but was a <422: Unprocessable Content>
      Response body: {"errors":["#<ActiveRecord::StatementInvalid:\"PG::AmbiguousColumn: ERROR:  column reference \\\"created_at\\\" is ambiguous\\nLINE 1: ...ontainers.state in ('Queued','Locked'))) ORDER BY created_at...\\n                                                             ^\\n\"> ()"],"error_token":"1745608934+99d736e5"}
      
  • New or changed UX/UX and has gotten feedback from stakeholders.
    • n/a
  • Documentation has been updated.
    • n/a
  • Behaves appropriately at the intended scale (describe intended scale).
    • n/a
  • Considered backwards and forwards compatibility issues between client and server.
    • n/a
  • Follows our coding standards and GUI style guidelines.

This also fixes a minor optimization bug. The last part of load_limit_offset_order_params deduplicates the order by entries and strips superfluous entries, e.g., given "uuid, created_at" it will use just "uuid", which is functionally identical and (at least at the time we wrote that) more efficient. This wasn't working for groups#contents queries: it assumed all orders entries were fully qualified with table names, but that wasn't the case when called with fill_table_names: false. I fixed this by moving the "optimize" code into a separate func and calling it separately from the contents controller.

Actions #8

Updated by Peter Amstutz 11 months ago

This LGTM

Actions #9

Updated by Peter Amstutz 11 months ago

  • Release set to 78
Actions #10

Updated by Tom Clegg 11 months ago

  • Status changed from In Progress to Resolved
Actions

Also available in: Atom PDF