#8544 the-new-hotness not processing messages
Closed: Fixed by smooge. Opened by kevin.

We got an alert:

[16:07:55] PROBLEM - rabbitmq01.phx2.fedoraproject.org/Check queue the-new-hotness is CRITICAL: RABBITMQ_QUEUE CRITICAL - messages CRITICAL (204), messages_ready OK (204) messages_unacknowledged OK (0) consumers OK (0) (noc01)
[16:24:11] PROBLEM - log01.phx2.fedoraproject.org/Disk space /var/log is WARNING: DISK WARNING - free space: /var/log 345287 MiB (15.00% inode=98%): (noc01)
[16:27:55] PROBLEM - rabbitmq01.phx2.fedoraproject.org/Check queue the-new-hotness is CRITICAL: RABBITMQ_QUEUE CRITICAL - messages CRITICAL (774), messages_ready OK (774) me

And the queue:

the-new-hotness 5097

I do see release-monitoring showing 500 errors, but I don't know why:

[17:20:58] I am not sure whats causing that... release-monitoring is throwing a 500 from it's api... but I don't know why.
[17:21:09] 10.131.2.1 - - [16/Jan/2020:01:20:42 +0000] "POST /api/version/get HTTP/1.1" 500 42 "-" "python-requests/2.20

@zlopez can you take a look please? Many thanks..


I had a quick look at it. The-new-hotness is currently getting restarted because of the MaxRetryError when calling /api/version/get on release-monitoring. Which is probably caused by error 500 on Anitya side.

I'm not sure why release-monitoring is throwing 500 when API is called, I will try to investigate further.

Probably found where the issue is and it should be fixed in next version that is currently in staging. I want to test few things before deploying it to production, so the fix could be up on Monday.

Description of the issue:
In Anitya 0.17.0 we introduced option to check releases instead of tags on Github, but some projects are using release names that aren't versions and this is causing the issue above.
In Anitya 0.18.0 the option is still available, but it's retrieving associated tag instead of release name.

Applied quick fix for now. Recreated the project with checking tags instead of releases. This should fix the issue for now, but until deployment of 0.18.0 it's still possible this issue could happen again.

Fixed by zlopez. Thanks

Metadata Update from @smooge:
- Issue close_status updated to: Fixed
- Issue status updated to: Closed (was: Open)

Metadata