OpenFn / OpenFn/apollo

Follow-ups on the gold workflow test material from #619

Open
#644 0 comments 0 reactions 1 assignee View on GitHub

@hanna-paasivirta is already working on this.

Since Aug 20, 2026.

Dominant language
Jupyter Notebook
Stars
5
Forks
10
Avg merge
2d 20h
Merged PRs (30d)
17

Description

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

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.