Getting error in retrieving inventory after some time

[What Comes Around]

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:

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?

[Dr. McKay]

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.

[What Comes Around]

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'
}

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.

[Dr. McKay]

That code all looks fine, but bear in mind that steamcommunity doesn't set the steamID property to null when the session ends like steam-user does.

[What Comes Around]

5 hours ago, Dr. McKay said:

That code all looks fine, but bear in mind that steamcommunity doesn't set the steamID property to null when the session ends like steam-user does.

Oh I see, what happens in that case? Is there a similar property I could use for steamcommunity?

[Dr. McKay]

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.

[What Comes Around]

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.

I see, thank you!

[What Comes Around]

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.

[What Comes Around]

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 .

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.