Certain nodes are only seeing service agreement bids of a specific ask (ie, node is only seeing .17 publishes when .24 publishes are also being offered)

[CosmiCloud]

trafficstars

Issue description

Random nodes on the network are only seeing 1 range of ask offers instead of all ranges. This affects multiple node operators.

Expected behavior

Nodes are able to bid on all service agreements regardless of ask price. If there are publishes for .17 and .24 then if the node has an ask of .24, it should be eligible to earn the .24 pubs and not only get stuck with the .17 pubs it will never earn anyway.

Actual behavior

The node only sees .17 publish attempts and does not have the opportunity to be r0 for .24 pubs. vice versa a node only sees .24 and does not see .17.

Steps to reproduce the problem

1. grep "service agreement bid"
2. See attached screenshot. The node on the right (green) can see only pubs with 0.24-0.25 bids (do we expect to see service agreement bid records in case bid is below node ask? i'd assume yes)
3. node on the left (red) can see only pubs with 0.17-0.18 bids and see zero 0.24-0.25 bids

Specifications

• Node version: 6.0.6
• Platform:
• Node wallet:
• Node libp2p identity:

Contact details

• Email: Node Alliance

Error logs

.24 only node: Dmitry_only_0.24_pubs_node.txt

.17 only node: Dmitry_only_0.17_pubs_node.txt

Disclaimer

Please be aware that the issue reported on a public repository allows everyone to see your node logs, node details, and contact details. If you have any sensitive information, feel free to share it by sending an email to [email protected].

[Valcyclovir]

I'm seeing the same behaviour on my nodes.

BRX, BRX88, BRX89 are only seeing 0.24 bids BRX86, BRX87 are only seeing 0.17 bids BRX86: QmV9WL9J8FEUEZznaCTK1mZuKkjP3CkRt3979fVZHbXVvm BRX87: QmRWR3W32A1eiqW7nWwcPxPbmK68VzXpyPrS7rpcjrY7SV

All 5 of them have a service ask of 0.24 but only the first 3 mentionned are able to win any commits.

This started happening about 30 hours ago. It's as if nodes are split into 2 groups, ones that can only see 0.17 service bids and the other group only 0.24.

otnode_log_BRX.txt otnode_log_BRX86.txt otnode_log_BRX87.txt otnode_log_BRX88.txt otnode_log_BRX89.txt

[botnumberseven]

only 0.24 nodes: 79 QmNqdyK4dAZg97Dy8XRZ8VAUppLJeBJdpdkUq1u8iowuUS Amado2 78 QmUSHCxxisiGipuMNqigcU64YgwiTjU9nTnvZkPPtWGeBy Amado3 80 QmPx8gKqABFQuzYTHD7Ka9uvbFvmg7hfezU8BYcUahvVUC Amado4

only 0.17 nodes: 77 QmQSmxjJL38oT6D8UHoyJzg9zhFmUtteH1uepFUZVUPKgD Amado1

[CosmiCloud]

only 0.17 node: QmSjLxW54uyPTKtJ3LZcNCmjZReKA2PyieHuuGKkkhA5vT

My only node :)

[DalSlacker]

I have the same issue Qmb44HMCYoQPkNfxxVE6rDtYv3uoKZJkp52cpfQi72BXqD only sees jobs with approx 0.17 QmTjs8wGS297NsQ9B3D42E11dUWAR8P3XsikvuKkJy8qFD only sees jobs with approx 0.24

[drMurlly]

I have the same issue, as described by CosmiCloud Identity ID: 51 Network ID: QmcmsZ76Yrm3sf6jZx7SX83W3CnWwadfYQ6YerefWAZuuH The node is only seeing 0.17 bids. My other three nodes are functioning as expected.

[hottogo]

My node QmSdi4m5SBfPU8VcTB3dB2i1HWAV6G4VdPQgo7K8xEqFWU is only recent .17 to .18 jobs and winning none as set to .24.

My other nodes seem to be fine

[br41nlet]

Thanks for the report @CosmiCloud, we're investigating it. I will get back to you with our findings or if some additional information is needed from you

[Valcyclovir]

I'm seeing the same behaviour on my nodes.

BRX, BRX88, BRX89 are only seeing 0.24 bids BRX86, BRX87 are only seeing 0.17 bids BRX86: QmV9WL9J8FEUEZznaCTK1mZuKkjP3CkRt3979fVZHbXVvm BRX87: QmRWR3W32A1eiqW7nWwcPxPbmK68VzXpyPrS7rpcjrY7SV

All 5 of them have a service ask of 0.24 but only the first 3 mentionned are able to win any commits.

This started happening about 30 hours ago. It's as if nodes are split into 2 groups, ones that can only see 0.17 service bids and the other group only 0.24.

otnode_log_BRX.txt otnode_log_BRX86.txt otnode_log_BRX87.txt otnode_log_BRX88.txt otnode_log_BRX89.txt

Just a quick follow up of my 3 working nodes, they completely stopped getting any new commits the past 12 hours. I know they are still functional since they are winning back previously won commits. A quick restart this morning fixed the problem, but this never happened before.