Jump to content
McKay Development

Getting error in retrieving inventory after some time


What Comes Around
 Share

Recommended Posts

Good day!

Recently I was surprised to find that my bots had inventories but looking at the logs they said they didn't have anything. So after enabling output settings I got to see the error. I am getting this error:

image.png.102d45ed2710aa0957c38fc46dda0daf.png

Of course the Error in getting inventory part is my own. Here is my code for getting the inventory:

function GetInventory(user){
    return new Promise((resolve, reject) => {
        const {
            client,
            community,
            manager,
            details: {
              username,
              password,
              shared_secret,
            },
          } = SteamClients[user.username];
        manager.getInventoryContents(730, 2, false, (err, inventory) => {
            if (err) {
                log.debug('GetInventory', err)
                reject(err);
            } else {
                resolve(inventory);
            }
        })
    })
}

I am confused as to why this happens after some time of my bots running. I considered that maybe when the sessions expire the cookies for manager don't get reassigned, but they do. I webRelog when the websession expires, I have relog enabled (as default) and I have all the appropriate event listeners and manager's cookies are set on a new websession being established. So I don't understand why this is happening. Any ideas?

Link to comment
Share on other sites

Can you verify the sessionExpired event is actually getting emitted? It can only get emitted if the module can verify with certainty that your session isn't valid anymore; getting a private inventory response isn't sufficient verification.

Link to comment
Share on other sites

4 hours ago, Dr. McKay said:

Can you verify the sessionExpired event is actually getting emitted? It can only get emitted if the module can verify with certainty that your session isn't valid anymore; getting a private inventory response isn't sufficient verification.

Yes, I have a listener for the event and I check the steamID property. So the sessionExpired event gets handled, I don't understand why I am getting the error in that case. Here is my listener:

community.on('sessionExpired', () => {
    information.steam_webservice_connection = 'disconnected';
    log.info('LoginClient', `${user.username}'s websession expired!`)
    if (client.steamID == null) {
        log.info('LoginClient', `${user.username} was disconnected from steam! Relogging in.`)
    } else {
        client.webLogOn();
    }
})

So in this way if the websession is expired I log in again, otherwise it does nothing because I have relogging in enabled as default. Also I have a bit of code that checks the steam community steamID and steam client steamID to check if the user is connected: 

if (SteamClients[user].client.steamID == null || SteamClients[user].community.steamID == null) {
  connection = '\x1b[31mdisconnected\x1b[37m'
} else {
  connection = '\x1b[32mconnected\x1b[37m'
}

image.png.a275f07cef14a05ec59af81e11b5a330.png

and so far it seems the clients and webclients are always connected, unless steam is down. And keep in mind, as I am seeing all accounts connected, I am getting this error. So I thought it must be a cookies issue, that's why manager doesn't have access to the inventory, but then I have this listener:

client.on('webSession', (sid, cookies) => {
    information.steam_webservice_connection = 'connected';
    manager.setCookies(cookies);
    community.setCookies(cookies);
    hasWebSession = true;
    log.debug('LoginClient', `Client weblogged in ${user.username}`)
    if(isLoggedOn) {
        stratup = true;
        information.start_time = Date.now();
        resolve()
    };
})

So if the client makes a new session (and it negotiates a websession) this event should fire. And if a new websession is established from the session expiration listener, this should fire. So, in any case manager's cookies should be up to date. So I really don't understand why I am getting this error.

5 hours ago, Dr. McKay said:

Can you verify the sessionExpired event is actually getting emitted? It can only get emitted if the module can verify with certainty that your session isn't valid anymore; getting a private inventory response isn't sufficient verification.

One more thing I should probably mention is these are my options for the manager constructor:

manager: new TradeOfferManager({
    steam: this.client,
    community: this.community,
    language: 'en'
})

Would this perhaps need to be updated if a new client session/websession is established? I don't see why it should as the client and community constructors don't change, their sessions do but not the constructor themselves. But I just thought I should throw this out there.

Link to comment
Share on other sites

I have looked at several ways I thought I could prevent this error, but I am still getting it. I cannot understand why it is happening. I have even made the client weblog() when the error occurs more than 10 times in succession. Still doesn't fix it. Do you know what this error could be? Because I cannot understand what the cause is.

Link to comment
Share on other sites

On 6/23/2021 at 10:00 AM, Dr. McKay said:

The only thing that happens when a session expires is the sessionExpired event gets emitted (potentially multiple times). There isn't any other way to tell.

 

On 7/1/2021 at 1:08 AM, What Comes Around said:

I have looked at several ways I thought I could prevent this error, but I am still getting it. I cannot understand why it is happening. I have even made the client weblog() when the error occurs more than 10 times in succession. Still doesn't fix it. Do you know what this error could be? Because I cannot understand what the cause is.

Good news, well I mean the error still occurs but I know what's going on. And knowing is good :).

image.png.f7ba07b721f60b6a0afe94981451d0e7.png

As you can see, while the error did look scary being displayed 5-10 times, all accounts do get successful requests from time to time. In fact, more often than not. So the fear factor was just a result of the scale I'm working in. I am not sure why this is the error I get instead of 502, but whatever, it's not catastrophic. Problem solved.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
 Share

×
×
  • Create New...