Yes, I understand that, however I don’t see how any of these scripts could be the cause. I suppose I’ll call on @xMunch about this one, though, as his script is likely the only one which could possibly be interfering. My first thought was that it was a cached issue (like when everything ballooned) however, I’ve been clearing my cache a lot recently, and no other users have said such a thing. I do think the vacation mode thing is related.
I was in the process of typing up an email as per your request but saw the (1) in this tab.
EDIT: Thank you. (Just saw your second edit below.)
I am going to reopen this since you keep persisting to edit your posts in a closed topic.
On the outside I can see why you think that way. But the problem in the past was a lot more involved than you think and isn’t a problem anymore. We were running concurrent tables for assignments for a brief period because we were doing data transformation. We had services which wrote to both and read from one. The problem stemmed from the how going off vacations were updating the timestamps on both tables (remember how reviews used to be every :15, but now every top of the hour? this had something to do with it). We were reading the bad data off of one table and it failed against a validation we set on one of the models. Thats why reviews didn’t move out of the pool.
We have long since dropped the table and reading off of one table. So the problem is not with vacation. It is just coincidence you went on vacation and had the issue.
Edit:
I have looked into what may caused the issue and it looks like the background job handling your review got dropped due to signal termination (this happens when background workers start descaling). Reviews are not evaluated asynchronously; they get sent to a background job which quickly processes it. Very rarely a job gets dropped. And when it does it gets replayed. I’ve looked at the failed job queue and it looks like the job which handled this one review got dropped. It very rarely happens, but it does happen. We have been working to fix this entirely ever since we implemented background job scaling. We did a pretty good job minimizing the drops to very very small levels, but we are looking to eliminate it completely.
I am going to close this thread now since the original issue of the thread has been addressed. And the error in the new issue has been identified. I’ll correct your item.