Skip to content

Conversation

@shamil-gadelshin
Copy link
Contributor

Main changes:

  • updated runtime types: "@joystream/types": "^0.13.0",
  • updated API "@polkadot/api": "^1.26.1",
  • transaction status IsFinalized was changed to asCompleted

async freeBalance(accountId) {
const decoded = this.base.identities.keyring.decodeAddress(accountId, true)
return this.base.api.query.balances.freeBalance(decoded)
return (await this.base.api.derive.balances.all(decoded)).freeBalance
Copy link
Contributor

@Lezek123 Lezek123 Aug 28, 2020

Choose a reason for hiding this comment

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

In this context I think (await this.base.api.derive.balances.all(decoded)).availableBalance may actually be more suitable, because freeBalance = avaialble + locked and if the balance is locked it seems like it cannot be transferred or used to pay the fee.

Copy link
Member

Choose a reason for hiding this comment

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

@Lezek123 is correct. The way we are using it we were not accounting for locked balance. It is only directly called by hasMinimumBalanceOf() which is the call that is really interested in a minimum transferable balance. We can fix this in a later PR.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Leszek's solution is only a single line. I'm including the fix in the current PR.

const leadOpeningId = await api.workers.devAddStorageLeadOpening()
const leadApplicationId = await api.workers.devApplyOnOpening(leadOpeningId, aliceMemberId, alice, alice)
api.workers.devBeginLeadOpeningReview(leadOpeningId)
await api.workers.devBeginLeadOpeningReview(leadOpeningId)
Copy link
Member

Choose a reason for hiding this comment

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

this await was left out so the two transactions can be finalized in the same block.

It works because the second call doesn't need to get any values from event(s) emitted by the first transaction.
Of course the second one will fail if the first fails.

So its just a speed optimization :)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Ok. I'm rolling it back.

async freeBalance(accountId) {
const decoded = this.base.identities.keyring.decodeAddress(accountId, true)
return this.base.api.query.balances.freeBalance(decoded)
return (await this.base.api.derive.balances.all(decoded)).freeBalance
Copy link
Member

Choose a reason for hiding this comment

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

@Lezek123 is correct. The way we are using it we were not accounting for locked balance. It is only directly called by hasMinimumBalanceOf() which is the call that is really interested in a minimum transferable balance. We can fix this in a later PR.

providers[id] = new Worker(value)
}
}
const entries = (await this.base.api.query.storageWorkingGroup.workerById.entries());
Copy link
Member

Choose a reason for hiding this comment

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

love the new api

@mnaamani
Copy link
Member

mnaamani commented Sep 1, 2020

The changes look good.

To build I had to fix call to ContentId.generate() to ContentId.generate(this.api.api.registry), in:

MokoBook:storage-node mokhtar$ git diff packages/cli/src/commands/upload.ts 
diff --git a/storage-node/packages/cli/src/commands/upload.ts b/storage-node/packages/cli/src/commands/upload.ts
index 7a1ff8cfe..f0a9f7c34 100644
--- a/storage-node/packages/cli/src/commands/upload.ts
+++ b/storage-node/packages/cli/src/commands/upload.ts
@@ -96,7 +96,7 @@ export class UploadCommand extends BaseCommand {
     return {
       accountId,
       ipfsCid: await this.computeIpfsHash(),
-      contentId: ContentId.generate(),
+      contentId: ContentId.generate(this.api.api.registry),
       fileSize: new BN(this.getFileSize()),
       dataObjectTypeId,
       memberId,

@mnaamani
Copy link
Member

mnaamani commented Sep 1, 2020

I'm seeing 9 linter errors that need to be fixed, we can fix in a separate PR?

Running yarn storage-cli dev-init works as expected after the build fix.

@shamil-gadelshin
Copy link
Contributor Author

That is strange - I had successfully uploaded the video file during the testing.

@mnaamani
Copy link
Member

mnaamani commented Sep 2, 2020

That is strange - I had successfully uploaded the video file during the testing.

Is it possible that the packages wasn't rebuilt and used some pre-compiled code you had?

I noticed storage-node is the only project we have where a tsconfig.tsbuildinfo is built. And sometimes its presence is preventing some code from being recompiled if the source doesn't change.

@mnaamani
Copy link
Member

mnaamani commented Sep 2, 2020

Did some additional testing. LGTM.

One bug I just realized in the async getAllProviders() it returns all the worker ids (including the lead worker id). I opened an issue #1211

@mnaamani mnaamani merged commit e88b6a2 into Joystream:iznik Sep 2, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants