Trade hold duration check made sense, but back when we were fetching inventories ourselves. Now, it's much better to find match first, as we have the full data loaded, and only if match is found, check user next.
I don't recall why we needed that ShouldSendHeartBeats condition here before, it causes the routine to run always if the bot is currently not listed, which is unwanted e.g. if the server tells user to go away, or due to any other reason.
* New inventory fetching
* use new method everywhere
* Store description in the asset, add protobuf body as a backing field for InventoryDescription, add properties to description
* parse trade offers as json, stub descriptions, fix build
* formatting, misc fixes
* fix pragma comments
* fix passing tradable property
* fix convesion of assets, add compatibility method
* fix fetching tradeoffers
* use 40k as default count per request
* throw an exception instead of silencing the error
* Good start
* Misc
* Make ApiAuthenticationMiddleware use new json
* Remove first newtonsoft dependency
* Pull latest ASFB json enhancements
* Start reimplementing newtonsoft!
* One thing at a time
* Keep doing all kind of breaking changes which need to be tested later
* Add back ShouldSerialize() support
* Misc
* Eradicate remaining parts of newtonsoft
* WIP
* Workaround STJ stupidity in regards to derived types
STJ can't serialize derived type properties by default, so we'll use another approach in our serializable file function
* Make CI happy
* Bunch of further fixes
* Fix AddFreeLicense() after rewrite
* Add full support for JsonDisallowNullAttribute
* Optimize our json utilities even further
* Misc
* Add support for fields in disallow null
* Misc optimization
* Fix deserialization of GlobalCache in STD
* Fix non-public [JsonExtensionData]
* Fix IM missing method exception, correct db storage helpers
* Fix saving into generic databases
Thanks STJ
* Make Save() function abstract to force inheritors to implement it properly
* Correct ShouldSerializeAdditionalProperties to be a method
* Misc cleanup
* Code review
* Allow JSON comments in configs, among other
* Allow trailing commas in configs
Users very often add them accidentally, no reason to throw on them
* Fix confirmation ID
Probably needs further fixes, will need to check later
* Correct confirmations deserialization
* Use JsonNumberHandling
* Misc
* Misc
* [JsonDisallowNull] corrections
* Forbid [JsonDisallowNull] on non-nullable structs
* Not really but okay
* Add and use ToJson() helpers
* Misc
* Misc
Those are usually stash accounts, and while we still want to match them, we can leave them only as a last resort if no other bots are available.
This decreases chance of hitting a bot that was just recently turned off or had its items traded away, as what usually happens with such accounts.
It was possible before if the inventory state was the same as previously announced, even if server purged the info long time ago. Also, add required logic for recovery if that happens regardless.
We can keep inventory checksum before deduplication in the cache. If it's determined to be the same, then our inventory state didn't change, so it also doesn't make much sense to ask server for set parts and announcement.
* Initial implementation of announce with diff
* Add missing logic pieces
* Change in logic
* Fix checksums
* Add deduplication logic
* Update SetPart.cs
* Use standalone endpoint for diff
* Use different hashcode impl
* Update AssetForListing.cs
* Misc
* Push all the changes for this to finally work
* Use original index rather than self-calculated
ASFB makes some calculations based on index, it's better for us to have holes rather than hiding skipped items.
* Handle edge case of no assets after deduplication
* Remove dead code
* Address trim warnings
* Misc optimization
Make it so the design actually follows what Steam gives us now. There is no need for standalone Confirmation object anymore, rather re-use what Steam gives us. Optimize parsing type, expose it as public API. Small breaking change in HandleConfirmations() action.
Initially I added check against zero as bullet-proofing for unexpected events, but some accounts actually report 0.
Assume 0 is older than needed, if we don't have information available, we shouldn't jump to conclusions.
