Hacktoberfest 2026 : les issues que les mainteneurs ont marquées pour octobre, ouvertes et accessibles aux débutants. Parcourir les issues Hacktoberfest

Ignore prediction models that have been added after acquisiton started

Ouverte
  • Quelque chose ne va pas ?
#87 0 commentaires 0 réactions 0 personnes assignées Voir sur GitHub

Personne n'a encore pris cette issue.

Évaluation

Difficulté
5/5
Temps estimé
Plus d'une semaine
Accessibilité débutants
30/100
Type d'issue
Bug
Clarté
À clarifier
Activité
À l'abandon
Stack technique
python, rabbitmq
Domaine
backend, databases

Piste de recherche

Commencez par lire src/smartem_backend/predictions/update.py et src/smartem_backend/cli/initialise_prediction_model_weights.py, puis suivez les sites d’appel de seeding et de prior_update dans consumer.py. Résolvez la sémantique du verrouillage du modèle d’acquisition et de la normalisation des poids avant l’implémentation ; le travail est terminé lorsque les modèles enregistrés tardivement ne peuvent pas perturber les mises à jour de grid en cours et que l’invariant de poids attendu est préservé.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

Needs discussion with Dan before implementation - the correct locking semantics are a
product decision, not just a code fix.

Status

Confirmed present in smartem-decisions@main, and more severe than this issue originally
described. The original note framed this as future-proofing ("need to think about this");
in fact registering a new prediction model breaks prediction updates for every in-flight
grid, via an unhandled exception.

What actually happens

  1. Per-grid model weights are seeded by initialise_all_models_for_grid
    (cli/initialise_prediction_model_weights.py:23), which is called from exactly one place:
    consumer.py:180, on grid creation only. It seeds a row per (grid, model, metric) for
    the models that exist at that moment, with default_weight = 1 / len(models).

  2. register_quality_prediction_model.py contains no grid or weight logic at all. Registering
    a new model does not backfill weights for grids that already exist.

  3. predictions/update.py:46 re-reads the model list on every prior update, unfiltered:

    model_rows = (await session.execute(select(QualityPredictionModel))).scalars().all()

    There is no grid or acquisition scoping.

  4. For each model it then requires a per-grid weight row (predictions/update.py:64):

    .scalars().one()

So for any grid created before the new model was registered, the next micrograph hits a model
with no weight row and .one() raises NoResultFound. This is unhandled, and prior_update
is called directly from the RabbitMQ consumer's motion-correction, CTF and particle-picking
handlers (consumer.py:451, :520, :583).

Because there is a CLI whose entire purpose is registering a model, this is a routine
operational action rather than an exotic edge case.

Not yet established: what the consumer does with the exception once raised - whether it
nacks, requeues, or drops the message depends on the aio-pika wrapper, which has not been
traced. The unhandled raise in the live event path is confirmed; the blast radius beyond that
point is not.

Secondary defect

default_weight = 1 / len(models) is computed once at grid initialisation. Even if a weight
row were backfilled for a late-registered model, the "weights sum to 1" invariant across a
grid's models would be broken. Any fix needs to state what should happen to normalisation.

Direction

The original instinct still stands: lock the set of prediction models for the lifetime of an
acquisition and have the update path resolve models through that locked set rather than
querying all registered models globally.

Open questions for that discussion:

  • Where does the lock live - a join table per grid/acquisition, or derived from the existence
    of the seeded weight rows (which would make update.py iterate weights rather than models)?
  • What should happen to a model registered mid-session: ignored for in-flight acquisitions
    (implied by this issue's title) or backfilled at 1/n with renormalisation?
  • Should the update path fail loudly or skip gracefully when a weight row is missing? Today it
    fails loudly by accident rather than by design.

Deriving the model set from the seeded weight rows is the smallest change and would fix the
crash and the scoping in one move, but it makes the lock implicit; worth weighing against an
explicit table.

Code references

  • src/smartem_backend/predictions/update.py:46 - unfiltered global model query
  • src/smartem_backend/predictions/update.py:64 - .one() on the per-grid weight row
  • src/smartem_backend/cli/initialise_prediction_model_weights.py:23 - grid-creation seeding
  • src/smartem_backend/consumer.py:180 - sole caller of the seeding
  • src/smartem_backend/consumer.py:451, :520, :583 - prior_update call sites
Langage dominant
TypeScript
Étoiles
0
Forks
0
Aucune PR mergée en 30 j

Préparer son environnement

Ce projet ne fournit ni conteneur de développement, ni Dockerfile, ni guide de contribution : l'installation est à votre charge. Commencez par son README, et consultez notre guide de la première contribution pour les étapes générales.

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de DiamondLightSource/smartem-devtools

Toutes les issues de DiamondLightSource/smartem-devtools

Issues similaires

Plus d'issues TypeScript

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.