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: #619 (comment) and #619 (comment)
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
upsertmakes 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: #619 (comment) and #619 (comment)