Internet Explorer 11 errors commiting through web interface?

Hi all,

I have a gitlab omnibus installation at version 7.3.2 installed on RHEL 6 that has problems when committing changes with Internet Explorer 11.

It appears any users on the local LAN using Internet Explorer 11 to commit through the web interface have what appears to be a timeout issue (after 31 seconds) and they receive a 502 error but the commit appears to work (ie. the file is updated). This happens 100% of the time with IE11, never with Firefox or Chrome.

Today I noticed an additional side effect in that the file is updated correctly but the Activity stream is not. The file ‘Last Commit’ entry is correct (has correct commit number and username) but nothing appears in the Activity stream.

In an attempt to resolve the IE11 commit issue I upgraded to gitlab omnibus 7.7.2 (latest) but IE11 still doesn’t function correctly but the problem manifests itself with a different error “Your changes could not be committed. Maybe the file was changed by another process or there was nothing to commit?” but the strange behaviour is the same.

I have now reverted back to 7.3.2 and hoping there is a simple resolution for the IE11 browser commit problem (as I can replicate it in both versions?)

I have attempted running IE11 in compatibility mode for IE10, edge, and no local proxy is being used. All latest patches applied to IE11. OS is Windows 7.

Not able to see anything out of the ordinary in /var/log/gitlab log files. Any thoughts?

Cheers.

Some additional investigation and I have found several threads pointing to unicorn timeouts, so I increased the unicorn timeout to 300, which resulted in a new error in the githost.log file which may point to the real issue

February 17, 2015 22:39 -> ERROR -> Grit::Git::GitTimeout
February 17, 2015 22:39 -> ERROR -> Command failed [1]: /opt/gitlab/embedded/bin/git --git-dir=/var/opt/gitlab/git-data/gitlab-satellites/group-name/project-name/.git --work-tree=/var/opt/gitlab/git-data/gitlab-satellites/group-name/project-name push origin master

error: Ref refs/heads/master is at 1bb92244bd70ea462e2ab6cd5176a5363ec2c528 but expected 95919ef631b6e9ed68246df2a375b57f0118969e
remote: error: failed to lock refs/heads/master
To /var/opt/gitlab/git-data/repositories/group-name/project-name.git
 ! [remote rejected] master -> master (failed to lock)
error: failed to push some refs to '/var/opt/gitlab/git-data/repositories/group-name/project-name.git'

This ONLY occurs when using Internet Explorer 11 to update the file through the web interface. Same project, same file using Firefox works fine (and is quick).

The error message for IE has also changed in the UI to “Your changes could not be committed because the file has been changed.”

That definitely seems like a bug. Care to report it upstream?

I will add to the issue tracker when I have some more specific details. I am going to run up a fresh omnibus install and see if I can reproduce the error as it seems strange that no one else has reported the issue.

I have spent some more time on this and it is starting to look like a race condition of sorts.

For example, with this commit (only pasted relevant part of log):
error: Ref refs/heads/master is at 8005ae045dc6023de3db1bb3634bdf805d89859d but expected 8525ab38f0e6223c0ffe52903fc8b0dfca094615

The last commit before submitting with Internet Explorer was 8525ab38f0e6223c0ffe52903fc8b0dfca094615

The new commit is 8005ae045dc6023de3db1bb3634bdf805d89859d (ie. the code change that is being committed by IE11)

So somehow, the repository is being updated with the new/latest commit before the git command runs. This causes git to generate the error because the commit to the repo has already occurred and the git command is still expecting the previous commit to be the latest.

Another point to note is that the error only appears in the log after the timeout/error occurs on the client, this may have some significance.

Opened as Issue #1096

1 Like