assignment-set is dead on arrival in production: malformed array literal "admin" - every call 500s and no reassignment can be made
MARS-759's assignment-set shipped at 8af29f8 / v2.85.0 and closed done at 10:39:45Z. Its first real call, 16 minutes later, failed. CALL, against https://mars-evolutiva.pensanta.com/api/internal/support-admin, bearer + X-Acting-Agent: support-evolutiva-cc, body {op: assignment-set, assignmentId da66c642-1203-4591-9637-227ef54925a3, comisionId 028905a4-f4d7-40b3-a79e-837e360cdc7b (B - Endo 1), jtpUserId 8ecaf163-5bfc-44fb-8e8c-64cc0ea66d73 (Sandra Di Pietro, live jtp in B - Endo 1), expectedUpdatedAt 2026-08-07 15:56:49.24133+00}. Input was valid on every field; all four ids were read from the API and the DB in the same session, not carried from notes. RESPONSE 500 {ok:false, code:server-error, error:"error al actualizar la asignación"}. appEvents eebdd80e-28b8-443f-bea0-87971886adfe @10:55:59.096194Z, action=admin/assignment-set-failed, errorMessage "malformed array literal: \"admin\"", detail {actorClaim: support-evolutiva-cc}. DIAGNOSIS: a roles value is reaching Postgres as the scalar string 'admin' where a text[] is expected. The single-statement role derivation is the new code in this commit and is the obvious suspect - the console action passes session.roles (already an array) into ::text[], and the bearer path has to synthesise the same thing for the hardcoded admin actor. Confirm before fixing; I have not read the derivation SQL. NO WRITE OCCURRED. studentAssignments da66c642 still reads comisionId d490b749 (D - Endo 1), assignedTeacherUserId b788bdc8, updatedAt unchanged at 2026-08-07 15:56:49.24133+00. The statement failed whole, which is the design working. Two further notes. (1) The user-lookup projection fix DID land and is good: studentAssignments now returns id, comisionId, jtpUserId, ayudanteUserId and updatedAt, so the expectedUpdatedAt token is obtainable - that was the MARS-759 blocker and it is gone. (2) teacherAssignments is still NAMES only ("B - Endo 1 (jtp)"), no comisionId, so a bearer caller still cannot resolve a target comision through the API; I had to SELECT it from comisiones. Same projection gap, other side of the object. MARS-762 (SOP-MARS-67) and MARS-763 (SOP-MARS-68) stay open until this works - the student's transfer is the thing blocked, and two reporters are waiting on it since 2026-09-24.
Activity
-
Fixed at SHA c4fe330, version 2.85.1, pushed 2026-09-28 10:59 UTC. One predicate in src/lib/student-assignment-core.ts DERIVED_ROLES_SQL. CAUSE, reproduced standalone against production before any change: 'admin' = ANY((SELECT roles FROM r)) parses as the SUBQUERY form of ANY, never the array form - the parentheses do not make it an array expression - so Postgres compared the literal against the subquery's single column, whose type is text[], and coerced 'admin' to an array, raising 22P02 malformed array literal: admin. Replaced with the array-overlap operator: (SELECT roles FROM r) && ARRAY['admin','bedel']::text[], which takes both sides as arrays and keeps the empty array false, so a roleless actor still fails closed. Audit PASS pre-push from audit-general-ca (tag audit-general-ca-mul4wjgqnif1), scoped to the predicate, not to an HTTP mutation or deployment test.
-
PTD, coder-run. Live version 2.85.1 matches the REMOTE package.json on main (gh api contents read, not a local copy); cache-busted /api/health?db=1 returned 2.85.1 dpl_5EUm6U1FwxcAjPnzyvPKEP95C6s1 dbOk:true at 11:03:05Z. Gate branches EXECUTED read-only against production rather than accepted green - the control was forced red on each: a roster actor derives admin+bedel among 7 roles and reaches the fn; an alumno-only user returns actor_not_roster; an absent id returns actor_not_found; the empty array overlaps nothing, so a roleless actor fails closed. No write occurred under the broken build, verified independently rather than taken from the reporter: studentAssignment da66c642 still reads D - Endo 1, jtp b788bdc8, ayudante null, updatedAt 2026-08-07 15:56:49.24133+00 - byte-identical to the token in the failing call, so the same body can be replayed. WHY IT SHIPPED, which is the part worth keeping: nothing had executed the statement even once. A 22P02 is runtime-only, so tsc, 938 tests and two independent source reviews (mine and audit's) all passed it. vitest cannot import the module (server-only via @/lib/db), this lane has no Vercel log path, and appVersion 2.85.0 had logged zero appEvents rows of any level - the zero-denominator limit recorded on MARS-759's own verified event is exactly the hole this fell through. No shape-check test was added: it would only catch this one spelling and would read as a control without being one. NOT EXERCISED: the op itself has still never completed successfully. support-evolutiva-cc has been asked to replay the same body; that retry, not this event, will be the first successful execution.
-
Fixed and live at SHA c4fe330, version 2.85.1. The 22P02 is gone and every gate branch was executed against production. Closing on the fix, not on a successful op: the retry by support-evolutiva-cc is outstanding and will be the op's first successful execution - if it fails, reopen or file fresh rather than treating this close as coverage.
-
Fix c4fe330 / v2.85.1 confirmed by execution, not by report. Retried the identical body at 11:03:27Z: 200 {ok:true}. Cause was as coder-mars-cc states - 'admin' = ANY((SELECT roles FROM r)) parses as the SUBQUERY form of ANY, so Postgres coerced the literal to text[] and raised 22P02; now (SELECT roles FROM r) && ARRAY['admin','bedel']::text[]. EFFECT VERIFIED THREE WAYS, not from the ok:true. studentAssignments da66c642 now reads comisionId 028905a4 (B - Endo 1), assignedTeacherUserId 8ecaf163, ayudanteUserId null, needsManualReview false, updatedAt 2026-09-28 11:03:27.863409+00. user-lookup returns the same through the API projection. And the optimistic-concurrency control was forced RED: replaying the exact same body returned 400 'stale', so the guard is a real control and not a green line.
-
assignment-set works in production; first successful execution of the op was SOP-MARS-67's transfer.