El banco de donantes no tenia orden, y el orden es parte del resultado

[frapercan]

Por que el orden del banco es un resultado y no una limpieza

El 91% de las consultas tienen vecinos a distancia ~0, ellas mismas o gemelas con
la misma secuencia. Asi que los terminos candidatos empatan en el k-esimo
hueco y la busqueda admite al donante que vaya PRIMERO en el banco. El orden del
banco decide, por tanto, que pares se publican.

Dos sitios lo decidian por accidente.

1. La consulta del pool unificado no llevaba ORDER BY

El orden era el que emitiera el plan. Medido sobre el banco de la 219, 142.422
filas, las mismas filas en todos los casos:

plan	digest del orden
hash join, sin paralelismo	89b79ad15383
hash join, work_mem bajo	89b79ad15383
merge join (enable_hashjoin=off)	cf77c750bed5
las mismas filas ordenadas por accesion	cf77c750bed5

El plan por si solo movia f_micro_w ~1e-3 por celda, concentrado en CCO y con
signos mezclados. Y el plan depende de estadisticas y de work_mem, que en esta
maquina es justo lo que se mueve.

2. El indice por aspecto se construia iterando un set de cadenas

Peor que lo anterior. CPython aleatoriza el hash de cadenas por proceso salvo que
PYTHONHASHSEED este fijado, y aqui no lo esta. Comprobado pasando las mismas
ocho accesiones por tres interpretes:

P12345,B2RXH2,Q4GWU5,A0A014NF26,O00142
P0DMV8,O00142,B2RXH2,Q4GWU5,Q9Y6K1
A0A014NF26,Q4GWU5,P12345,P0DMV8,A6NMY6

Asi que el orden del banco por aspecto cambiaba en cada arranque de worker que
reconstruyera la cache, no solo cuando cambiaba el plan. La ruta por aspecto es la
que usa la comparacion con el nodo de computo.

Extraido a _aspect_indices, que ordena por accesion. Se ordenan las accesiones y
no los indices resultantes, para que siga siendo correcto con independencia del
orden en que quede el pool unificado.

Lo que lo tapaba

La cache en disco congelaba un orden. Una repeticion identica del mismo payload
reproducia par a par: 187.834 pares, 0 solo en A, 0 solo en B, 0 con distancia
distinta. Pero esa cache tiene ref_cache_freshness_seconds, asi que el
enunciado real no era "dos corridas pueden discrepar", era "una corrida de hoy
puede discrepar de una de la semana que viene, en silencio, por 1e-3 por celda".
Eso es lo que el sello de marco existe para impedir.

Esto tambien acota un hecho que ya teniamos medido: la evaluacion reproduce 117 de
117 metricas exactamente, asi que el suelo de reproducibilidad no vive en la
puntuacion. Vive en la recuperacion.

Por que accesion

Porque es el orden que una reproduccion externa elegiria sin que nadie se lo diga,
y porque alinea el desempate con el del nodo de computo, cuyo banco ya va por
accesion. El desacuerdo medido entre los dos arneses sobre 219->220, cuatro celdas
de nueve identicas y el resto dentro de 8e-4, deberia pasar a coincidencia exacta.

Tests

Diez nuevos en tests/test_the_donor_bank_has_an_order.py, y la suite de
prediccion entera en verde (221, uno saltado).

El pool: que ordena por accesion, que lo hace tambien con una politica de
donantes restringida y con reviewed_only, y que el ORDER BY es el ultimo y uno
solo, no dentro de la subconsulta de anotadas, donde no ordenaria nada util.

El indice por aspecto, de forma determinista: el colector se sustituye para
entregar las accesiones en orden INVERSO, asi que iterar la entrada tal cual
escribiria el reverso y solo ordenar escribe orden de accesion. No depende de que
un set real tenga la suerte de salir desordenado. Y acc_to_idx asigna indices
deliberadamente NO en orden de accesion, para que un test que pase no pueda estar
pasando por coincidencia.

El helper aparte: que ordena cualquier iterable (lista, reversed, set), que
descarta una accesion que el pool unificado no lleva en vez de petar, y que un
aspecto vacio da un array int32 vacio.

Un test existente, TestReferencePoolQuery::test_builds_subquery, afirmaba la
cadena de joins exacta y se actualiza, porque la consulta termina ahora en
.order_by().

Operativa, que no va en esta PR

Las caches de banco que ya hay en disco se escribieron con el orden viejo. Al
desplegar hay que invalidarlas para que se reconstruyan ordenadas, o el arreglo no
cambia nada en esta maquina hasta que caduquen solas. Lo hago en el despliegue.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 88.02%. Comparing base (d8bc801) to head (8f961bd).
⚠️ Report is 106 commits behind head on develop.

Additional details and impacted files

@@             Coverage Diff             @@
##           develop    #1007      +/-   ##
===========================================
+ Coverage    87.85%   88.02%   +0.17%     
===========================================
  Files          306      330      +24     
  Lines        23414    25583    +2169     
===========================================
+ Hits         20570    22520    +1950     
- Misses        2844     3063     +219     

Files with missing lines	Coverage Δ
...operations/predict_go_terms/_batch_op_reference.py	99.47% <100.00%> (+<0.01%)	⬆️

... and 39 files with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.