When committing changes to a branch with an app that has dependent workflows, I'm seeing "uncomitted changes" on the workflows, which

My goal is to commit changes to my application, create a PR, and merge to main.

I am currently on a branch. I just committed app changes to that branch. I have a dependent workflow (wfABC) that was also “protected” at the same time I introduced “protection” to the app. That workflow depends on a number of workflow “below” it (ie wfRST, wfUVW), so “protection” was also added to them at the same time.

I have made changes to the dependent workflow, wfABC but not to any of the other workflows (ie wfRST, wfUVW). However, when I go to create the pull request from the app (after committing changes to the app and wfABC), it shows (ie wfRST, wfUVW) as having “uncomitted changes” even though no changes were made. To confirm, I opened the corresponding workflows and viewed the diff (under the commit button), and there are indeed no changes.

So I have 2 questions:

  1. When trying to create an app pull request, why is Retool telling me there are uncomitted changes to a workflow, when no changes have been made?
  2. Going back to when I first setup app “protection” — I remember seeing a notice in the process of protecting, or maybe it was in the docs, something about “when an app depends on a workflow, the workflow will initially be committed along with the app. however, changes to the workflow will not be represented in source control / pull requests / commits / whatever”. ←- This also seems to contradict what Retool is telling me now, that there are uncommitted changes on a workflow.

Thanks,

Larry

1. Retool is showing the dependent workflows as “uncommitted changes” because when protection or dependencies update, Retool changes some hidden internal metadata inside those workflows. The actual workflow logic hasn’t changed, so the diff is empty, but the metadata change still makes Retool mark them as modified.

2. This doesn’t conflict with the message that workflow logic won’t appear in commits. The workflow code is not being committed — only the hidden metadata gets updated in the background. That’s why Retool still shows uncommitted changes even though the visible workflow code didn’t change.

1 Like

@Vishal1620 that’s very insightful; thank you!!

If no workflows have changed, and I commit a change to the app and create a pull request, can I safely ignore the warning that my dependent workflows have uncommitted changes or do I need to create a commit for each of them (since I can’t create a single commit for everything at once)? In this specific case, I have about 8 workflows that are showing “uncommitted changes” and it’d be annoying to have to create 8 additional commits every time I create a new PR for the app itself.

Yes, you can safely ignore those warnings. Since the workflows didn’t actually change, Retool is only showing metadata updates, not real edits. You don’t need to create 8 separate commits every time just commit your app changes and continue.

Thank you @Vishal1620 . Very helpful!!

I created a PR for my app changes. I had changes in a dependent workflow, and committed those too. When I view the PR, I see workflow changes in there. Based on the original verbiage, I thought workflow changes would not be reflected in app PRs?! Did I miss something?

@lkiss The message only means that normal workflow logic doesn’t get bundled automatically when you commit an app. But if you manually commit a workflow, then Retool treats it like any other change so it will show up in the PR.

So in your case, since you committed the workflow yourself, those changes will appear in the app PR. That’s expected.