Follow-ups on the gold workflow test material from #619
I maintainer di solito rispondono entro 5 giorni
@hanna-paasivirta ci sta già lavorando.
Dal 20/8/2026.
Valutazione
Questa issue non è ancora stata valutata.
Descrizione
Two small things came out of reviewing #619 that we agreed to handle separately rather than hold the merge. Both are test material, nothing user facing.
The first is the create and update logic in the two fan-out reference workflows. It calls operations inside fn, which gives the immediately-invoked shape that the code quality judge is told to flag. We checked the docs and the rule is right: the operations page calls that an anti-pattern to avoid. So the reference workflows are the thing to change, not the judge rules.
For the vague fan-out there looks to be an easy fix. The openmrs adaptor has upsert, which does the lookup and then creates or updates inside one operation, so the if/else goes away and the path stays linear. That matters because a branch would otherwise mean duplicating the DHIS2 and FHIR steps under both sides.
The verbose fan-out is genuinely unresolved. It only wants the generated OpenMRS ID on the create path, and upsert makes that decision for you, so we need a view on the right shape there. Hanna is checking with Hunter.
The second is smaller. Four of the new specs ask the judge to catch invented adaptor functions, while the same PR tells judges not to flag functions as invented unless the docs contradict them. Both judge files say test criteria win on a conflict, so the criteria put the guessing back whenever the docs lookup comes back empty. Rewording them to something checkable without docs would settle it.
Review comments for reference: https://github.com/OpenFn/apollo/pull/619#discussion_r3822147407 and https://github.com/OpenFn/apollo/pull/619#discussion_r3822147420
- Lingua principale
- Jupyter Notebook
- Stelle
- 5
- Fork
- 10
- Merge medio
- 2g 12h
- PR unite (30g)
- 17
Preparare l'ambiente
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di OpenFn/apollo
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 84/100
I maintainer di solito rispondono entro 5 giorni
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100
I maintainer di solito rispondono entro 5 giorni
-
platform
Difficoltà 2/5 1-3 ore Idoneità per principianti 84/100
I maintainer di solito rispondono entro 5 giorni
-
Apollo 3.3.0 is stalledAperta
Difficoltà 4/5 3-5 giorni Idoneità per principianti 30/100
OpenFn/apollo#696 · 1 commento ·
I maintainer di solito rispondono entro 5 giorni
-
Difficoltà 4/5 3-5 giorni Idoneità per principianti 45/100
I maintainer di solito rispondono entro 5 giorni