"Dangerous change protection is enabled" after changing configuration

Problem: Error “Dangerous change protection is enabled for this repository” continues even after “Dangerous change protection” disabled in GUI.

  • I recently migrated my Phabricator to a new machine.
  • Repos started having strange behavior - that they would update the files (I.e. pushing new files, and then cloning the repo showed the new files there), but the WebUI would not know or show the new files (or any other repo change.)
  • I fixed this by adding a “phabricator.base-uri” to the local.json config file.

!!However!!
NOW, when I try to do a git push origin master --force, I get a “Dangerous changes disabled” error message, even though Dangerous changes has subsequently been allowed via the GUI.

  • I did try disallowing dangerous changes, updating the repo, and then re-allowing dangerous changes again. It did not work.
  • I did try updating the repo from the command line using /bin/repository update reponame --trace … which appears to have run successfully, but the Dangerous Changes is still disallowed.

Phabricator Version Information
Library Version Date Branchpoint
phabricator d0f4554dbeb0 Feb 24 2020
arcanist 5451d2875221 Feb 27 2020

Other Version Information
Binary Version Path
php 5.6.40 apache2handler
diff 3.3 /usr/bin/diff
git 1.8.3.1 /usr/bin/git
hg Not Available
pygmentize Not Available
svn Not Available

Unfortunately, there’s no error message. It just fails to recognize the change of state.

Thanks for any hep you can give!

Please include version information in your report.

https://discourse.phabricator-community.org/t/bug-reports-must-have-reproduction-instructions/2829

When you report that you get an error message, please please please include the text of the error message in your report.

https://secure.phabricator.com/book/phabflavor/article/please_please_please/

Updated. Thanks!

This was the “error message” I was hoping to get a copy of.

There are a couple of ways that Phabricator can produce push rejections. Although it’s likely that this isn’t anything tricky, double-checking the error message takes a few seconds if I have a copy of it and might save us hours on a wild goose chase if this is really, say, a rejection from Herald and the root cause is something like “it’s too easy to write Herald rules that look confusingly similar to builtin push rejection rules”.

I can’t reproduce this problem locally. Here’s a force-push blocked by dangerous change protection (shown in a window in the background at the top of the screenshot);

Here’s the same force-push permitted a moment later after allowing dangerous changes (see above the console in the background window):

I can’t recall any recent changes which would impact behavior here so I’m at a loss as to how to reproduce the issue you describe.

Hi epriestley,

Thanks for the reply.

This occurred after a migration, which caused a problem with the config file. The config file got re-written from scratch, and didn’t have the “phabricator.base-uri” set in it.

This caused strange behavior with the repos - where the actual repo would get updated, but the Web UI page would not show those updated changes. During that time (before fixing the phabricator.base-uri issue) I tried un-setting and re-setting the “Allow dangerous changes” setting, via the WebUI.

After fixing the issue, the WebUI was showing the changes to the repo again - but the “Allow dangerous changes” setting would not work, even after toggling it off and on again.

Perhaps you could attempt the same process to recreate the issue.

If not, perhaps we could just troubleshoot it from scratch?

I suspect (not being a Phabricator developer) that there’s probably a switch somewhere in one of the MySQL DBs - that for some reason is now stuck in limbo. I don’t know where that switch is.

Or, perhaps, there’s a flag in the actual repo itself (on the hard drive) which, now, is not getting changed by the WebUI when the “Allow dangerous changes” is flipped? Is there something like that?

Maybe we could look there?

Thanks again!
Mike

P.s. If you need to be able to reproduce it in order for it to be a bug report, and you can’t, perhaps you can just change the “bug” flag to the a “General discussion” flag?

Thanks again!

Perhaps you could attempt the same process to recreate the issue.
If not, perhaps we could just troubleshoot it from scratch?

I’m happy to do this under a paid support pact, but need working reproduction steps to continue pursuing this as a bug report.

I suspect (not being a Phabricator developer) that there’s probably a switch somewhere in one of the MySQL DBs - that for some reason is now stuck in limbo. I don’t know where that switch is.
Or, perhaps, there’s a flag in the actual repo itself (on the hard drive) which, now, is not getting changed by the WebUI when the “Allow dangerous changes” is flipped? Is there something like that?

My expectation is that Phabricator does not work like this.

P.s. If you need to be able to reproduce it in order for it to be a bug report, and you can’t, perhaps you can just change the “bug” flag to the a “General discussion” flag?

Sure.

Bump