In #3052037: One of my Git commit is auto posting new comments to the issue endlessly what was happening was the entire _versioncontrol_reposync_run_worker() processing was taking over 60 seconds. That’s the default in the Pheanstalk library we use for Beanstalk to assume the queue runner failed and restart the job. It then got into a loop until one of the still-running processes managed to get the job complete and deleted.

Most of the processing on Drupal.org is in hook_versioncontrol_code_arrival(), outside of the versioncontrol sync log timing and locking. So the duplicate jobs were able to proceed. We’ve raised this limit on Drupal.org’s configuration, but this might still happen if there are pushes that take longer than the new limit to process.

These did get a different slid and elid each time, so detecting this condition might be tricky. If it is possible to detect, it would be great to bail out instead of re-processing the same thing.

Comments

drumm created an issue. See original summary.

drumm’s picture

drumm
he/him
Location NY, US
commented
Related issues: +#3052337: Use touch command to avoid exceeding TTR

I also opened #3052337: Use touch command to avoid exceeding TTR to avoid this queue behavior in the first place. That would be better than workarounds here.

If there isn’t a straightforward way to detect this condition, I think it would be best to won’t fix this issue and keep the complexity out of the versioncontrol codebase.