Skip to content
TORNLIFE More

API issue with accessing log

Started by MCSH [2855875] on in Bugs & Issues.

6 replies · 105 views · thread synced · 10 days ago · View on torn.com
About this thread

Posts archived: 7 / 7 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
7
Discussion span
→
People posting
4
Likes on archived posts
1
Posts by staff, officers and moderators
4
Authority score
58 / 100
Historical score
36 / 100
Story score
36 / 100
Engagement score
45 / 100

Most-liked replies

  • Chedburn [1] Admin · 1 likes ·
    We no longer cache similar requests within the same selections, so all of these situations should now work when requesting one after another. Thanks.
MCSH [2855875] · #1
I've noticed there are some weird behaviors when accessing the user log.

While accessing the following URL, `https://api.torn.com/user?selections=profile,log&cat=SOME_CATEGORIES&to=SOME_TIMESTAMP&key=KEY` for different time stamps (for exporting all the logs) I seem to get the same result regardless of the timestamp, so essentially the timestamp is ignored. This doesn't happen if the selection doesn't include profile or if there weren't any recent (I've set the delay to 1.2 seconds) requests.

Another potentially relevant issue is that if a comment is provided before the log parameter, the log parameter seems to be ignored.

Kindly please let me know if I can provide any more information!
DeKleineKobini [2114440] Committee Committee · #2
Including the profile selection likely results in the entire call being cached. So either don't include profile, or set the delay to 30s.
CloudJumper [1636201]Staff · #3
As mentioned above, the call will get cached if you include Profile in your request.

Another potentially relevant issue is that if a comment is provided before the log parameter, the log parameter seems to be ignored.

That is not the case, I am unable to reproduce this:

[image: i.imgur.com]

Can you provide more evidence?
MCSH [2855875] · #4
Thank you for checking it. As I tried this part again I'm unable to replicate it at this point, I'm not sure what has changed on my end.

As for the caching of log, I don't think it's correct behavior as there is a from or to argument provided that is being ignored, but it's not impossible to work around it and you can close it if you think it's not worth the effort to fix.
CloudJumper [1636201]Staff · #5
As for the caching of log, I don't think it's correct behavior as there is a from or to argument provided that is being ignored, but it's not impossible to work around it and you can close it if you think it's not worth the effort to fix.

Passing along to Joe for this.

Thanks!
MCSH [2855875] · #6
So I might have found another, possibly related bug.

If I fetch a few items descriptions like the following:


/torn/818,817,....?selections=items



and then within 30 seconds or less, use the following request

/torn/?selections=items



Expecting to get details about all items, there are times when the API returns only the previously selected items. This might happen even if the requesting IPs are entirely different and even if a separate key is used.
Chedburn [1] Admin Developer · #7
We no longer cache similar requests within the same selections, so all of these situations should now work when requesting one after another. Thanks.