Skip to content
TORNLIFE More

Abroad items occasionally skip one restock cycle

Started by Professor_GmbH [2792553] Reporter on in Bugs & Issues.

4 replies · 85 views · thread synced · 3 days ago · View on torn.com
About this thread

Posts archived: 5 / 5 posts (100%) · the total is Torn's reply count + the opening post at the last fetch

Counted by TornLife from the archived posts.

Archived posts
5
Discussion span
→
People posting
3
Likes on archived posts
12
Posts by staff, officers and moderators
3
Authority score
58 / 100
Historical score
34 / 100
Story score
44 / 100
Engagement score
56 / 100

Most-liked replies

Professor_GmbH [2792553] Reporter

I was asked to make a new post for this, it comes from a discussion in this post: Here

Xanax restock times is usually 2hrs +-10% (or something close to that), so 108-132 minutes from when it sold out.
Other travel Items have different timers.

I witnessed it before on very rare occasions on other destinations (like Canada), that the restock "skips" one cycle and moves to the next one, so we get the 4 hr restock time that Dieselblade mentioned.

Now since yesterday in South Africa, we had that same thing happen several times close to each other and with different items (I only watched Xanax + Uncut Diamonds), which makes me believe it has something to do with the stock getting sold out quicker than usual.

To clarify: this isn't us missing the restock, because it is sold out super fast or something, the restock just doesn't happen.


I was able to observe the following for yesterday and today: 

Xanax (~120 min restock timer):
Yesterday:
Empty: 12:09 TCT - Expected Restock: ~14:09 TCT - Actual Restock: 16:14 TCT

Today: 
Empty 02:36 TCT - Expected Restock: ~04:36 TCT - Actual Restock: 06:33 TCT


Uncut Diamonds (~60 min restock timer):
Yesterday:
Empty: 18:06 TCT - Expected Restock: ~19:06 TCT - Actual Restock: 20:12 TCT
Empty: 21:30 TCT - Expected Restock: ~22:30 TCT - Actual Restock: 23:36 TCT

 

Hope that helps to figure out if that "Skip" is intentional or a bug.
As said, I only ever witnessed that very rarely before, for example with Xanax in Canada and I think only when it got sold out in under a minute before (but there are other times when its sold out in Canada very fast, where the next 2 hour restock works just fine). 


Best regards.

Mentions: Travel Update - Selling items back to abroad shops resets restock timers

splent [2088243] Admin Staff

Thanks for all the details. 

 

I can definitely confirm restock is skipped sometimes.

I'm not entirely sure why does this happen. I suspect there's a racing condition of sort, so I decoupled the price changing and restock logic, and moved the restock logic directly to DB layer to prevent any accidental stock values being overwritten.

 

I tested the logic and it seems okay, but then again, I tested the previous logic also and it also seemed fine, so let's wait and see if this happens again.

I'll monitor the restock logs we have as well.

 

Also, I'll mark this bug as "Info Required" for a bit before marking it as "Fixed" again.

 

Thanks!

Professor_GmbH [2792553] Reporter

It looks like the bug still happens.

I just observed a few minutes ago:

Uncut Diamonds (~60 min restock timer):
Empty: 16:08 TCT - Expected Restock: ~17:08 TCT - Actual Restock: ??:?? TCT (my guess is ~18:08 TCT) 

splent [2088243] Admin Staff

Indeed. 


This bug is now finally, properly resolved.

 

So, the cron job runs every minute at xx:00, but the restock timestamp could however be scheduled at e.g. xx:43.

This leaves 17 second window in which selling an item back to the system and then purchasing it again would set a new restock timestamp value.

 

So yeah, the issue was not within the cron job itself as I thought it was (some parts of the logic were a bit unnecessarily complex), but with buying that last item from the system but only if the restock timestamp was already scheduled and the current time had surpassed the timestamp and the cron job didn't pick it up.

Thanks everyone for your patience and OP for the details. 

We'll of course continue monitoring this bug.