feat: Add ability to create a change request ignoring conflicts

[kyle-ssg]

Thanks for submitting a PR! Please check the boxes below:

• I have added information to docs/ if required so people know about the feature!
• I have filled in the "Changes" section below?
• I have filled in the "How did you test this code" section below?
• I have used a Conventional Commit title for this Pull Request

Changes

Allows user to specify that they wish to ignore conflicts when creating a change request, this is useful when scheduling multiple updates to a single flag. Checking this option will also skip checks detecting that the feature state is unchanged.

How did you test this code?

Created multiple change requests for a flag

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Preview	Comments	Updated (UTC)
flagsmith-frontend-preview	Ready	Preview	Comment	Nov 20, 2025 11:07am
flagsmith-frontend-staging	Ready	Preview	Comment	Nov 20, 2025 11:07am

1 Skipped Deployment

Project	Deployment	Preview	Comments	Updated (UTC)
docs	Ignored	Preview		Nov 20, 2025 11:07am

[github-actions]

Docker builds report

Image	Build Status	Security report
ghcr.io/flagsmith/flagsmith-api-test:pr-6236	Finished ✅	Skipped
ghcr.io/flagsmith/flagsmith-e2e:pr-6236	Finished ✅	Skipped
ghcr.io/flagsmith/flagsmith-api:pr-6236	Finished ✅	Results ✅
ghcr.io/flagsmith/flagsmith:pr-6236	Finished ✅	Results ✅
ghcr.io/flagsmith/flagsmith-private-cloud:pr-6236	Finished ✅	Results ✅
ghcr.io/flagsmith/flagsmith-frontend:pr-6236	Finished ✅	Results ✅

[matthewelwell]

This isn't really related to being able to create the change request, but more about what happens when it goes live at the scheduled date.

Without this boolean enabled, a scheduled change will fail, and send a notification to the author, if another change has been made to the flag between creation of the change request, and the time it is due to go live. With this boolean enabled, it will ignore the conflict and update the flag with the information it had at the point of creation.

Based on this, we should (a) only show this if the change request is scheduled for the future, and (b) update the wording here. Perhaps something like:

"Ignore any conflicting changes when this change goes live. If disabled, and another change is made to this flag before the live date, this change will fail and a notification will be sent to the author."

[kyle-ssg]

I could imagine a scenario where people line up these change requests without scheduling and the process is just manual - in a case where they don't know exactly when the time frame is they just know its coming.

For example this could be for maintenance but they do not know exactly when they want to turn the feature back on.

[matthewelwell]

Sorry, yeah, it looks like the logic also applies there, for CRs that stay open for a while, and other changes happen in between, this would be the case too. In that scenario though, we'd probably want to have this checkbox on the 'publish' action, rather than when you create the change request itself.

The FE technically could handle that itself by checking if there are conflicts on an open CR, showing the checkbox and then sending 2 requests when the user hits publish - one to manually update the CR to set "ignore_conflicts": true, and the second to actually publish the CR.

What we'd probably want to do though is to add this same ignore_conflicts attribute to the payload on the publish endpoint.

[kyle-ssg]

Right, so this isn't needed really at all when creating change requests? One thing I noticed was we check for when the change request appears unchanged, it seems this has raised a usecase where submitting an unchanged change request is valid. I think I should just remove this check all-together and move the ignore_conflicts to the publish step?

[matthewelwell]

Not quite - there are 2 use cases:

1. Publishing a change request
2. Creating a scheduled change request

For the scheduled change, we do need this on creation of the change request.

Agreed that we should remove the hard fail on if there are no changes, but we should perhaps just show a warning message instead?

[kyle-ssg]

This is done however it was a bit more complex than I thought a couple things had to be tested for regression

• Versioned vs Non versioned environments
  Since change requests use change sets for versioned environments the change detection had to differ when publishing

• Segment change detection
  Detecting changes at the point of saving the feature modal is quite ugly until quite a lot of refactoring is done, I've tested this detects changes for segment changes / priority changes.

[matthewelwell]

@kyle-ssg I don't understand what's happened here. We've lost the option that was the original point of this change - there's no option anywhere on creating a scheduled change, or publishing a change request that is scheduled for the future.

To be totally clear, what I am expecting is a checkbox that says something like "Ignore any conflicts when this change goes live" to be visible in the following cases:

1. When creating a scheduled change (i.e. clicking 'Schedule Update' from the feature modal)
2. When publishing a change request that is scheduled for the future.

If this checkbox is checked, you should send the ignore_conflicts parameter to the change request. For the second point, this will require sending an update request to the change request before publishing.

Let me know if this isn't clear - I've also messaged on Slack to discuss in a huddle because I think we're not on the same page somewhere here.

[matthewelwell]

Following our discussion earlier, I've tried to document exactly how change requests and scheduled changes work in versioned / non-versioned environments here.

Based on this, the only real use case that I can see for this is to be able to select to ignore conflicts when there are no changes to the feature when the change request / scheduled change is created. I do think that we need to be clearer to the user about exactly what is going to happen, however, so I think we should implement the following:

'Create Change Request' flow

1. Keep the confirmation when creating a change request with no changes from the current live version, but do not set ignore_conflicts at this point.
2. If the change request is scheduled for the future, and there are no changes from the current live state, when the user chooses to publish the change request, they should be given the option to 'ignore conflicts' (and should be shown the warning text as below).

'Schedule Update' flow

1. Add a confirmation when creating a scheduled update that contains no changes from the current live state (as per the current implementation for 'Create Change Request' flow
2. Add a second confirmation to choose to 'Ignore conflicts' (and show the warning text as suggested below).

Suggested Warning Text

"By choosing to ignore conflicts, the change defined in this Change Request will become live regardless of any changes that happen to this feature between now and the scheduled live date. This may result in a loss of those changes, please proceed with care."

[matthewelwell]

@kyle-ssg , this is looking better, but still missing a few pieces. I've listed out the scenarios that I've tested below with some feedback where necessary.

✅ Publishing an 'immediate' change request when there are no conflicts does not show the warning and does not send "ignore_conflicts": true
❌ Publishing a change request with a scheduled date in the future shows an option to send "ignore_conflicts" regardless of whether there are conflicts or not
❌ Creating a scheduled change (i.e. change requests disabled) shows the warning and sends "ignore_conflicts" if checkbox is enabled.

Technically the last one does kind of work, but it sends the ignore_conflicts parameter to the wrong endpoint - it needs to be sent when the change request is created or updated, not to the commit endpoint. I can update the BE to accept this parameter on commit if necessary.

Other Tests

❌ Publishing an 'immediate' change request when there are conflicts shows the warning and sends "ignore_conflicts": true

I actually think this one isn't relevant anyway - sorry! In the BE, the ignore_conflicts only comes into play for scheduled changes. If someone manually publishes a change for immediate effect, then conflicts are ignored as it's assumed that they have checked the diff. We could perhaps update the BE to need ignore_conflicts here too if we want.

Either way, the FE isn't sending the parameter (but it doesn't matter).