Skip to content

Conversation

@markspanbroek
Copy link
Contributor

@markspanbroek markspanbroek commented Dec 4, 2025

  • Simplifies availability by removing reservations, and having only single set of sales terms.
  • Introduces MarketplaceNode as the main interface for sales, purchasing and validation.
  • Removes the old contract interactions abstraction.

@markspanbroek markspanbroek force-pushed the refactor-marketplace-interface-3 branch from 585e97f to a3036db Compare December 4, 2025 09:29
@markspanbroek markspanbroek force-pushed the refactor-marketplace-interface-3 branch from a3036db to c71adee Compare December 4, 2025 10:21
@markspanbroek markspanbroek changed the title refactor(marketplace)!: new interface part 2 refactor(marketplace)!: new interface part 3 Dec 4, 2025
@markspanbroek markspanbroek marked this pull request as ready for review December 4, 2025 14:39
@benbierens benbierens self-requested a review December 4, 2025 15:55
Copy link
Contributor

@benbierens benbierens left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I like where this is going.

method unsubscribe*(subscription: OnChainMarketSubscription) {.async: (raises: []).} =
try:
await noCancel subscription.eventSubscription.unsubscribe()
except ProviderError:
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just for my info: when does ProviderError happen?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The base method Subscription.unsubscribe() lists it as one of the errors that may be raised. JsonRpcProvider uses local subscriptions, which never raise an exception when unsubscribing, but we're using the generic Provider here.

await clock.start()
success clock
except CancelledError as error:
raise error
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If you omit these lines "except CancelledError" ... "raise error", wouldn't it result in the same thing?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Unfortunately not. CancelledError is a subtype of CatchableError, so it would be picked up by except CatchableError.

import ../utils/json
import ../manifest
import ../units
import ../clock
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If this import wasn't required but now it is, I don't see why. :o

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, we have too much export <module> code everywhere, so there are lots of surpising things in scope. And they sometimes surprisingly go out of scope when you remove something unrelated. This particular instance could very well be caused by the removal of contract interactions.

validator = some ValidatorInteractions.new(clock, validation)

s.archivistNode.contracts = (client, host, validator)
s.archivistNode.marketplace = marketplace
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The changes in this file make me so happy...

check expectedData.len == data.len
check expectedData == data

test "slot repair calls onBatch callback and sets expiry":
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I know this test isn't exactly a pearl of coding, but...
it was covering a testnet-discovered issue in which blocks resulting from repair had default-expiry instead of contract-duration-expiry.

I can disable node.nim:714 if err =? (await updateExpiry(@[blk])).errorOption: and I don't think any tests will catch this. Now I am entirely in favor of destroying this code. And the whole expiry system is being redesigned. But is there a way to cover this behavior? Or is it not worth the effort at this time?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, I agree. I intend to bring these tests back in #73, because then there is a nice interface to test against.

let request = await testbed.request.nodes(3).submit(node)
let size = request.dataset.data.len
# start request
# 9 slots makes the odds that all slots are filled by one node negligable
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This smells like it could go wrong once in a great while.
What I did is: calculate the slot size and set each provider availability to be slot size + 10%
Then have nodes = 3 and 4 providers.
You can use the slotFilled events to find any one provider and stop it and you're also guaranteed that there's capacity for repair.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, this test did something similar before. But now we can no longer set the provider availability size, because with the changes in this PR we can only set the repostore quota. And the node will simply try to sell the entire quota. I tried restricting the quota for the nodes in this test, but that didn't work because each node would try to fill 3 slots simultaneously (3 slotqueue workers). So that's why I chose these request parameters. I came to a rough estimate that this test could go wrong once every 250 000 runs, which I deemed acceptable.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants