Dev Log: August 25 Wrap-up

Overview

Today was a mix of architectural heavy lifting and some much-needed logic cleanup. Spent a significant chunk of time figuring out a clean way to handle loops in our workflow engine without breaking the fundamental rules of our graph execution.

What I Worked On

Implementing the For-Each Node

This was the big highlight of the day. Our workflow engine is built as a strict directed acyclic graph (DAG). That’s great for predictability, but it makes doing anything "per row" a nightmare because you can't easily draw an edge back to an earlier node without creating a cycle. If the engine sees a cycle, it stalls out because it can't find a starting point for the next step.

I managed to sidestep this by implementing a forEach node that uses nested execution. Instead of looping within the main graph, the node identifies its "loop body" nodes, carves them out, and runs them through a sub-instance of the executor for every row in the dataset.

It’s a much cleaner approach. Here’s a quick look at the configuration structure for the new node:

{
  "nodeType": "forEach",
  "formConfig": [
    {
      "label": "Row Variable Name",
      "name": "item_key",
      "value": "row",
      "hint": "The key the current row is passed under."
    },
    {
      "label": "Input Mappings",
      "name": "mappings",
      "placeholder": "{\"id\": \"inputs.row.id\"}"
    }
  ]
}

Refining Master Upload Status

I noticed some checklists were getting stuck in a "Pending" state even when the master type was changed to something that doesn't actually require a file upload (what we call "auto-executed" types).

I updated the logic to re-derive the status on every fetch. Now, if the master definition says it's an auto-type and the checklist is still pending, we automatically move it to executed. It’s a small change, but it removes a lot of manual friction for the users.

// Simple check to ensure auto-executed types don't stay pending
if (isAutoExecutedType(master.type) && checklist.status === 'PENDING') {
    checklist.status = 'EXECUTED';
    needToUpdate = true;
}

Facility Selection Syncing

Fixed a annoying bug in the hospital onboarding flow. We use signals to manage state in the UI, but several of our older, custom-upload popups still look at sessionStorage for the facility_id.

I noticed that if the default facility was loaded automatically, the storage wasn't always updated, leading to a mismatch. I consolidated this into a single setter so that the signal and the storage never drift apart again. It’s one of those "boring" fixes that actually prevents a dozen random support tickets.

Cleaning up HTTP Nodes

Did a bit of housekeeping on the HTTP request nodes. We had some legacy code trying to force a dynamic session handle visibility that we don't really need anymore. I commented that out to keep the UI cleaner. Less noise, more focus.

Wrapping Up

Overall, a solid day. The forEach logic feels like a real win for the workflow engine's flexibility. Tomorrow, I’ll probably dive deeper into testing how that nested execution handles larger datasets without hitting memory limits. Catch you then.