getConfirmations gives [] even if there are "Awaiting Mobile Confirmation" trades

[lopataz]

So, I implemented getConfirmations as follow:

function getconf(){

 var timekey=Math.round(Date.now() / 1000);
        var confirmationkey = SteamTotp.getConfirmationKey(identitySecret, timekey, "conf");

        community.getConfirmations(timekey, confirmationkey, function(err2,confirmations){
            if(err2){
                console.log(err2);
            }else{
                console.log(confirmations); //Gives '[]' even if there are waiting trades
                confirmations.forEach(function(conf,index,array){
                    setTimeout(function(conf){
                        var timekey2=Math.round(Date.now() / 1000);
                        var confirmationkey2 = SteamTotp.getConfirmationKey(identitySecret, timekey2, "allow");

      community.respondToConfirmation(conf.id,conf.key,timekey2,confirmationkey2,true,function(err){
                            console.log(err);
                        });
                    },index*1500,conf);
                });
            }
        });
}

I call getconf every 40 seconds
But when I send some offers sometimes I don't get the confirmations for it.
It does it very frequently! and the confirmations never appears, but the next confirmation appear ometimes.
Here is the screenshot of the sent offer : https://gyazo.com/d1a842e92af53817e2aa939498d0a162
Here is the screenshot of the community.getConfirmations response (empty array []): https://gyazo.com/2a41c7211a53d3971341bea3cdd1ab04

[apladas]

Can confirm, this happens with me also.

[charredgrass]

Also happens with me and I'm polling confirmations using startConfirmationsChecker - the newConfirmation event is never called.

[DoctorMcKay]

Like nothing ever, or just sometimes?

[apladas]

It happens for some trade offers, not all, like 80-90% of the confirmations work and show up and the other just disappear.

[DoctorMcKay]

Sounds like a problem on Steam's end. I've experienced stuff like this, but changing the device ID in the URL fixed it for me. For that reason, the module uses a different device ID every time it requests the page.

[Lagg]

Can confirm reproducability of this.

Edit: newConfirmation is emitted upon a restart /or restart of the login flow. But then never again.

[Lagg]

Alright so it will emit newConfirmation one more time if I call checkConfirmations. Not exactly in the spirit of clean polling. But I'm busy debugging my own stuff right now. Wish I could help more :(

[DoctorMcKay]

@Lagg Is it not polling or something? I can't imagine what checkConfirmations would do that regular polling wouldn't.

[Lagg]

Honestly not sure right now. Something strange is happening with steam. When I enabled trade confirmations for an account, it gave a "can not act on confirmation" error, but showed the trade offer as approved (as in literally ready state 2 and showing confirmation method 2). Then when I disabled them it didn't even send me an email to opt out and just did it, then when I tried enabling them again every offer that was marked sent reverted to needing mobile confirmations, and yet steam is not returning any confirmations whatsoever. So needless to say it could be a deeper problem.

[DoctorMcKay]

Agreed, trading is completely screwed right now for me. I send an offer from an alt to my main account, confirm it on the alt, and it appears Active to the alt. But my main account doesn't see it at all.

I also did a real-time trade between the two with only the alt losing items. Confirmed it, and the offer went into that same Active-but-only-shows-up-to-me state.

[Lagg]

Um... Okay... So it looks like steam sends opt-out confirmation as a confirmation... Didn't know that. Explains the lack of link

    title: 'Confirm Opt-Out of Trade Confirmation Emails',
    receiving: '',
    time: 'Just now',
    icon: '' } ]

Which I was able to accept just fine, but actual offers are problematic. This is crazy.

[Lagg]

One other thing possibly worth noting. I can't figure out the relationship or lack thereof of accounts that do this. My test bot gets and accepts confirmations just fine. And this is a test bot - so never been touched besides the prerequisite $5. It didn't even have any items at first either. I find it insane that valve doesn't have this stuff figured out before their own deadline.

[halipso]

same happens to me.
any way to fix it?

[Lagg]

Oh there's always a way to fix this stuff. It's just that Valve doesn't generally like taking responsibility for their bugs, especially in situations where deadlines are imposed for activation. Just continue trying to figure out attributes that could be causing this and report any suspicious data in this issue. It'll help all of us, especially mckay.

[lopataz]

I did a function to resend not confirmed offers

[halipso]

Yeah i did the same.
Just resending an offer.

[Lagg]

You guys will want to be careful about when you cancel offers starting on the 9th. I believe there's an account lock.

[scholtzm]

Hopefully it should be safe to cancel if you have 2FA+mobile confs enabled. (???)

[Lagg]

Nope, I think this was actually part of the outrage that started the petition stuff in the first place. The lock occurs even then from what I understand. Of course, since there's no unambiguous documentation available we can't be sure until it happens.

[scholtzm]

With the limit of 30 pending trade offers, if cancelling was punished with a 3 day lock, every active bot will get locked down pretty fast. Hopefully, that's not the case.

[DoctorMcKay]

I have spoken with a Valve employee regarding this. You cannot cancel escrow'd trades individually. There will be a "I was hijacked, lock everything down" button that cancels all escrow'd trades and active trade offers. As long as you don't click that, there's no trade lockdown.

[apladas]

Escrow'd trades are the one's that have 3 day limit? If I cancel the trades that have pending mobile confirmation then I'm fine?

[charredgrass]

@kenzik Yes, you should be fine - but we really don't know that much about the technicalities of Escrow until it's in effect.

[Lagg]

Hopefully the same is not true of this current bug.

[scholtzm]

You cannot cancel escrow'd trades individually.

So once the trade gets into escrow, the items are locked for 3 days and we cannot get them back?

[andrewda]

@scholtzm Unless you lock your account and cancel all active and escrow'd trades, yes, I think that's correct.

[scholtzm]

I have also noticed that I was unable to retrieve trade offer IDs for certain confirmations. The retrievals that failed were for trades that were roughly 50 minutes old at the time.

[andrewda]

@scholtzm Could this be because of how messed up trade offers were yesterday? There were a ton of issues on Steam's end yesterday, so that might be why those ID retrievals failed.

[Lagg]

Can anyone confirm/disconfirm that the issue with the ghost-whisperer shit going on with the trade offers and confirmations is resolved? I've been poking around the sub the reddit thread is on and people were steadily reporting the issue but now it appears to have dropped off. I can't test myself at the moment since my two test bots always worked and I still saw a white page on the confirmations in the official app. But that could just as easily indicate steam's "standard" timeouts.

[Lagg]

If the device ID is at all required by Valve to be anything besides whatever the client feels like. I'm just going to say this now: They already failed at utilizing a very awesome OTP spec properly and there's a major bug 2 days before release. This would be bad, possibly with security implications. Because if the ID can be used in any way for authentication, keying or is any way compared to an identity datum they've made the key weaker by default. Despite the quite frankly betrayed feeling and loss of respect, I'm pretty sure they're smarter than this.

I hope :(

Edit: Has only generating the device ID upon login been considered? I know, even less assurance of non-stale page data. But it's either that or none apparently.

[Desp163]

What happens if first confirmation didn't pop and then you send second trade? Does two notifications show up?
Because this is how random steam trades and emails were getting stuck for a while.

[lopataz]

@Desp163
The second trade appear without the first one,
The first trade will never pop.

Sometimes it's 3 consecutive trades that don't appear. But the next trades confirmations will appear

[DoctorMcKay]

v3.14.1 uses truly-random machineids, maybe see if that resolves your issues.

[DoctorMcKay]

Just a note: I've deployed 3.14.1 into production and I'm experiencing about 5% failure. Failures seem to be clustered around each other.

[scholtzm]

Does the trade confirmation just never appear?

[Miwwa]

I use always one deviceId for one bot, but have same issue

[DoctorMcKay]

I'm not totally sure. I just check my confirmations 5 times after I send an offer, and if it's not there I just cancel it.

[Lagg]

That'll work great until one starts running into issues with the servers throttling them. Really surprised in a not-good way that it's 1 day before this thing and I still see blanks even in the app sometimes. Can't say I have a better idea I suppose.

[DoctorMcKay]

After running overnight I have a failure rate of 3.6%.

[Lagg]

Well your stat report was good enough for me to trust so I bit my lip and bent over and enabled confirmations for the same bot I mentioned earlier.

And it accepted them fine. This inconsistent behavior is really what is the worst. Anyway, not sure if the offer is invisible to the other party yet.

Edit: The other party accepted, so apparently it's not. Can people please confirm if their bots previously experiencing these issues are now fixed so we can get a rough idea of what workarounds must be done for other problems, if any.

[emko]

Does anyone know if the Android app has the same problem?

[scholtzm]

@DoctorMcKay What was the failure rate for you before Escrow? Assuming trades must have failed occasionally even then.

[laterbreh]

I can't confirm nor deny that this is an issue for me unfortunately. I've confirmed over 100 trades today and they all went through... God knows when we go to production the problem will arise.

The point of my post is just to add some more information. This is what I am doing:

Info used to login:
var code = SteamTotp.generateAuthCode('your code here', timekey);
var timekey = Math.round(Date.now() / 1000);

(using steam user on the client.on('webSession'))
community.setCookies(cookies);
community.startConfirmationChecker(10000, identity_hashed);
identity_hashed is var identity_hashed = identity_secret.toString('base64');

I also included this from the documentation:

community.on('confKeyNeeded', function(tag, callback) {
var time = Math.floor(Date.now() / 1000);
console.log('Conf Key Needed');
callback(null, time, SteamTotp.generateAuthCode('your key here', time, tag));
});

and finally
community.checkConfirmations(); after each sent trade.

EDIT: I am using trade-offer-manager to send the trades also.

I will continue to do more testing today... I hope the information I provided will be useful to someone here running into the problem. I'll report back what my error rate is once I deploy this to production when escrow goes live.

Good luck everyone.

[Lagg]

Might as well leave my own then: I've successfully enabled confirmations on 4 bots of a fleet of 25. All 4 of which were experiencing the confirmations problem (and additionally a plethora of 401s and "cannot act on confirmation"s). They've all made several offers between the time I enabled them and now, and none slipped through. The code I'm using is mildly more complex than @laterbreh 's due to handling the events myself, but functionally it's the same as what the automatic ones do. I also do the callbacks for confKeyNeeded in a similar manner.

Will likely report back here if I can when the rest are enabled. But things are looking optimistic. Don't know if this is a result of your fixes or what @DoctorMcKay but thanks for the modules regardless.

Edit: Forgot to mention this but it's really nothing new in the grand scheme of things. There are sometimes HTTP 401s for seemingly no reason (even logging in while the bot is elsewhere doesn't cause them). My approach to getting around this is emitting something like "shitsBroke" and then brutally restarting the login flow. Seems like there's something on steam that is globally invalidating sessions for reasons other than concurrent logins.

[laterbreh]

@Lagg After reading your thread something hit after re-reading my bot. I am still using a sentry file. My plan was to remove this since i assumed with the steam-totp it would be irrelevant, but I forgot to remove this. So my bot is still using a sentry file, and was using one all day when I was doing testing.

I have no idea if that makes the difference or not but I thought I would share: client.setSentry(fs.readFileSync('sentry'));

Ill continue to update as I find out more.

@DoctorMcKay you are a god by the way, and I just wanted to thank you for all the work you have done. What would be the best way to donate to your efforts?

[Lagg]

I assume they still are relevant. I mean we still use steamMachineAuth which is more likely than not just a hash of a sentry valve has on their servers while the client has its own. But yeah in any case I'm using the same call right before logOn.

Edit: and here is McKay's PP link @laterbreh . I think he deserves a good donation or two. I certainly plan to when I'm not such a stingy bastard /or not spending annoying lump sums due to current real life happenings.

[Lagg]

Update: I enabled the whole fleet, all seems to be well. Or at the very least the same errors and issues aren't happening. I would like to think that means it was fixed and recommend that this be closed. But I don't trust valve nearly enough for that. Especially after what happened that resulted in this thread in the first place, so take it how you will.

[DoctorMcKay]

@scholtzm That number is only the rate of failure among offers that were sent successfully, but couldn't be confirmed.

Since about 3 PM today I have a confirmation failure rate of about 5.5% out of nearly 20,000 offers.

I'm closing this since it appears to be as resolved as it's going to be without action from Valve. Continued discussion and observations are encouraged if you have them.

[andrewda]

@lopataz I think it is in fact Steam. I have witnessed two occurrences (out of at least 150 trades) where I simply never receive the trade confirmation, and the only way to get it is to cancel and rerun the trade. I've been using Steam Mobile confirmations since Day 1 that they were released, so I have a lot of trades under my belt with it. In my experience at least, the success rate is significantly higher in the app, but still not perfect.

[Lagg]

Because the community has been helpful to me in many ways during this update I might as well try to continue reporting what I notice since I have a pretty decent testing set. When updating to fix the escrow_end_date attribute error (thank you so goddamn much for the prompt fix & merge @DoctorMcKay and @lincsanders - loving that I've only needed to downstream patch once for this) I noticed that sometimes both confirmations and trade offer URLs will return 404s, thus leading to the offerID attr being null and offer page itself claiming invalidity. However, steam still responds perfectly in line with what it usually does when accepting confirmations. So I'm not sure what kind of effect it's having on the offer. But it definitely still confirms it and returns no data indicating errors besides the nulled offerID. So account for that if you must.

[DoctorMcKay]

1.1% failure out of around 23k confirmations in past 24 hours. It seems to be getting more stable.

[timavo]

Maybe this can be useful for debugging: I step-by-step build my bot to confirm outstanding trade offers and experienced some weird behaviour regarding this problem.

In the first step I used the following to get all the trade offers which need to be confirmed:

time_conf = Math.floor(Date.now() / 1000);
key_conf = SteamTotp.getConfirmationKey(identity_secret, time_conf, 'conf');

community.getConfirmations(time_conf, key_conf, function (err, confirmations) {
    console.log(err);
    console.log(confirmations);
});

All went fine and I got an array of CConfirmation objects multiple times (didn't confirm them).

Then I used the following to get the trade offer IDs for each confirmation object:

time_conf = Math.floor(Date.now() / 1000);
key_conf = SteamTotp.getConfirmationKey(identity_secret, time_conf, 'conf');

community.getConfirmations(time_conf, key_conf, function (err, confirmations) {
    if (err) { logger.error(err); return; }
    console.log(confirmations);

    time_details = Math.floor(Date.now() / 1000);
    key_details = SteamTotp.getConfirmationKey(identity_secret, time_details, 'details');

    confirmations.forEach(function(confirmation) {
        confirmation.getOfferID(time_details, key_details, function(err, offerID) {
            if (err) { logger.error(err); return; }
            console.log(offerID);
        });
    });
});

At first I got the error [Error: Cannot load confirmation details] on each confirmation.getOfferID() because I used the tag 'conf' for getting the details. Directly after changing the tag to 'details' I suddenly got an empty array as response of community.getConfirmations().

Since then I'm not able to retrieve the information for the 'old' trade offers. After sending two new ones I can get the offerID for one of them. The other one returns the error Error: Cannot load confirmation details.

[DoctorMcKay]

You need to use conf for getConfirmations and details for getOfferID. You can't use the same for both.

[timavo]

That's what I am doing.

[scholtzm]

@DoctorMcKay 1.1% seems to be pretty acceptable, thanks for the stats.