Question 243648 in PHP Versions Question posted in
You can find a list of all versions here.

Php versions – Helix Swarm – Review Creation faulty "revision of 1"

I am now using Helix Swarm for quite a while but as up recently an error that some users are affected by started to occur.

When users request the review of a changelist the review is sucessfully created but it displays "revsion of 1" (it should usually say revision x of x, so in that case 1 of 1).

Neither does it display the amount of changed lines.

The review can mostly be done as normal, but updating it from Perforce doesnt work and it can not be approved by anyone.

I am at somewhat of a loss, since there is no ressources in the internet where even to begin with debugging.

I have checked out all logs (syslog, helix core log, swarm log) and none of them seem to yield anything interesting. The PHP config seems to be configured correctly (using ssl and all that), worker respawns are set up in cron, all other configs seem to be fine…

And then again, neither does it happen every review, nor does it affect any users in particular.

Any input is appreciated!

Swarm Version: SWARM/2023.1/2414875

Swarm Extension Version: 2023.1/2414875

Helix Core Version: P4D/LINUX26X86_64/2023.1/2442900

OS: Ubuntu Server 20.04.6 LTS

Update 08.20.23:

I have figured out, the condition that triggers the broken reviews is when the reviews contain binary files.

Tags:

2

Answers


  1. 0

    I recently ran into this problem and was able to find a solution. The issue is not binary files being part of the review but rather files marked as exclusive checkout.

    The solution was to run

    p4 configure set filetype.bypasslock=1

    You will need admin/superuser permissions to do this. I found this answer in their documentation https://www.perforce.com/manuals/swarm/Content/Swarm/setup.post.html#Handling_Exclusive_Locks

    Login or Signup to reply.
  2. 0

    I also ran into the problem and the issue was from the Swarm workers, the number of tasks was consistently non-0 and large, so I guess basically workers were stuck (3 of them configured at the time).

    I solved the problem by reloading the configuration and then starting the workers again.
    From the web page with an admin account:

    1. Go to the User id drop-down menu
    2. Select "System Information"
    3. Click on the "Cache Info" tab
    4. Click on the "Reload Configuration" button
    5. Go to the "Queue Info" tab
    6. Click on "Start a worker"
    Login or Signup to reply.
Please signup or login to give your own answer.

Back To Top
Search