feat: allow customers to create more than one space #246
Conversation
this is just a matter of changing how we generate subscription IDs. they are now generated from customer AND consumer, which means they will be unique for a given customer/consumer pair - in other words, a given customer will only be able to provision a given space one time.
this just updates the test `ProvisionsStorage` to behave the way the production `ProvisionsStorage` does as of storacha/w3infra#246
View stack outputs
|
|
Is there no test for this behaviour that needs to be updated? |
|
yea, surprisingly there isn't - in retrospect I definitely should have added one during the migration from D3 but it looks like I overlooked it! There is a test in I do think it would be a good idea to have a test that verifies a user can create multiple spaces - thinking through that I think the original test slipped through the cracks because most of the service-level tests live in w3up, but this is explicitly a behavior we'd like implementors to be able to control with their |
|
ok - updated with an integration test! |
upload-api/stores/provisions.js
Outdated
| * by deriving subscription ID from customer AND consumer) in the future | ||
| * or by other providers for flexibility. | ||
| * uses a CID generated from `customer` and `consumer` which ensures each customer | ||
| * will get at most one subscription per space. |
There was a problem hiding this comment.
It'll also allow existing spaces that have already been provisioned to be provisioned again...can we fix/avoid?
There was a problem hiding this comment.
oh HMMM good point, maybe this should just be generated from "consumer" so that a given space can only ever be provisioned once... will make that tweak and add a test!
There was a problem hiding this comment.
oh it turns out we already check for this in provisioning! I would like to leave the door open for a "multi-payer" space in the future so I think we should leave as currently implemented!
@alanshaw pointed out that as implemented, a space could be registered by more than one user, which would make billing pretty challenging. I tried to write a test for this, but w3up-client and access-client go to some lengths to stop a user from registering another user's space so this is a deeper rabbithole than I'd like to go down for now.
|
@travis btw I tested w3infra from your commit at aafebb2 locally and confirmed that it resolves storacha/w3cli#112 I'll test again once deployed |
this just updates the test `ProvisionsStorage` to behave the way the production `ProvisionsStorage` does as of storacha/w3infra#246
this is just a matter of changing how we generate subscription IDs. they are now generated from customer AND consumer, which means they will be unique for a given customer/consumer pair - in other words, a given customer will only be able to provision a given space one time.