List screenings

Maximum rows. Shared parser, parseLimitOffset: a NON-NUMERIC value is 400 common.invalid_input — it is NOT silently defaulted; 0 or any negative value except -1 is coerced to the default 10; a value above 100 is coerced to 100; -1 passes through as LimitSkipDataFetching: the count is computed and the data fetch is skipped, so the response carries totals and no rows. Note that limit is the only working pagination control here — see offset.

IGNORED ON THIS ROUTE — PAGINATION PAST PAGE ONE IS NOT POSSIBLE. The value is parsed and carried in the parameters, but FetchKYCScreenings never applies it: it calls applyParams(..., isCount=false), whose applyPaginationAndSort ends return result.Limit(limit) with no .Offset(...) anywhere on the path. Around forty sibling Fetch* functions in the same file do call GetOffset and Offset; this one does not. So ?offset=10&limit=10 returns the SAME first ten rows as ?limit=10, and a client that walks offsets re-reads page one forever. Use a search predicate on screening_date or created_at to page instead. Parsing rules, for completeness: a negative value is coerced to 0; a NON-NUMERIC value is a 400 common.invalid_input from parseLimitOffset, not a default.

Sort expression, passed through to the query builder.

Group rows by this field; data then arrives as an object keyed by the stacked value.

Passed through to the query builder.

A JSON document. Malformed JSON is 400 common.invalid_input. It is not the only query parameter that can fail: a non-numeric limit or offset is the same 400 from parseLimitOffset. An invalid search field is NOT a 400 on this route — see search..

Free-text search. Also accepted as search_text; both land on the same key.

Per-field filter, optionally with an operator suffix (.like, .gt, .gte, .in, …). Valid fields are exactly: id, entity_type, entity_id, entity_name, entity_schema, collection, status, screening_date, match_count, highest_score, has_matches, requested_by, assigned_to, assigned_at, case_id, created_at, updated_at.

TWO TRAPS. First, updated_at is listed but kyc.screening HAS NO SUCH COLUMN — the table declares modified_at — so ?search.updated_at=… passes the field-name check and then fails in the database. Second, modified_at, the column that does exist, is NOT in validFields, so filtering on it is refused as an invalid search field. Neither is usable.

HOW AN UNKNOWN FIELD IS REFUSED, AND WHY IT IS A 500. A search.-prefixed key is NOT subject to the shared parser's default: return nil branch — ParseQueryParameters puts every such key into the search map unvalidated. The refusal happens later, in validateFieldName. Its FIRST check is the identifier pattern, which builds MsgInvalidField WithCode(400) — that one is an honest 400. An unknown but well-formed field falls to the check after it, which builds MsgInvalidSearchField with NO WithCode. This route reaches it through the GetAll pipeline (getall.Service.GetAllTotal -> getAllQueryStorage.GetTotal -> applyParams -> applySearch -> query.ParseSearchQuery), and applySearch returns that error UNCHANGED. An AppError with an empty Code makes HandleAppErrorWithCode fall to InternalServerError500. So ?search.modified_at=x answers 500 query_m.invalid_search_field, class business, retryable absent — a caller error reported as a server fault. There IS a path that upgrades the same error to 400: query.ApplySearchAndSort re-raises it WithCode(400). It is not this one. kycRepository.SearchScreeningsWithQuery in common/storage/storage_kyc.go does call it, but nothing calls that method — the handler calls the identically-named method on UniversalScreeningService, which uses the GetAll pipeline instead. Do not read the repository function to predict this route's behaviour.

EVERY STRING VALUE IS SILENTLY REWRITTEN. createSearchCondition runs sanitizeValue on the parsed value; for a string that is sanitizeStringValue, which keeps letters, digits, . space / @ - and _ and DELETES every other rune, then trims. Only a value sanitizeDate recognises as a timestamp escapes it. It runs BEFORE escapeLikeValue, so a caller's % is not escaped as a literal — it is gone by then. ?search.entity_name=O'Brien builds entity_name = 'OBrien' and matches nothing; ?search.entity_name.like=Jo%hn becomes ILIKE '%John%' and matches a different set of rows. Neither is an error: the route answers 200 with a page the caller cannot explain from their own query. A name containing an apostrophe, an ampersand or a comma is not searchable here.