🐞 [Bug]: Reserve a node as dedicated, then un-reserve it, it appears as shared and not dedicated

[mik-tf]

Is there an existing issue for this?

• I have searched the existing issues

which package/s did you face the problem with?

Dashboard

What happened?

Reserve a node as dedicated, then unreserve it, it appears as shared and not dedicated

Steps To Reproduce

1. reserve dedicated node
2. un-reserve it
3. it appears as shared and you can't reserve it as dedicated anymore
4. note that it can "fix" itself with some time, but it comes back if you redo the steps 1-2

which network/s did you face the problem on?

Main

version

latest

Twin ID/s

No response

Node ID/s

7510

Farm ID/s

No response

Contract ID/s

No response

Relevant screenshots/screen records

Relevant log output

-

[ramezsaeed]

This is by design; if the node doesn't have any loads it can appear as shared or dedicated.

[mik-tf]

The situation is that here a node that has no workload, that could be reserved as dedicated in the past, cannot be reserved as dedicated anymore. If it is by design, imo we need to adjust the design.

I could reserve the node, then I un-reserved it, then I could no longer reserve it.

So imagine you want to use a node for its GPU features, well you just can't, because you need to reserve it as dedicated node to use the GPU, and the function sometimes disappears.

Thank you for your time.

[xmonader]

Empty = (0 workloads), then the nodes are available for rent and for shared hosting if someone created even a network workload that node won't be available for full rental. if that's the case, please reopen the ticket.

[mik-tf]

Update

• Check this graphql basic search:

• Check this grid proxy basic search (all deleted contracts, nothing else than deleted contracts):
  • https://gridproxy.grid.tf/contracts?node_id=7510

Notes

• Maybe the initial issue was not clear: I reserved the node and deployed on it, deleted all contracts, and then un-reserved it. The moment after it was not possible to reserve it, i.e. it was implied there were no other contracts in a practical sense, but I think the screenshots above show this more clearly. In that regard, it seems there is an issue. Thanks.

[mik-tf]

Update

• After many hours passed, I can reserve again the node

• Hypothesis: Grid proxy showed 0 contracts, there were no "active" contracts, but somehow the grid thinks deleted contracts are still relevant and it's not possible to reserve the node until the "cache" clears up

[mik-tf]

Remove the process_wontfix. We can see there were no active contracts on the node, and it still showed as shared and not dedicated + users could not reserve the node. It should be fixed, otherwise people can't rent a node with no contracts. As you said @xmonader I reopened it since there were no contracts on the node (all contracts were deleted contracts).

[AhmedHanafy725]

tested on https://next.dashboard.grid.tf and worked fine

Screencast.from.02-25-2025.02.08.14.PM.webm

[mik-tf]

Perhaps it is fixed with the new dashboard. But I also know @delandtj and @ashraffouda were testing the GPU node of our partner today and the same thing happened: they un-reserved the node, they even without any contracts, they could not re-reserve the node. Then Ashraf could rent it through a quick Go program. This means the issue is perhaps with gridproxy as @scottyeager hinted.

[Omarabdul3ziz]

i tested the flow on multiple nodes and it works fine.

• ashraf unreserved the node you mentioned "dev:320 btw" and i could reserve it in no time (from the dashboard) marked as rentable in the proxy.
• also reserved node 163, deployed some contracts, deleted the contracts, and unreserved the node. i could deploy it again and marked as rentable in the proxy.
• without reserving, i deployed some contracts on node 163, it became a "shared/ non-rented/non-rentable" node then deleted the contracts and it is back as rentable

changes are reflected in no time on proxy. i couldn't catch any errors/delays. could you mention a specific node that show this problem i could debug further on it?

[mik-tf]

Of course, node 7510 on mainnet, as shown in the picture in the issue. It happened with that one. Sorry for late reply, was coming back from EthDenver.

[mik-tf]

@Omarabdul3ziz currently it is happening to node 7510:

Lmk if you need anything more.