feat: merge master (no squash) #2481
Conversation
WalkthroughThis PR makes several refactoring and documentation updates across multiple packages. In configuration files, it updates comments (e.g. adding “Update sinon” to the lodash.get note in .yarnrc.yml) and adds ES2020 environment settings in ESLint configs. Numerous protocol buffer and JS DAPI client files now convert number types to string or BigInt for improved precision, with updates to getters, setters, and JSDoc annotations. The changes also include new classes (e.g. DataContractHistoryEntry, ChainStatus, etc.), adjustments in test assertions and fixtures, and minor code streamlining in the Dash SDK and wasm‑dpp modules. Changes
Sequence Diagram(s)sequenceDiagram
participant Client as Client
participant GRPC as GRPC Transport
participant Factory as getStatusFactory
participant Response as GetStatusResponse
Client->>GRPC: Request status information
GRPC-->>Factory: Return proto status payload
Factory->>Factory: Parse proto data & instantiate status classes
Factory->>Client: Return GetStatusResponse with components (VersionStatus, NodeStatus, ChainStatus, NetworkStatus, StateSyncStatus, TimeStatus)
Possibly related PRs
Poem
Tip CodeRabbit's docstrings feature is now available as part of our Pro Plan! Simply use the command ✨ Finishing Touches
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 6
🧹 Nitpick comments (23)
packages/js-dapi-client/lib/methods/platform/getStatus/NodeStatus.js (2)
1-9: Add input validation and make properties readonly.Consider adding type validation in the constructor and making properties immutable:
class NodeStatus { /** * @param {string} nodeId - Node ID * @param {string=} proTxHash - Node's proTxHash + * @throws {TypeError} If nodeId is not a string */ constructor(nodeId, proTxHash) { + if (typeof nodeId !== 'string') { + throw new TypeError('nodeId must be a string'); + } + if (proTxHash !== null && typeof proTxHash !== 'string') { + throw new TypeError('proTxHash must be a string or null'); + } - this.nodeId = nodeId; - this.proTxHash = proTxHash || null; + Object.defineProperty(this, 'nodeId', { + value: nodeId, + writable: false, + }); + Object.defineProperty(this, 'proTxHash', { + value: proTxHash || null, + writable: false, + }); }
11-16: Enhance JSDoc with more details.Add more comprehensive documentation:
/** + * Get the unique identifier of the node * @returns {string} Node ID + * @example + * const status = new NodeStatus('node123'); + * console.log(status.getNodeId()); // 'node123' */ getNodeId() { return this.nodeId; }packages/js-dapi-client/lib/methods/platform/getStatus/NetworkStatus.js (1)
1-36: Add input validation in the constructor.The implementation is well-structured but could benefit from input validation to ensure data integrity.
constructor(chainId, peersCount, listening) { + if (typeof chainId !== 'string' || chainId.trim().length === 0) { + throw new Error('chainId must be a non-empty string'); + } + if (!Number.isInteger(peersCount) || peersCount < 0) { + throw new Error('peersCount must be a non-negative integer'); + } + if (typeof listening !== 'boolean') { + throw new Error('listening must be a boolean'); + } this.chainId = chainId; this.peersCount = peersCount; this.listening = listening; }packages/js-dapi-client/lib/test/fixtures/getStatusFixture.js (2)
1-3: Add JSDoc description for the function.The JSDoc comment block is empty. Add a description explaining the purpose and usage of this fixture.
/** + * Returns a fixture for testing status responses with mock data including version, + * node, chain, network, stateSync, and time information. + * @returns {Object} The status fixture object */
31-31: Standardize numeric type handling for block heights.Some block heights are strings while others are numbers. Consider standardizing all block heights as strings for consistency.
- latestBlockHeight: '94461', + latestBlockHeight: BigInt('94461').toString(), - maxPeerBlockHeight: '94461', + maxPeerBlockHeight: BigInt('94461').toString(),Also applies to: 35-35
packages/js-dapi-client/lib/methods/platform/getStatus/TimeStatus.js (2)
2-7: Enhance JSDoc documentation for better clarity.The JSDoc comments could be more descriptive about:
- The purpose and significance of each time value
- The units used (milliseconds, seconds, etc.)
- The relationship between these different time measurements
8-18: Add input validation for time values.Consider adding validation to:
- Ensure local time is not null or undefined (required parameter)
- Validate that time values are not negative
- Consider using a consistent type (bigint) for epoch instead of number
Example validation:
constructor( local, block, genesis, epoch, ) { + if (local == null) { + throw new Error('Local time is required'); + } + if (typeof local !== 'bigint') { + throw new Error('Local time must be a BigInt'); + } + if (local < 0n) { + throw new Error('Time values cannot be negative'); + } this.local = local; this.block = typeof block === 'bigint' ? block : null; this.genesis = typeof genesis === 'bigint' ? genesis : null; - this.epoch = epoch || null; + this.epoch = typeof epoch === 'bigint' ? epoch : null; }packages/js-dapi-client/test/unit/methods/platform/getIdentity/GetIdentityResponse.spec.js (1)
82-89: LGTM! Consider reducing assertion duplication.The metadata assertions correctly use BigInt for numeric fields. However, there's duplication of these assertions between test cases.
Consider extracting the repeated metadata assertions into a helper function:
function assertMetadata(actualMetadata, expectedMetadata) { expect(actualMetadata.getHeight()) .to.deep.equal(BigInt(expectedMetadata.height)); expect(actualMetadata.getCoreChainLockedHeight()) .to.deep.equal(expectedMetadata.coreChainLockedHeight); expect(actualMetadata.getTimeMs()) .to.deep.equal(BigInt(expectedMetadata.timeMs)); expect(actualMetadata.getProtocolVersion()) .to.deep.equal(expectedMetadata.protocolVersion); }This would reduce duplication and make the tests more maintainable.
Also applies to: 109-116
packages/js-dapi-client/lib/methods/platform/getStatus/StateSyncStatus.js (4)
39-44: Fix JSDoc comment for getRemainingTime methodThe JSDoc comment is incorrect. It should describe the remaining time rather than total synced time.
/** - * @returns {bigint} Total synced time + * @returns {bigint} Remaining time to sync */
60-65: Fix JSDoc comment for getSnapshotHeight methodThe JSDoc comment is incorrect. It should describe the snapshot height rather than chunk process average time.
/** - * @returns {bigint} Chunk process average time + * @returns {bigint} Snapshot height */
67-72: Fix JSDoc comment for getSnapshotChunkCount methodThe JSDoc comment is incorrect. It should describe the snapshot chunks count rather than chunk process average time.
/** - * @returns {bigint} Chunk process average time + * @returns {bigint} Snapshot chunks count */
81-86: Fix method name inconsistencyThe method name
getBackfilledBlockTotaldoesn't match the property namebackfillBlocksTotal(singular vs. plural). Consistency would improve code clarity./** - * @returns {bigint} Backfill blocks total + * @returns {bigint} Backfilled blocks total count */ -getBackfilledBlockTotal() { +getBackfilledBlocksTotal() { return this.backfillBlocksTotal; }packages/js-dapi-client/lib/methods/platform/getStatus/VersionStatus.js (2)
11-27: Add input validation in constructor.The constructor accepts multiple parameters but lacks validation. Consider adding type and value checks to ensure data integrity.
constructor( dapiVersion, driveVersion, tenderdashVersion, tenderdashP2pProtocol, tenderdashBlockProtocol, driveCurrentProtocol, driveLatestProtocol, ) { + if (typeof dapiVersion !== 'string' || !dapiVersion) { + throw new Error('dapiVersion must be a non-empty string'); + } + if (typeof tenderdashP2pProtocol !== 'number') { + throw new Error('tenderdashP2pProtocol must be a number'); + } + if (typeof tenderdashBlockProtocol !== 'number') { + throw new Error('tenderdashBlockProtocol must be a number'); + } + if (typeof driveCurrentProtocol !== 'number') { + throw new Error('driveCurrentProtocol must be a number'); + } + if (typeof driveLatestProtocol !== 'number') { + throw new Error('driveLatestProtocol must be a number'); + } this.dapiVersion = dapiVersion; this.driveVersion = driveVersion || null; this.tenderdashVersion = tenderdashVersion || null; this.tenderdashP2pProtocol = tenderdashP2pProtocol; this.tenderdashBlockProtocol = tenderdashBlockProtocol; this.driveCurrentProtocol = driveCurrentProtocol; this.driveLatestProtocol = driveLatestProtocol; }
2-10: Enhance JSDoc comments with more descriptive information.The JSDoc comments could be more descriptive to better explain the purpose and format of each parameter.
/** - * @param {string} dapiVersion - DAPI version - * @param {string=} driveVersion - Drive ABCI version - * @param {string=} tenderdashVersion - Tenderdash version - * @param {number} tenderdashP2pProtocol - Tenderdash Protocol Version - * @param {number} tenderdashBlockProtocol - Tenderdash Block Version - * @param {number} driveCurrentProtocol - Current Dash Platform (Drive) protocol version - * @param {number} driveLatestProtocol - Next Dash Platform (Drive) protocol version + * @param {string} dapiVersion - DAPI version in semver format (e.g., '1.0.0') + * @param {string=} driveVersion - Drive ABCI version in semver format (e.g., '1.0.0') + * @param {string=} tenderdashVersion - Tenderdash version in semver format (e.g., '1.0.0') + * @param {number} tenderdashP2pProtocol - Tenderdash P2P Protocol Version number + * @param {number} tenderdashBlockProtocol - Tenderdash Block Protocol Version number + * @param {number} driveCurrentProtocol - Current Dash Platform (Drive) protocol version number + * @param {number} driveLatestProtocol - Next Dash Platform (Drive) protocol version number for future upgrades */packages/js-dapi-client/test/unit/methods/platform/getDocuments/GetDocumentsResponse.spec.js (2)
87-94: Enhance assertion specificity for metadata values.The assertions could be more specific by checking for exact types and ranges.
- expect(getDocumentsResponse.getMetadata().getHeight()) - .to.deep.equal(BigInt(metadataFixture.height)); - expect(getDocumentsResponse.getMetadata().getCoreChainLockedHeight()) - .to.deep.equal(metadataFixture.coreChainLockedHeight); - expect(getDocumentsResponse.getMetadata().getTimeMs()) - .to.deep.equal(BigInt(metadataFixture.timeMs)); - expect(getDocumentsResponse.getMetadata().getProtocolVersion()) - .to.deep.equal(metadataFixture.protocolVersion); + const metadata = getDocumentsResponse.getMetadata(); + expect(metadata.getHeight()).to.be.a('bigint') + .and.to.deep.equal(BigInt(metadataFixture.height)); + expect(metadata.getCoreChainLockedHeight()).to.be.a('number') + .and.to.be.at.least(0) + .and.to.deep.equal(metadataFixture.coreChainLockedHeight); + expect(metadata.getTimeMs()).to.be.a('bigint') + .and.to.deep.equal(BigInt(metadataFixture.timeMs)); + expect(metadata.getProtocolVersion()).to.be.a('number') + .and.to.be.at.least(0) + .and.to.deep.equal(metadataFixture.protocolVersion);
25-40: Add edge case tests for metadata values.The test setup could include edge cases for metadata values.
Consider adding tests for:
- Maximum safe integer values for height and timeMs
- Zero values for protocol version
- Negative values (should throw errors)
packages/js-dapi-client/lib/methods/platform/getStatus/ChainStatus.js (1)
2-12: Enhance JSDoc with format specifications.Add format specifications for hash values and valid ranges for heights in the JSDoc comments.
/** * @param {boolean} catchingUp - is node syncing? - * @param {string} latestBlockHash - latest block hash - * @param {string} latestAppHash - latest app hash - * @param {bigint} latestBlockHeight - latest block height - * @param {string} earliestBlockHash - earliest block hash - * @param {string} earliestAppHash - earliest app hash - * @param {bigint} earliestBlockHeight - earliest block height - * @param {bigint} maxPeerBlockHeight - max peer block height - * @param {number=} coreChainLockedHeight - core chain locked height + * @param {string} latestBlockHash - latest block hash (32-byte hex string) + * @param {string} latestAppHash - latest app hash (32-byte hex string) + * @param {bigint} latestBlockHeight - latest block height (non-negative) + * @param {string} earliestBlockHash - earliest block hash (32-byte hex string) + * @param {string} earliestAppHash - earliest app hash (32-byte hex string) + * @param {bigint} earliestBlockHeight - earliest block height (non-negative) + * @param {bigint} maxPeerBlockHeight - max peer block height (non-negative) + * @param {number=} coreChainLockedHeight - core chain locked height (non-negative) */packages/js-dapi-client/test/unit/methods/platform/getIdentityBalance/GetIdentityBalanceResponse.spec.js (2)
23-26: Add test cases for edge case balances.Consider adding test cases for:
- Maximum safe BigInt values
- Zero balance
- Negative balance handling
beforeEach(async () => { metadataFixture = getMetadataFixture(); proofFixture = getProofFixture(); balance = BigInt(1337); + // Add test cases for edge cases + const testCases = { + maxBalance: BigInt(Number.MAX_SAFE_INTEGER), + zeroBalance: BigInt(0), + negativeBalance: BigInt(-1), // Should throw error + }; });
106-113: Improve metadata assertions with type checks.The metadata assertions could be more specific by including type checks.
- expect(getIdentityBalanceResponse.getMetadata().getHeight()) - .to.deep.equal(BigInt(metadataFixture.height)); - expect(getIdentityBalanceResponse.getMetadata().getCoreChainLockedHeight()) - .to.deep.equal(metadataFixture.coreChainLockedHeight); - expect(getIdentityBalanceResponse.getMetadata().getTimeMs()) - .to.deep.equal(BigInt(metadataFixture.timeMs)); - expect(getIdentityBalanceResponse.getMetadata().getProtocolVersion()) - .to.deep.equal(metadataFixture.protocolVersion); + const metadata = getIdentityBalanceResponse.getMetadata(); + expect(metadata.getHeight()) + .to.be.a('bigint') + .and.to.deep.equal(BigInt(metadataFixture.height)); + expect(metadata.getCoreChainLockedHeight()) + .to.be.a('number') + .and.to.be.at.least(0) + .and.to.deep.equal(metadataFixture.coreChainLockedHeight); + expect(metadata.getTimeMs()) + .to.be.a('bigint') + .and.to.deep.equal(BigInt(metadataFixture.timeMs)); + expect(metadata.getProtocolVersion()) + .to.be.a('number') + .and.to.be.at.least(0) + .and.to.deep.equal(metadataFixture.protocolVersion);packages/js-dapi-client/test/unit/methods/platform/getIdentityKeys/getIdentityKeysFactory.spec.js (1)
137-144: Enhanced metadata assertionsPrevious test used a single deep equality check that has been replaced with more granular assertions. The new approach properly converts and compares numeric values using BigInt where appropriate.
While this change improves test specificity, it would be helpful to add a comment explaining why the test was restructured to use individual assertions instead of a deep equality check.
packages/wasm-dpp/src/identity/state_transition/identity_update_transition/identity_update_transition.rs (1)
443-445: Inconsistent type casting in set_revisionWhile the method's signature now accepts u64, there's still an unnecessary cast to u64 in the implementation. Since the parameter is already u64, the cast is redundant.
pub fn set_revision(&mut self, revision: u64) { - self.0.set_revision(revision as u64) + self.0.set_revision(revision) }packages/js-dapi-client/test/unit/methods/platform/getDataContractHistory/GetDataContractHistoryResponse.spec.js (1)
77-77: Consider adding a timeout to the while loop.The while loop for waiting for document completion could potentially run indefinitely. Consider adding a timeout mechanism.
+ const maxRetries = 10; + let retries = 0; let withdrawalCompleted = false; let withdrawalDocument; - for (let i = 0; i < 10; i++) { + while (!withdrawalCompleted && retries < maxRetries) { + retries++;Also applies to: 82-82
packages/platform-test-suite/test/e2e/withdrawals.spec.js (1)
113-113: Consider using explicit BigInt comparison.The comparison could be more explicit using BigInt's comparison methods.
- expect(identityBalanceUpdated < identityBalanceBefore).to.be.true(); + expect(identityBalanceUpdated).to.be.lessThan(identityBalanceBefore);
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (107)
.yarnrc.yml(1 hunks)packages/dapi-grpc/.eslintrc(1 hunks)packages/dapi-grpc/clients/platform/v0/nodejs/platform_protoc.js(89 hunks)packages/dapi-grpc/clients/platform/v0/web/platform_pb.d.ts(38 hunks)packages/dapi-grpc/clients/platform/v0/web/platform_pb.js(89 hunks)packages/dapi-grpc/protos/platform/v0/platform.proto(18 hunks)packages/js-dapi-client/.eslintrc.yml(1 hunks)packages/js-dapi-client/lib/BlockHeadersProvider/BlockHeadersProvider.js(7 hunks)packages/js-dapi-client/lib/SimplifiedMasternodeListProvider/createMasternodeListStreamFactory.js(1 hunks)packages/js-dapi-client/lib/methods/platform/getDataContractHistory/DataContractHistoryEntry.js(1 hunks)packages/js-dapi-client/lib/methods/platform/getDataContractHistory/GetDataContractHistoryResponse.js(3 hunks)packages/js-dapi-client/lib/methods/platform/getDataContractHistory/getDataContractHistoryFactory.js(2 hunks)packages/js-dapi-client/lib/methods/platform/getEpochsInfo/EpochInfo.js(3 hunks)packages/js-dapi-client/lib/methods/platform/getEpochsInfo/GetEpochsInfoResponse.js(1 hunks)packages/js-dapi-client/lib/methods/platform/getIdentityBalance/GetIdentityBalanceResponse.js(3 hunks)packages/js-dapi-client/lib/methods/platform/getIdentityContractNonce/GetIdentityContractNonceResponse.js(3 hunks)packages/js-dapi-client/lib/methods/platform/getIdentityNonce/GetIdentityNonceResponse.js(3 hunks)packages/js-dapi-client/lib/methods/platform/getStatus/ChainStatus.js(1 hunks)packages/js-dapi-client/lib/methods/platform/getStatus/GetStatusResponse.js(1 hunks)packages/js-dapi-client/lib/methods/platform/getStatus/NetworkStatus.js(1 hunks)packages/js-dapi-client/lib/methods/platform/getStatus/NodeStatus.js(1 hunks)packages/js-dapi-client/lib/methods/platform/getStatus/StateSyncStatus.js(1 hunks)packages/js-dapi-client/lib/methods/platform/getStatus/TimeStatus.js(1 hunks)packages/js-dapi-client/lib/methods/platform/getStatus/VersionStatus.js(1 hunks)packages/js-dapi-client/lib/methods/platform/getStatus/getStatusFactory.js(2 hunks)packages/js-dapi-client/lib/methods/platform/getTotalCreditsInPlatform/GetTotalCreditsInPlatformResponse.js(3 hunks)packages/js-dapi-client/lib/methods/platform/response/AbstractResponse.js(1 hunks)packages/js-dapi-client/lib/methods/platform/response/Metadata.js(2 hunks)packages/js-dapi-client/lib/test/fixtures/getMetadataFixture.js(1 hunks)packages/js-dapi-client/lib/test/fixtures/getStatusFixture.js(1 hunks)packages/js-dapi-client/test/unit/methods/platform/getDataContract/GetDataContractResponse.spec.js(4 hunks)packages/js-dapi-client/test/unit/methods/platform/getDataContract/getDataContractFactory.spec.js(2 hunks)packages/js-dapi-client/test/unit/methods/platform/getDataContractHistory/GetDataContractHistoryResponse.spec.js(8 hunks)packages/js-dapi-client/test/unit/methods/platform/getDataContractHistory/getDataContractHistoryFactory.spec.js(8 hunks)packages/js-dapi-client/test/unit/methods/platform/getDocuments/GetDocumentsResponse.spec.js(3 hunks)packages/js-dapi-client/test/unit/methods/platform/getDocuments/getDocumentsFactory.spec.js(3 hunks)packages/js-dapi-client/test/unit/methods/platform/getEpochsInfo/GetEpochsInfoResponse.spec.js(3 hunks)packages/js-dapi-client/test/unit/methods/platform/getEpochsInfo/getEpochsInfoFactory.spec.js(3 hunks)packages/js-dapi-client/test/unit/methods/platform/getIdentitiesContractKeys/GetIdentitiesContractKeysResponse.spec.js(3 hunks)packages/js-dapi-client/test/unit/methods/platform/getIdentitiesContractKeys/getIdentitiesContractKeysFactory.spec.js(2 hunks)packages/js-dapi-client/test/unit/methods/platform/getIdentity/GetIdentityResponse.spec.js(2 hunks)packages/js-dapi-client/test/unit/methods/platform/getIdentity/getIdentityFactory.spec.js(2 hunks)packages/js-dapi-client/test/unit/methods/platform/getIdentityBalance/GetIdentityBalanceResponse.spec.js(2 hunks)packages/js-dapi-client/test/unit/methods/platform/getIdentityBalance/getIdentityBalanceFactory.spec.js(3 hunks)packages/js-dapi-client/test/unit/methods/platform/getIdentityByPublicKeyHash/GetIdentityByPublicKeyHashResponse.spec.js(2 hunks)packages/js-dapi-client/test/unit/methods/platform/getIdentityByPublicKeyHash/getIdentityByPublicKeyHashFactory.spec.js(2 hunks)packages/js-dapi-client/test/unit/methods/platform/getIdentityContractNonce/GetIdentityContractNonce.spec.js(2 hunks)packages/js-dapi-client/test/unit/methods/platform/getIdentityContractNonce/getIdentityContractNonceFactory.spec.js(3 hunks)packages/js-dapi-client/test/unit/methods/platform/getIdentityKeys/GetIdentityKeys.spec.js(1 hunks)packages/js-dapi-client/test/unit/methods/platform/getIdentityKeys/getIdentityKeysFactory.spec.js(2 hunks)packages/js-dapi-client/test/unit/methods/platform/getIdentityNonce/GetIdentityNonce.spec.js(2 hunks)packages/js-dapi-client/test/unit/methods/platform/getIdentityNonce/getIdentityNonceFactory.spec.js(3 hunks)packages/js-dapi-client/test/unit/methods/platform/getProtocolVersionUpgradeState/GetProtocolVersionUpgradeStateResponse.spec.js(1 hunks)packages/js-dapi-client/test/unit/methods/platform/getProtocolVersionUpgradeState/getProtocolVersionUpgradeStateFactory.spec.js(2 hunks)packages/js-dapi-client/test/unit/methods/platform/getProtocolVersionUpgradeVoteStatus/GetProtocolVersionUpgradeVoteStatusResponse.spec.js(1 hunks)packages/js-dapi-client/test/unit/methods/platform/getProtocolVersionUpgradeVoteStatus/getProtocolVersionUpgradeVoteStatusFactory.spec.js(2 hunks)packages/js-dapi-client/test/unit/methods/platform/getStatus/GetStatusResponse.spec.js(1 hunks)packages/js-dapi-client/test/unit/methods/platform/getStatus/getStatusFactory.spec.js(1 hunks)packages/js-dapi-client/test/unit/methods/platform/waitForStateTransitionResult/waitForStateTransitionResultFactory.spec.js(3 hunks)packages/js-dash-sdk/src/SDK/Client/Client.ts(1 hunks)packages/js-dash-sdk/src/SDK/Client/Platform/Fetcher/Fetcher.ts(1 hunks)packages/js-dash-sdk/src/SDK/Client/Platform/NonceManager/NonceManager.spec.ts(1 hunks)packages/js-dash-sdk/src/SDK/Client/Platform/NonceManager/NonceManager.ts(6 hunks)packages/js-dash-sdk/src/SDK/Client/Platform/methods/contracts/get.spec.ts(2 hunks)packages/js-dash-sdk/src/SDK/Client/Platform/methods/contracts/get.ts(1 hunks)packages/js-dash-sdk/src/SDK/Client/Platform/methods/contracts/history.spec.ts(2 hunks)packages/js-dash-sdk/src/SDK/Client/Platform/methods/contracts/history.ts(2 hunks)packages/js-dash-sdk/src/SDK/Client/Platform/methods/contracts/update.ts(1 hunks)packages/js-dash-sdk/src/SDK/Client/Platform/methods/documents/broadcast.ts(1 hunks)packages/js-dash-sdk/src/SDK/Client/Platform/methods/documents/get.ts(1 hunks)packages/js-dash-sdk/src/SDK/Client/Platform/methods/identities/get.ts(1 hunks)packages/js-dash-sdk/src/test/mocks/createAndAttachTransportMocksToClient.ts(1 hunks)packages/js-dash-sdk/src/test/mocks/createDapiClientMock.ts(1 hunks)packages/js-dash-sdk/tsconfig.json(1 hunks)packages/platform-test-suite/lib/test/fixtures/getDataContractFixture.js(1 hunks)packages/platform-test-suite/lib/test/fixtures/getIdentityFixture.js(1 hunks)packages/platform-test-suite/test/e2e/withdrawals.spec.js(4 hunks)packages/platform-test-suite/test/functional/platform/Document.spec.js(1 hunks)packages/platform-test-suite/test/functional/platform/Epoch.spec.js(1 hunks)packages/platform-test-suite/test/functional/platform/Identity.spec.js(8 hunks)packages/platform-test-suite/test/functional/platform/getStatus.spec.js(1 hunks)packages/rs-dpp/src/state_transition/state_transitions/document/batch_transition/batched_transition/document_transition.rs(1 hunks)packages/wallet-lib/src/plugins/Workers/TransactionsSyncWorker/TransactionsReader.spec.js(3 hunks)packages/wallet-lib/src/plugins/Workers/TransactionsSyncWorker/TransactionsSyncWorker.spec.js(1 hunks)packages/wasm-dpp/.eslintrc(1 hunks)packages/wasm-dpp/lib/test/fixtures/getIdentityCreditTransferTransitionFixture.js(1 hunks)packages/wasm-dpp/lib/test/fixtures/getIdentityFixture.js(1 hunks)packages/wasm-dpp/src/data_contract/data_contract.rs(1 hunks)packages/wasm-dpp/src/document/document_facade.rs(1 hunks)packages/wasm-dpp/src/document/extended_document.rs(1 hunks)packages/wasm-dpp/src/document/factory.rs(3 hunks)packages/wasm-dpp/src/document/mod.rs(1 hunks)packages/wasm-dpp/src/document/state_transition/batch_transition/document_transition/document_create_transition.rs(2 hunks)packages/wasm-dpp/src/document/state_transition/batch_transition/document_transition/document_delete_transition.rs(1 hunks)packages/wasm-dpp/src/document/state_transition/batch_transition/document_transition/mod.rs(3 hunks)packages/wasm-dpp/src/document/state_transition/batch_transition/mod.rs(1 hunks)packages/wasm-dpp/src/errors/consensus/basic/identity/identity_insufficient_balance_error.rs(1 hunks)packages/wasm-dpp/src/errors/consensus/fee/balance_is_not_enough_error.rs(1 hunks)packages/wasm-dpp/src/identity/identity.rs(1 hunks)packages/wasm-dpp/src/identity/state_transition/identity_credit_transfer_transition/transition.rs(4 hunks)packages/wasm-dpp/src/identity/state_transition/identity_update_transition/identity_update_transition.rs(1 hunks)packages/wasm-dpp/src/identity/state_transition/identity_update_transition/to_object.rs(2 hunks)packages/wasm-dpp/src/metadata.rs(2 hunks)packages/wasm-dpp/test/integration/document/Document.spec.js(1 hunks)packages/wasm-dpp/test/integration/document/DocumentFacade.spec.js(1 hunks)packages/wasm-dpp/test/integration/identity/IdentityFacade.spec.js(3 hunks)packages/wasm-dpp/test/integration/identity/stateTransition/IdentityUpdateTransition/validation/state/validateIdentityUpdateTransitionStateFactory.spec.js(4 hunks)
⛔ Files not processed due to max files limit (11)
- packages/wasm-dpp/test/integration/identity/stateTransition/assetLockProof/chain/validateChainAssetLockProofStructureFactory.spec.js
- packages/wasm-dpp/test/integration/identity/stateTransition/assetLockProof/fetchAssetLockTransactionOutputFactory.spec.js
- packages/wasm-dpp/test/integration/stateTransition/StateTransitionFacade.spec.js
- packages/wasm-dpp/test/unit/Metadata.spec.js
- packages/wasm-dpp/test/unit/dataContract/DataContract.spec.js
- packages/wasm-dpp/test/unit/document/Document.spec.js
- packages/wasm-dpp/test/unit/document/DocumentFactory.spec.js
- packages/wasm-dpp/test/unit/identity/Identity.spec.js
- packages/wasm-dpp/test/unit/identity/IdentityFactory.spec.js
- packages/wasm-dpp/test/unit/identity/stateTransition/IdentityUpdateTransition/IdentityUpdateTransition.spec.js
- packages/wasm-dpp/test/unit/identity/stateTransition/identityCreditTransferTransition/identityCreditTransferTransition.spec.js
✅ Files skipped from review due to trivial changes (10)
- packages/js-dash-sdk/src/SDK/Client/Platform/methods/documents/get.ts
- packages/js-dash-sdk/src/SDK/Client/Platform/methods/contracts/get.ts
- packages/wasm-dpp/test/integration/identity/stateTransition/IdentityUpdateTransition/validation/state/validateIdentityUpdateTransitionStateFactory.spec.js
- packages/wasm-dpp/src/document/state_transition/batch_transition/document_transition/document_delete_transition.rs
- packages/wasm-dpp/src/data_contract/data_contract.rs
- packages/js-dapi-client/lib/SimplifiedMasternodeListProvider/createMasternodeListStreamFactory.js
- packages/wallet-lib/src/plugins/Workers/TransactionsSyncWorker/TransactionsSyncWorker.spec.js
- packages/wallet-lib/src/plugins/Workers/TransactionsSyncWorker/TransactionsReader.spec.js
- packages/rs-dpp/src/state_transition/state_transitions/document/batch_transition/batched_transition/document_transition.rs
- packages/wasm-dpp/src/document/document_facade.rs
⏰ Context from checks skipped due to timeout of 90000ms (18)
- GitHub Check: Rust packages (drive-abci) / Tests
- GitHub Check: Rust packages (drive-abci) / Linting
- GitHub Check: Rust packages (drive-abci) / Formatting
- GitHub Check: Rust packages (drive-abci) / Check each feature
- GitHub Check: Rust packages (drive) / Unused dependencies
- GitHub Check: Rust packages (drive) / Tests
- GitHub Check: Rust packages (drive) / Linting
- GitHub Check: Rust packages (drive) / Formatting
- GitHub Check: Rust packages (dpp) / Tests
- GitHub Check: Rust packages (dpp) / Linting
- GitHub Check: Rust packages (dpp) / Check each feature
- GitHub Check: Rust packages (dash-sdk) / Linting
- GitHub Check: Rust packages (dash-sdk) / Tests
- GitHub Check: Rust packages (dash-sdk) / Check each feature
- GitHub Check: Build Docker images (Drive, drive, drive-abci) / Build Drive image
- GitHub Check: Build Docker images (DAPI, dapi, dapi) / Build DAPI image
- GitHub Check: Build Docker images (Dashmate helper, dashmate-helper, dashmate-helper) / Build Dashmate helper image
- GitHub Check: Build JS packages / Build JS
🔇 Additional comments (354)
packages/platform-test-suite/test/functional/platform/Epoch.spec.js (1)
27-27: LGTM! Consistent with the BigInt transition.The change from integer to BigInt aligns with the broader effort to use BigInt for numeric values across the codebase.
packages/platform-test-suite/lib/test/fixtures/getIdentityFixture.js (1)
30-30: LGTM! Consistent with the BigInt transition.The change from integer to BigInt for balance aligns with the broader effort to use BigInt for numeric values across the codebase.
packages/dapi-grpc/.eslintrc (1)
3-5: LGTM! ES2020 environment support is necessary.Adding ES2020 environment support is required for proper linting of BigInt and other ES2020 features being used in the codebase.
packages/wasm-dpp/.eslintrc (1)
3-5: LGTM! Consistent ES2020 environment support.Adding ES2020 environment support aligns with similar changes in other packages and is necessary for proper linting of BigInt and other ES2020 features.
packages/js-dash-sdk/src/SDK/Client/Platform/methods/documents/broadcast.ts (1)
50-50: LGTM! Good practice using string conversion for contract nonce.Converting the contract nonce to string helps prevent potential precision loss when dealing with large integers in JavaScript.
packages/wasm-dpp/test/integration/document/DocumentFacade.spec.js (1)
106-106: LGTM! Consistent type handling in tests.Converting the numeric value to string in tests ensures consistency with production code behavior where numbers are handled as strings.
packages/wasm-dpp/lib/test/fixtures/getIdentityCreditTransferTransitionFixture.js (1)
9-9: LGTM! Appropriate use of BigInt for credit amounts.Using BigInt for credit amounts is the right approach as it prevents precision loss and overflow issues that could occur with regular numbers.
packages/js-dash-sdk/src/SDK/Client/Platform/methods/identities/get.ts (1)
34-39: Constructor parameter style change looks goodThe code now uses positional parameters instead of an object with named parameters for the Metadata constructor. This change maintains the same functionality while aligning with similar changes across the codebase.
packages/js-dapi-client/.eslintrc.yml (1)
4-5: Enabling ES2020 environment in ESLint configurationAdding ES2020 environment support is appropriate, as it enables linting for newer JavaScript features like BigInt that are being used in the codebase.
packages/js-dapi-client/lib/methods/platform/getEpochsInfo/GetEpochsInfoResponse.js (2)
44-44: Using BigInt for block heightConverting block height to BigInt ensures proper handling of large integer values, which is important for blockchain data. This change is consistent with similar modifications throughout the codebase.
46-46: Using BigInt for timestampsConverting the start time to BigInt provides better precision for timestamps. This change aligns with the broader initiative to standardize large integer handling across the codebase.
packages/wasm-dpp/lib/test/fixtures/getIdentityFixture.js (1)
37-37: Using BigInt for identity balanceConverting the identity balance to BigInt is appropriate for financial values that require precision. This change aligns with the broader conversion to BigInt for numeric values throughout the codebase.
packages/js-dash-sdk/tsconfig.json (1)
3-3:✅ Verification successful
Verify browser compatibility and dependency constraints.
The target has been updated to ES2020, which introduces modern JavaScript features. Please ensure:
- All dependencies support ES2020 features
- Target browsers support ES2020 features
- Build pipeline is configured to handle ES2020
🌐 Web query:
What browsers support ES2020 features?💡 Result:
ES2020 (officially ECMAScript 2020) features are supported by most modern browsers starting from these minimum versions:
Browser Minimum Version Release Date Chrome 80 February 2020 Edge 80 January 2020 Firefox 74 March 2020 Safari 14 September 2020 iOS Safari 14.4 January 2021 Opera 67 March 2021 Samsung Internet 13.0 March 2021 Key ES2020 features include:
- Optional chaining (
?.)- Nullish coalescing operator (
??)- Dynamic imports (
import())Promise.allSettledglobalThisreference- BigInt primitive type
Browser compatibility notes:
- Safari added full ES2020 support in version 14[1][5], though some features like BigInt required later updates (iOS Safari v14.4)[1]
- Legacy browsers like Internet Explorer lack any ES2020 support[2][6]
- Modern evergreen browsers (Chrome/Edge/Firefox) automatically update to maintain compatibility[3][8]
For environments requiring older browser support:
- Use transpilers like Babel (v7.8+) or TypeScript (v3.7+)[4]
- Include polyfills for features like
Promise.allSettledandglobalThis[1][4]Global ES2020 compatibility currently exceeds 92% of modern web traffic when excluding niche/enterprise-specific browsers[2]. Developers should still verify specific feature support using resources like CanIUse before deployment[5][7].
Citations:
- 1: https://docs.sentry.io/platforms/javascript/guides/angular/troubleshooting/supported-browsers/
- 2: https://gist.github.com/Julien-Marcou/156b19aea4704e1d2f48adafc6e2acbf
- 3: https://www.infoq.com/news/2020/04/es2020-features/
- 4: https://martinmck.com/posts/es2020-everything-you-need-to-know/
- 5: https://caniuse.com/?search=es2020
- 6: https://www.w3schools.com/js/js_versions.asp
- 7: https://caniuse.com/?search=es20
- 8: https://ui.refinitiv.com/start/browser-support
ES2020 Target Verification: Confirm Build and Dependency Compatibility
The update to
"target": "es2020"is appropriate, given that modern browsers (Chrome ≥80, Edge ≥80, Firefox ≥74, Safari ≥14, Opera ≥67, Samsung Internet ≥13) fully support ES2020 features. However, please verify the following:
- Dependencies: Ensure that all project dependencies are compatible with ES2020 features. If any dependency isn't fully ES2020-compliant, consider updating it or integrating a transpiler/polyfill strategy.
- Build Pipeline: Confirm that your build tools (e.g., Babel, TypeScript compilers, bundlers) are configured to process ES2020 code.
- Browser Targets: Review your target user base. If legacy browsers (e.g., Internet Explorer) must be supported, additional transpilation or polyfilling might be necessary.
packages/js-dash-sdk/src/test/mocks/createDapiClientMock.ts (1)
10-11: LGTM! Consistent use of BigInt for nonce values.The change from number to BigInt aligns with the broader effort to handle large integers consistently across the codebase, improving type safety and precision.
packages/js-dapi-client/lib/methods/platform/getDataContractHistory/DataContractHistoryEntry.js (1)
1-27: LGTM! Well-structured class with proper encapsulation.The implementation follows good practices:
- Clear and accurate JSDoc comments
- Proper encapsulation with getter methods
- Type safety with bigint for date and Buffer for value
packages/js-dash-sdk/src/SDK/Client/Platform/methods/contracts/update.ts (1)
35-35: Removed redundant BigInt conversion.The explicit BigInt conversion for
identityContractNoncehas been removed, suggesting that the value is already a BigInt when returned from the nonce manager. This change aligns with the broader effort to standardize BigInt usage for large integers across the codebase..yarnrc.yml (1)
26-26:❓ Verification inconclusive
Added TODO note to update Sinon.
The comment for
lodash.gethas been updated to include "Update sinon" in addition to the existing note about replacing with the optional chaining operator. This suggests that Sinon may have a dependency on lodash.get that needs attention.
🏁 Script executed:
#!/bin/bash # Check if Sinon depends on lodash.get yarn why sinon | grep -A 10 "Found.*via"Length of output: 115
Action Required: Confirm Sinon Dependency on lodash.get
The current verification command failed due to the absence of a lockfile. It’s necessary to generate the lockfile (using
yarn install) and then re-run the dependency check to verify whether Sinon relies onlodash.get. Please run these steps manually:
- Run
yarn installto create the lockfile.- Execute
yarn why sinon | grep -A 10 "Found.*via"to check Sinon’s dependency chain.- If Sinon shows a dependency on
lodash.get, then the TODO comment is valid; otherwise, consider updating or removing the note.packages/platform-test-suite/lib/test/fixtures/getDataContractFixture.js (1)
13-13: Updated parameter type annotation to support multiple numeric formats.The JSDoc type annotation for
identityNoncehas been expanded from justnumbertostring|number|bigint, making the function's interface more flexible while maintaining compatibility with the existing codebase, which is converting the value to BigInt on line 154.packages/platform-test-suite/test/functional/platform/Document.spec.js (1)
303-303: Updated revision increment to use BigInt.The revision increment now uses
BigInt(1)instead of the numeric value1, ensuring type consistency when working with revision numbers. This aligns with the broader effort to standardize BigInt usage for numeric values across the codebase.packages/js-dash-sdk/src/SDK/Client/Platform/methods/contracts/history.spec.ts (2)
13-13: LGTM! Import aligns with BigInt usage.The new import of
DataContractHistoryEntrysupports the transition to using BigInt for numeric values.
60-60: LGTM! Proper usage of BigInt for timestamps.The change from using a plain number to
BigInt(1000)improves precision and aligns with the codebase's standardization of large number handling.packages/wasm-dpp/src/errors/consensus/basic/identity/identity_insufficient_balance_error.rs (1)
26-28: LGTM! Enhanced numeric range for balance values.The change from
u32tou64for the balance method improves the handling of larger balance values, preventing potential overflow issues.packages/js-dapi-client/lib/test/fixtures/getMetadataFixture.js (2)
3-6: LGTM! Improved type documentation.The JSDoc updates accurately reflect the new return types, improving type safety and documentation clarity.
11-14: LGTM! Consistent type handling for numeric values.The changes properly implement:
- BigInt for height
- String for coreChainLockedHeight
- String for timeMs
This aligns with the standardization of numeric value handling across the codebase.packages/js-dapi-client/lib/methods/platform/response/AbstractResponse.js (1)
52-59: LGTM! Improved type safety in metadata handling.The explicit extraction of metadata properties enhances type safety and ensures consistent handling of numeric values across the codebase.
packages/js-dapi-client/test/unit/methods/platform/getIdentityByPublicKeyHash/GetIdentityByPublicKeyHashResponse.spec.js (1)
79-86: LGTM! Enhanced test coverage with proper BigInt handling.The test improvements include:
- Individual validation of metadata properties
- Proper
BigIntcomparisons for numeric values- Consistent assertions across test cases
Also applies to: 123-130
packages/wasm-dpp/src/identity/state_transition/identity_update_transition/to_object.rs (1)
19-19:❓ Verification inconclusive
Verify the impact of changing revision type from u32 to u64.
The type change from
u32tou64for the revision field could affect:
- API compatibility
- Serialization/deserialization
- Storage requirements
Let's verify the usage of this type across the codebase:
Also applies to: 33-33
🏁 Script executed:
#!/bin/bash # Search for revision type declarations and usages ast-grep --pattern 'revision: u32' ast-grep --pattern 'revision: u64' rg -A 2 'revision.*u(32|64)'Length of output: 6197
Action: Verify and Resolve Revision Type Consistency
The investigation confirms that the transition from using a revision type of
u32tou64is broadly adopted across the codebase. In particular, theto_object.rsimplementation in the identity update transition now correctly usesu64.However, note the following details:
- In packages/rs-dpp/src/state_transition/state_transitions/document/batch_transition/batched_transition/document_create_transition/v0/mod.rs, the revision is still set as
1u32. This discrepancy could potentially affect:
- API compatibility: External expectations for revision values may be inconsistent.
- Serialization/deserialization: Mixing numeric literal types may not align with the new
u64schema.- Tests/Fixtures: If tests expect a
u64value, this literal might introduce subtle errors.Please review whether this instance is intentional (perhaps for version-specific behavior) or if it should be updated to use a
u64literal. Adjusting it to1u64would ensure consistency across both the API and internal implementation.packages/platform-test-suite/test/functional/platform/getStatus.spec.js (1)
20-22: LGTM! Improved version status validation.The test improvements include:
- Using proper getter methods for version information
- Explicit type checking for version strings
- Validation of non-empty values for critical components
packages/js-dapi-client/test/unit/methods/platform/waitForStateTransitionResult/waitForStateTransitionResultFactory.spec.js (1)
58-65: LGTM! Improved metadata validation with granular assertions.The changes enhance test precision by:
- Breaking down metadata validation into individual property checks
- Using BigInt for height and timeMs to handle large integers accurately
- Maintaining consistency across all test cases
Also applies to: 100-107, 151-158
packages/js-dapi-client/test/unit/methods/platform/getProtocolVersionUpgradeVoteStatus/GetProtocolVersionUpgradeVoteStatusResponse.spec.js (1)
117-124: LGTM! Consistent metadata validation approach.The changes maintain consistency with other test files by:
- Using granular assertions for metadata properties
- Properly handling large integers with BigInt
packages/js-dash-sdk/src/SDK/Client/Platform/methods/contracts/get.spec.ts (1)
84-84: LGTM! Consistent handling of numeric metadata.The changes maintain consistency across test cases and align with other files by using BigInt for block height and time values.
Also applies to: 86-86, 98-98, 100-100
packages/js-dapi-client/test/unit/methods/platform/getProtocolVersionUpgradeState/GetProtocolVersionUpgradeStateResponse.spec.js (1)
114-121: LGTM! Improved type safety in metadata assertions.The changes correctly handle large numeric values by using BigInt for height and timeMs fields, while maintaining direct comparisons for other fields. This ensures type consistency and prevents potential precision loss.
packages/js-dash-sdk/src/test/mocks/createAndAttachTransportMocksToClient.ts (1)
63-65: LGTM! Enhanced precision for balance handling.Converting satoshis to BigInt ensures accurate handling of large balance values that could potentially exceed JavaScript's Number.MAX_SAFE_INTEGER (2^53 - 1).
packages/js-dapi-client/test/unit/methods/platform/getIdentityKeys/GetIdentityKeys.spec.js (1)
109-116: LGTM! Consistent type handling in metadata assertions.The changes maintain consistency with other response handlers by using BigInt for numeric fields in metadata assertions.
packages/js-dash-sdk/src/SDK/Client/Client.ts (1)
166-170: Code cleanup looks goodThe refactoring simplifies the code by directly returning the result of
this.wallet.getAccountwithout using an intermediate variable, which improves readability while maintaining the same functionality.packages/wasm-dpp/src/document/state_transition/batch_transition/mod.rs (1)
148-149: Type enhancement for better numeric range supportThe parameter type change from
u32tou64for the nonce improves the API by allowing larger values and removing the unnecessary type casting. This is aligned with the codebase's transition to using larger integer types for blockchain operations.packages/js-dapi-client/test/unit/methods/platform/getDataContract/GetDataContractResponse.spec.js (3)
66-67: Good addition of metadata field testsAdding tests for the new metadata fields
timeMsandprotocolVersionimproves test coverage and ensures these properties are correctly handled.Also applies to: 83-86
79-81: Proper use of BigInt for numeric comparisonsUsing
deep.equalwithBigIntfor height comparison is appropriate for ensuring precise handling of large numbers in blockchain contexts.
104-105: Consistent testing of metadata fieldsThe test properly sets and validates the same metadata fields in both test scenarios, ensuring consistent behavior across different use cases.
Also applies to: 122-125
packages/js-dapi-client/lib/methods/platform/getStatus/StateSyncStatus.js (1)
1-30: Well-structured class for sync statusThe
StateSyncStatusclass provides a clean encapsulation of state synchronization metrics with appropriate constructor parameters and property initialization.packages/wasm-dpp/test/integration/document/Document.spec.js (2)
88-88: BigInt conversion aligns with precision requirements.The change to convert
result.$revisiontoBigIntbefore comparison ensures accurate equality checks when dealing with large integers. This is consistent with the overall transition to usingBigIntfor handling document revisions throughout the codebase.
96-96: Improved Metadata instantiation with proper BigInt usage.The refactoring from an object literal to a direct constructor call with explicit
BigIntvalues forblockHeightandtimeMsensures proper type handling for these potentially large numeric values.packages/js-dash-sdk/src/SDK/Client/Platform/Fetcher/Fetcher.ts (3)
131-135: Improved JSDoc type annotations for better type safety.The added type annotations in the JSDoc comments clearly specify the expected parameter types, making the API more self-documenting and helping developers use the function correctly.
138-138: Type change from number to bigint improves precision.Updating the
startAMsparameter type fromnumbertobigintensures proper handling of large timestamps without precision loss, which is critical for blockchain-related timestamps.
143-144: Simplified function syntax while maintaining functionality.The refactoring from a multi-line function with explicit
awaitto a concise arrow function improves code readability while maintaining the same functionality, as the method naturally returns a Promise.packages/js-dapi-client/test/unit/methods/platform/getIdentityContractNonce/getIdentityContractNonceFactory.spec.js (4)
29-29: BigInt conversion for nonce ensures consistent type handling.Using
BigInt(1)instead of a regular number aligns with the changes in the implementation code where nonce values are now handled as BigInt to prevent potential precision issues with large integers.
87-95: Improved metadata testing with explicit property assertions.Breaking down the metadata validation to check individual properties with proper BigInt conversion provides more explicit and precise testing, making it easier to identify which specific property might fail in future changes.
123-123: BigInt conversion for default nonce value.Updating the assertion to expect
BigInt(0)instead of0ensures type consistency with the implementation code's handling of nonce values as BigInt.
125-132: Consistent metadata property validation with BigInt conversion.These additional assertions for metadata properties ensure the same comprehensive validation approach is used in all test cases, maintaining consistency and improving test reliability.
packages/js-dapi-client/test/unit/methods/platform/getIdentityContractNonce/GetIdentityContractNonce.spec.js (3)
25-25: BigInt conversion for nonce initialization.Using
BigInt(1)instead of a regular number ensures that the test environment accurately reflects how nonce values are handled in the actual implementation.
104-105: Type-consistent assertion for default nonce value.Updating the assertion to expect
BigInt(0)instead of0ensures type consistency when the nonce is undefined in the proof-based response path.
107-114: Detailed metadata property validation with explicit BigInt conversions.Breaking down the metadata validation into individual property assertions with proper type handling for BigInt values ensures comprehensive testing of the response structure and type consistency.
packages/dapi-grpc/clients/platform/v0/web/platform_pb.d.ts (7)
58-59: LGTM! Improved numeric precision in ResponseMetadata.The change from
numbertostringforheightandtimeMsfields in ResponseMetadata improves precision for large values.Also applies to: 67-68, 88-91
537-538: LGTM! Enhanced numeric handling in identity-related fields.Changed return types from
numbertostringfor identity-related numeric fields like nonces and balances to prevent potential precision loss.Also applies to: 563-563, 606-607, 632-632, 675-676, 701-701
1447-1448: LGTM! Better numeric precision for evonodes count.Updated
countfield type fromnumbertostringin EvonodeProposedBlocks to handle potentially large block counts safely.Also applies to: 1463-1463
2501-2502: LGTM! Improved timestamp handling in contract history.Changed
startAtMsfield type tostringto maintain precision for large timestamp values.Also applies to: 2522-2522
5703-5704: LGTM! Enhanced time precision in status responses.Updated time-related fields (
local,block,genesis) to usestringtype for better handling of timestamps.Also applies to: 5708-5709, 5713-5714
5784-5785: LGTM! Improved block height precision.Changed block height fields to
stringtype to handle large block numbers without precision loss.Also applies to: 5797-5798, 5800-5801
5861-5862: LGTM! Enhanced numeric precision in state sync fields.Updated all numeric fields in StateSync to use
stringtype for better precision:
- totalSyncedTime
- remainingTime
- chunkProcessAvgTime
- snapshotHeight
- snapshotChunksCount
- backfilledBlocks
- backfillBlocksTotal
Also applies to: 5864-5865, 5870-5871, 5873-5874, 5876-5877, 5879-5880, 5882-5883
packages/js-dapi-client/test/unit/methods/platform/getIdentityNonce/GetIdentityNonce.spec.js (2)
25-25: LGTM! Proper initialization of nonce as BigInt.The change from number to BigInt ensures proper handling of large nonce values.
104-114: LGTM! Consistent use of BigInt for metadata assertions.The test assertions have been properly updated to handle numeric values as BigInt where appropriate:
- nonce as BigInt(0)
- height as BigInt
- timeMs as BigInt
packages/js-dapi-client/test/unit/methods/platform/getIdentitiesContractKeys/GetIdentitiesContractKeysResponse.spec.js (1)
106-121: LGTM! Consistent metadata assertions using BigInt.The test assertions have been properly updated to handle numeric values as BigInt where appropriate:
- height as BigInt
- timeMs as BigInt
Also applies to: 164-171
packages/wasm-dpp/src/document/state_transition/batch_transition/document_transition/document_create_transition.rs (1)
83-84: LGTM! Increased integer size for initial_revision.Changed return type from u32 to u64 to support larger revision numbers. This is a good future-proofing change.
packages/js-dapi-client/lib/methods/platform/getIdentityBalance/GetIdentityBalanceResponse.js (2)
6-6: LGTM! Updated JSDoc types for BigInt.Properly documented the parameter and return types as bigint in JSDoc comments.
Also applies to: 17-17
28-28: LGTM! Explicit BigInt conversion for balance.The balance value is now properly converted to BigInt when creating from proto.
packages/js-dapi-client/test/unit/methods/platform/getIdentityNonce/getIdentityNonceFactory.spec.js (2)
28-28: LGTM! Consistent use of BigInt for nonce values.The change to use
BigInt(1)for nonce initialization aligns with the type safety improvements across the codebase.
84-92: LGTM! Enhanced metadata validation with granular property checks.The changes improve test precision by:
- Breaking down metadata validation into specific property checks
- Converting numeric values (height, timeMs) to BigInt for accurate comparisons
Also applies to: 119-128
packages/js-dapi-client/test/unit/methods/platform/getEpochsInfo/getEpochsInfoFactory.spec.js (2)
30-30: LGTM! Consistent use of BigInt for epoch info values.The change to use
BigIntfor epoch info initialization aligns with the type safety improvements across the codebase.
95-102: LGTM! Enhanced metadata validation with granular property checks.The changes improve test precision by:
- Breaking down metadata validation into specific property checks
- Converting numeric values (height, timeMs) to BigInt for accurate comparisons
Also applies to: 134-141
packages/js-dapi-client/test/unit/methods/platform/getIdentityByPublicKeyHash/getIdentityByPublicKeyHashFactory.spec.js (1)
92-99: LGTM! Enhanced metadata validation with granular property checks.The changes improve test precision by:
- Breaking down metadata validation into specific property checks
- Converting numeric values (height, timeMs) to BigInt for accurate comparisons
Also applies to: 126-133
packages/js-dapi-client/test/unit/methods/platform/getIdentitiesContractKeys/getIdentitiesContractKeysFactory.spec.js (1)
148-155: LGTM! Enhanced metadata validation with granular property checks.The changes improve test precision by:
- Breaking down metadata validation into specific property checks
- Converting numeric values (height, timeMs) to BigInt for accurate comparisons
Also applies to: 182-189
packages/js-dapi-client/test/unit/methods/platform/getProtocolVersionUpgradeVoteStatus/getProtocolVersionUpgradeVoteStatusFactory.spec.js (2)
101-108: Improved test precision using BigInt conversions.The change correctly updates the metadata validation to check individual properties instead of comparing the whole metadata object. Using
BigIntforheightandtimeMsensures proper handling of large numbers that could potentially overflow JavaScript's Number type limits.
141-148: Consistent approach to metadata validation using BigInt.The same pattern of individual property validation with BigInt conversions is appropriately applied in this test case as well, maintaining consistency with the pattern used throughout the codebase.
packages/wasm-dpp/src/document/mod.rs (2)
129-130: Enhanced type support by upgrading revision to u64.The function parameter type has been updated from
Option<u32>toOption<u64>to support larger revision numbers, which is a good change for future-proofing the system.
134-135: Streamlined get_revision implementation with u64 return type.The function return type has been updated from
Option<u32>toOption<u64>, and the implementation has been simplified to directly return the revision value without type casting. This ensures consistency with the set_revision method and maintains type safety.packages/js-dapi-client/lib/methods/platform/getStatus/getStatusFactory.js (3)
9-9: Updated import to match functionality.The import has been correctly updated to
GetStatusResponse, aligning with the function's purpose of fetching node status.
13-13: Corrected function documentation to reflect actual behavior.The JSDoc comments have been updated to accurately describe the function as fetching node status rather than identity information, improving code clarity and documentation accuracy.
Also applies to: 17-19, 20-20
48-48: Improved response handling using the dedicated factory method.The implementation now uses
GetStatusResponse.createFromProto(getStatusResponse)instead of directly accessing the V0 object properties, which is a more maintainable approach that properly encapsulates the response creation logic.packages/js-dapi-client/test/unit/methods/platform/getDataContract/getDataContractFactory.spec.js (2)
87-95: Enhanced test precision with property-specific BigInt assertions.The test now validates individual metadata properties with appropriate type conversions rather than comparing the entire metadata object, providing more precise assertions and better error messages when tests fail.
129-136: Consistent metadata validation approach in proof test case.This change maintains consistency with the first test case by using the same pattern of individual property validation with BigInt conversions when necessary.
packages/js-dapi-client/test/unit/methods/platform/getIdentity/getIdentityFactory.spec.js (1)
87-94: LGTM! Consistent handling of large integers.The changes correctly update the metadata assertions to handle
heightandtimeMsasBigIntvalues, which is essential for blockchain-related data where large integers are common.Also applies to: 123-130
packages/wasm-dpp/src/document/factory.rs (2)
23-28: LGTM! Better import organization.Moving imports to the top of the file improves code organization and readability.
131-137: LGTM! Safer nonce handling.Converting nonce from string parsing instead of f64 is a safer approach for handling large integers, preventing potential precision loss.
packages/js-dapi-client/test/unit/methods/platform/getDataContractHistory/getDataContractHistoryFactory.spec.js (1)
45-52: LGTM! Comprehensive BigInt implementation.The changes correctly implement BigInt handling across all relevant areas:
- Data contract history dates
- Start time parameter
- Metadata assertions
This ensures consistent and safe handling of large integers throughout the codebase.
Also applies to: 55-56, 59-60, 106-106, 115-115, 129-136, 165-165, 173-180
packages/js-dapi-client/lib/methods/platform/response/Metadata.js (1)
4-7: LGTM! Well-documented BigInt implementation.The changes correctly implement and document BigInt handling for height and timeMs properties:
- JSDoc clearly indicates support for both bigint and string inputs
- Constructor properly converts values to BigInt
- Getter return types are accurately documented
Also applies to: 10-13, 18-19, 34-35
packages/js-dapi-client/lib/methods/platform/getIdentityContractNonce/GetIdentityContractNonceResponse.js (4)
4-4: BigInt conversion for nonce filter valueThe constant now uses BigInt for the filter, which provides improved precision and range for large integers.
8-9: Updated type annotation from number to bigintThis type change correctly reflects the change from using JavaScript's native number to using bigint.
19-20: Updated return type annotation from number to bigintReturn type annotation now correctly indicates the method returns a bigint.
31-32: Updated proto conversion to use BigIntThe implementation now properly converts the proto value to BigInt before applying the filter.
packages/js-dash-sdk/src/SDK/Client/Platform/NonceManager/NonceManager.spec.ts (8)
24-26: Updated test to use BigInt for nonce valuesTests now properly use BigInt values instead of numbers, matching the implementation changes.
29-32: Updated mock response to use BigIntThe mock now correctly returns a BigInt value for the identity nonce.
35-43: Updated clock test to use BigInt valuesAll numeric nonce values in this test have been correctly converted to BigInt.
47-56: Updated bump nonce test to use BigInt arithmeticTest now uses BigInt for both the initial value and for the increment operation.
60-64: Updated identity contract nonce test to use BigIntIdentity contract nonce test now properly uses BigInt values.
67-72: Updated mock for contract nonce to use BigIntMock response for contract nonce now correctly uses BigInt.
75-88: Updated clock test for contract nonce to use BigIntClock test now correctly uses BigInt values for the contract nonce.
91-101: Updated bump contract nonce test to use BigIntTest for bumping contract nonce now correctly uses BigInt for values and arithmetic.
packages/js-dapi-client/lib/methods/platform/getIdentityNonce/GetIdentityNonceResponse.js (4)
4-4: BigInt conversion for nonce filter valueFilter constant now uses BigInt instead of number, ensuring proper handling of large integer values.
8-9: Updated parameter type annotation from number to bigintType annotation correctly reflects the change to using BigInt.
19-20: Updated return type annotation from number to bigintReturn type annotation now correctly indicates the method returns a bigint.
31-32: Updated proto conversion to use BigIntImplementation now properly converts the proto value to BigInt before applying the bitmask filter.
packages/js-dapi-client/test/unit/methods/platform/getIdentityKeys/getIdentityKeysFactory.spec.js (1)
176-183: Enhanced metadata assertions in proof testSimilar to the previous test, individual property assertions have been added for more detailed verification. This ensures proper type checking of BigInt values.
packages/wasm-dpp/test/integration/identity/IdentityFacade.spec.js (2)
35-35: Appropriate use of BigInt for balanceThe change from using a regular integer to BigInt is consistent with the apparent codebase refactoring for improved precision when handling balances.
184-184: Using BigInt for revision incrementThe change to add a BigInt to another BigInt is correct and consistent with the type system changes throughout the codebase.
packages/wasm-dpp/src/identity/state_transition/identity_update_transition/identity_update_transition.rs (1)
438-440: Updating method signature for revision to use u64Changing the return type from u32 to u64 increases the range of supported revision numbers, which is a good improvement for future-proofing.
packages/js-dapi-client/lib/methods/platform/getStatus/GetStatusResponse.js (4)
1-7: Well-organized imports for status componentsThe imports are logically structured and include all necessary status classes.
8-24: Clean implementation of GetStatusResponse classThe class constructor properly initializes all status components with appropriate JSDoc comments.
26-66: Well-documented getter methodsAll getter methods include proper JSDoc annotations and follow a consistent pattern.
68-161: Comprehensive static factory method with BigInt handlingThe
createFromProtomethod properly converts numerical values to BigInt where appropriate, which ensures precision is maintained when handling large numbers.packages/js-dapi-client/test/unit/methods/platform/getStatus/getStatusFactory.spec.js (4)
1-17: Complete imports for test dependenciesAll necessary classes and utilities for testing are properly imported.
18-92: Thorough test setup with complex fixture preparationThe test setup creates a detailed mock response based on fixtures, which provides a realistic test environment.
94-182: Comprehensive verification of status response parsingThe test thoroughly verifies each component of the status response, including proper BigInt conversion for numerical values.
184-278: Edge case testing for optional fieldsThe test properly handles cases where fields are missing, ensuring the code is robust against incomplete responses.
packages/wasm-dpp/src/document/extended_document.rs (1)
136-140: LGTM! Improved revision number range.The change from
u32tou64for revision numbers enhances the system's capability by:
- Increasing the maximum possible revision number
- Maintaining type safety through consistent numeric types
- Aligning with the broader initiative to handle larger integers
Also applies to: 143-145
packages/js-dapi-client/test/unit/methods/platform/getEpochsInfo/GetEpochsInfoResponse.spec.js (1)
26-26: LGTM! Enhanced numeric precision in tests.The changes improve test reliability by:
- Using BigInt for large numeric values
- Adding granular metadata assertions
- Maintaining consistency with the codebase's BigInt usage pattern
Also applies to: 83-90, 99-105, 125-132
packages/js-dapi-client/test/unit/methods/platform/getIdentityBalance/getIdentityBalanceFactory.spec.js (1)
30-30: LGTM! Improved balance and metadata handling.The changes enhance test reliability by:
- Using BigInt for balance values
- Adding detailed metadata assertions
- Maintaining consistency with the codebase's BigInt usage
Also applies to: 88-95, 124-131
packages/js-dapi-client/test/unit/methods/platform/getDocuments/getDocumentsFactory.spec.js (1)
113-120: LGTM! Enhanced metadata assertions.The changes improve test quality by:
- Breaking down metadata assertions into granular checks
- Using BigInt for numeric values consistently
- Maintaining alignment with the codebase's BigInt usage pattern
Also applies to: 154-161, 195-202
packages/js-dapi-client/test/unit/methods/platform/getStatus/GetStatusResponse.spec.js (3)
21-70: LGTM! Well-structured test setup.The test setup is comprehensive and properly initializes all required fixtures and mocks.
91-98: Improved test assertions with granular checks.The test now validates individual metadata properties with explicit type conversions to BigInt where appropriate, which is more precise than the previous deep equality check.
127-134: Consistent metadata validation pattern.The second test case follows the same granular validation pattern as the first test, maintaining consistency in the test suite.
packages/wasm-dpp/src/document/state_transition/batch_transition/document_transition/mod.rs (2)
98-100: Improved type safety in revision handling.The
get_revisionmethod now returnsOption<Revision>directly instead of converting to JsValue, which provides better type safety and eliminates unnecessary conversions.
131-133: Enhanced numeric precision with u64.The
set_revisionmethod now usesu64instead ofu32, allowing for a broader range of revision values while maintaining type consistency across the codebase.packages/js-dapi-client/test/unit/methods/platform/getProtocolVersionUpgradeState/getProtocolVersionUpgradeStateFactory.spec.js (2)
91-98: Enhanced metadata validation with explicit type checks.The test now validates individual metadata properties with proper type conversions, improving the precision of the assertions.
127-134: Consistent metadata validation pattern maintained.The second test case follows the same granular validation pattern, ensuring consistency across test cases.
packages/wasm-dpp/src/errors/consensus/fee/balance_is_not_enough_error.rs (2)
32-34: Improved numeric precision for balance values.The
get_balancemethod now returnsu64instead off64, providing exact precision for balance values without floating-point rounding issues.
37-39: Enhanced fee value precision.The
get_feemethod now returnsu64instead off64, maintaining consistency with the balance type and ensuring exact precision for fee values.packages/js-dapi-client/lib/methods/platform/getTotalCreditsInPlatform/GetTotalCreditsInPlatformResponse.js (1)
6-6: LGTM! Consistent type updates for large integer handling.The changes correctly update the types from
numbertobigintand ensure proper conversion usingBigInt()in the proto handling. This aligns with the broader effort to standardize large integer handling across the codebase.Also applies to: 17-17, 29-29
packages/js-dapi-client/test/unit/methods/platform/getDataContractHistory/GetDataContractHistoryResponse.spec.js (2)
28-35: LGTM! Well-structured fixture data.The fixture data is now properly structured as an array of objects with BigInt dates and buffer values, which is a cleaner and more maintainable approach.
151-158: LGTM! Proper metadata handling.The metadata handling is correctly updated to include timeMs and protocolVersion, with proper BigInt conversions where needed.
packages/js-dapi-client/lib/methods/platform/getEpochsInfo/EpochInfo.js (1)
5-5: LGTM! Consistent type updates.The changes correctly update the types from
numbertobigintforfirstBlockHeightandstartTime, maintaining consistency with the codebase's BigInt standardization.Also applies to: 6-7, 26-26, 40-40
packages/platform-test-suite/test/e2e/withdrawals.spec.js (1)
175-175: LGTM! Proper BigInt arithmetic.The arithmetic operations correctly use BigInt multiplication and division.
Also applies to: 190-190
packages/js-dapi-client/lib/methods/platform/getDataContractHistory/getDataContractHistoryFactory.js (2)
21-21: Update JSDoc parameter type to match implementation.The JSDoc type for
startAtMshas been updated tobigintto match the implementation. This change improves type safety when handling large timestamps.
29-29:✅ Verification successful
Verify BigInt conversion and string representation.
The code correctly:
- Initializes
startAtMswithBigInt(0)as default value- Converts
startAtMsto string when setting it in the requestThis ensures proper handling of large timestamps throughout the data flow.
Also applies to: 48-48
🏁 Script executed:
#!/bin/bash # Description: Verify consistent BigInt usage for startAtMs parameter # Test: Search for startAtMs usage to ensure consistent type handling rg -A 2 'startAtMs'Length of output: 11620
Action Required: Confirming Correct BigInt Handling for startAtMs
The code in
packages/js-dapi-client/lib/methods/platform/getDataContractHistory/getDataContractHistoryFactory.jscorrectly initializesstartAtMsasBigInt(0)(line 29) and subsequently converts it to a string when setting the request parameter. This ensures reliable handling of large timestamps, and our repository search confirms that similar patterns are consistently applied across related files (e.g., in the Node.js protocol files).No changes are required.
packages/platform-test-suite/test/functional/platform/Identity.spec.js (3)
232-232: Improve balance comparison clarity.The balance comparison has been updated to use explicit boolean comparison with
to.be.true(). This change makes the test assertions more explicit and aligns with BigInt comparison requirements.Also applies to: 320-320
422-422: Ensure correct BigInt arithmetic in credit transfer tests.The changes correctly handle BigInt arithmetic for:
- Converting topUpAmount to credits using
BigInt- Comparing balances before and after transfers
- Handling balance differences with proper BigInt operations
Also applies to: 433-435, 551-556
622-622: Ensure consistent revision handling with BigInt.The revision comparison has been updated to use BigInt arithmetic, ensuring precise handling of revision numbers in identity updates.
Also applies to: 654-654
packages/js-dash-sdk/src/SDK/Client/Platform/methods/contracts/history.ts (2)
15-17: Update parameter type documentation.The JSDoc parameter types have been correctly updated to reflect:
startAtMsasbigintlimitandoffsetasnumber
23-23: Improve contract history data handling.The changes correctly:
- Update
startAtMsparameter type tobigint- Simplify iteration over contract history entries
- Handle date conversion from BigInt to Number
Also applies to: 45-51
packages/wasm-dpp/src/identity/identity.rs (3)
108-110: Improve balance getter precision.The balance getters have been updated to use
u64instead of floating-point numbers, providing better precision and type safety for balance values.Also applies to: 113-115
118-120: Enhance balance operations type safety.Balance operations (set, increase, reduce) have been updated to use
u64, ensuring:
- No precision loss during arithmetic operations
- Proper handling of large balance values
- Consistent type usage across the codebase
Also applies to: 123-125, 128-130
133-135: Improve revision handling precision.The revision getter and setter have been updated to use
u64, providing better precision and type safety for revision numbers.Also applies to: 138-140
packages/js-dapi-client/lib/methods/platform/getDataContractHistory/GetDataContractHistoryResponse.js (4)
3-3: LGTM!The import of
DataContractHistoryEntryis correctly added to support the new data structure.
7-7: LGTM!The constructor parameter type is correctly updated to use an array of
DataContractHistoryEntryobjects, improving type safety.
18-18: LGTM!The return type documentation is correctly updated to reflect the array return type.
38-42: LGTM!The
createFromProtomethod is correctly updated to:
- Map proto entries to
DataContractHistoryEntryobjects- Convert date to
BigIntfor precision- Handle null case appropriately
packages/wasm-dpp/src/metadata.rs (2)
37-42: LGTM!The constructor signature is correctly updated to use explicit numeric types (
u64,u32) instead of deserializing from JSON, improving type safety and reducing potential precision loss.
71-72: LGTM!The getter methods are correctly updated to:
- Return
u64forblock_heightandtime_ms- Return
u32forcore_chain_locked_heightandprotocol_version- Cast values appropriately where needed
This change improves type safety and prevents potential precision loss when handling large numbers.
Also applies to: 76-77, 81-82, 86-87
packages/wasm-dpp/src/identity/state_transition/identity_credit_transfer_transition/transition.rs (3)
93-94: LGTM!The amount getter and setter methods are correctly updated to use
u64instead off64, preventing potential precision loss when handling large amounts.Also applies to: 98-99
104-104: LGTM!The code is correctly simplified by:
- Directly returning the user fee increase without casting
- Removing unnecessary
-> ()return type annotation fromset_nonceAlso applies to: 118-118
184-184: LGTM!The amount serialization in
toObjectandtoJSONmethods is correctly updated to usebigint_from_str, ensuring that large numbers are properly handled in JavaScript.Also applies to: 259-259
packages/js-dapi-client/lib/BlockHeadersProvider/BlockHeadersProvider.js (3)
8-11: LGTM!The
BlockHeadersProviderOptionsdocumentation is correctly updated to:
- Use quotes for the default network value
- Add documentation for the
fromBlockHeightproperty
39-41: LGTM!The method parameter documentation is correctly updated to:
- Specify
BlockHeadersProviderOptionstype for options- Clarify that
BlockHeadersReaderandSpvChainparameters are instancesAlso applies to: 64-64, 72-72
108-109: LGTM!The parameter type documentation is correctly updated to:
- Specify
BlockHeader[]type for headers array- Add
numbertype for block heights- Clarify object and function types for headers handler
Also applies to: 200-201
packages/js-dash-sdk/src/SDK/Client/Platform/NonceManager/NonceManager.ts (6)
26-38: LGTM! Clean implementation.The method correctly handles the bigint nonce parameter while maintaining the existing logic.
74-81: LGTM! Proper bigint usage.The method correctly uses bigint arithmetic with the
1nliteral for incrementing the nonce.
83-104: LGTM! Clean implementation.The method correctly handles the bigint nonce parameter while maintaining the existing logic.
40-72:❓ Verification inconclusive
Verify DAPI client compatibility.
The method now returns
bigint, but we should verify thatdapiClient.platform.getIdentityNoncereturns the correct type.Let's check the DAPI client implementation:
🏁 Script executed:
#!/bin/bash # Search for getIdentityNonce implementation in DAPI client ast-grep --pattern 'getIdentityNonce($_) { $$$' packages/js-dapi-client/Length of output: 74
Verify DAPI Client Return Type for Identity Nonce
The changes now return a
bigintfromgetIdentityNonce, but no concrete evidence was found in the DAPI client's code (using our initial ast-grep query) to confirm that its implementation returns abigint. Please manually verify thatdapiClient.platform.getIdentityNonceindeed returns abigintso the consuming code remains correct.
4-7:✅ Verification successful
LGTM! Note the breaking change.
The transition from
numbertobigintfor nonce values is a good improvement for handling large numbers without precision loss. However, this is a breaking change that requires updates in consuming code.Let's verify the impact on consumers:
🏁 Script executed:
#!/bin/bash # Search for direct usage of NonceState type rg -A 2 "NonceState" --type tsLength of output: 850
LGTM – Transition to
bigintis well implemented.
Based on our search, theNonceStatetype is only used internally within theNonceManager(specifically in theidentityNonceandidentityContractNoncemaps). This means that while the switch fromnumbertobigintis a breaking change in theory, it doesn't seem to impact any external consumers at this time. Still, if any public APIs eventually expose these types or if external code relies on them, they might need to be updated accordingly.
106-152:✅ Verification successful
Verify DAPI client compatibility.
The method now returns
bigint, but we should verify thatdapiClient.platform.getIdentityContractNoncereturns the correct type.Let's check the DAPI client implementation:
🏁 Script executed:
#!/bin/bash # Search for getIdentityContractNonce implementation in DAPI client ast-grep --pattern 'getIdentityContractNonce($_) { $$$' packages/js-dapi-client/Length of output: 82
🏁 Script executed:
#!/bin/bash # Re-run the search for "getIdentityContractNonce" in the js-dapi-client package using ripgrep for a broader search: rg "getIdentityContractNonce" packages/js-dapi-client/Length of output: 9461
DAPI Client Compatibility Confirmed
After reviewing the output from the broader search and the corresponding tests (notably in
packages/js-dapi-client/test/unit/methods/platform/getIdentityContractNonce/getIdentityContractNonceFactory.spec.js), the DAPI client’sgetIdentityContractNonceimplementation is shown to return a value consistent withbigint. The test asserts (e.g., comparing againstBigInt(0)) that the expected type is correctly produced.No further modifications are necessary on this front.
packages/dapi-grpc/clients/platform/v0/nodejs/platform_protoc.js (88)
6731-6734: Use of string-based fields for 'height' and 'timeMs'.
Converting to strings for 64-bit integer fields in JS is a common approach to avoid overflow issues. Looks correct.
6774-6774: Reading 'height' as a string.
UsingreadUint64String()is consistent with storing the field as a string.
6786-6786: Reading 'timeMs' as a string.
This aligns with the move to string-based 64-bit fields.
6827-6831: Conditional writing of 'height'.
Checking withparseInt(f, 10) !== 0before callingwriteUint64String()is a standard pattern for skipping zero values.
6848-6852: Conditional writing of 'timeMs'.
Same pattern as above: skip writing if the field is zero.
6873-6885: Getter/Setter for 'height'.
Both the getter and setter store and retrieve the field as a string; this is consistent with the earlier changes.
6927-6939: Getter/Setter for 'timeMs'.
Switching to a string return type and usingsetProto3StringIntField()is correct for uint64 fields in JS.
9975-9975: Using string for 'identityNonce'.
Correct for large numeric fields, ensures no overflow in JS.
10015-10015: Reading 'identityNonce' as string.
readUint64String()aligns with the new field type.
10057-10062: Conditional serialization for 'identityNonce'.
Ensuring we only write if the value is non-zero.
10085-10096: Getter/Setter for 'identityNonce'.
Consistently using string-based methods. Looks good.
10427-10430: String-based 'identityContractNonce'.
Maintains consistency with 64-bit integer handling in JS.
10467-10470: Reading 'identityContractNonce' as string.
Again, correct approach for large numeric fields.
10509-10514: Conditional serialization of 'identityContractNonce'.
Only writes the field if parseInt(...) != 0.
10537-10548: Getter/Setter for 'identityContractNonce'.
Switching to string-based get/set. No issues.
10879-10882: String field for 'balance'.
Consistent with handling large balances in JS.
10919-10922: Reading 'balance' as string.
Matches the approach for other uint64 fields.
10961-10966: Conditional serialization of 'balance'.
Skipping zero values via parseInt check.
10989-11000: Getter/Setter for 'balance'.
Correct shift to strings for large numeric values.
11473-11475: String fields 'balance' and 'revision'.
Appropriate for 64-bit values in JavaScript.
11512-11519: Reading 'balance' and 'revision' as strings.
Prevents overflow for large values.
11549-11560: Conditional writing of 'balance' and 'revision'.
Skipping zero in string form is consistent with the approach.
11564-11600: Getter/Setter for 'balance' and 'revision'.
Each now uses Proto3 string-based fields. Looks fine.
16062-16065: String-based 'count' field.
Consistent strategy to store uint64.
16104-16107: Reading 'count' as string.
Proper for large numeric values.
16144-16148: Conditional write for 'count'.
Skipping if parseInt(...) is 0.
16194-16210: Getter/Setter for 'count'.
Storing the value as string eliminates potential overflow.
17819-17821: String-based 'balance' in IdentityBalance.
Same pattern for large numeric fields.
17861-17864: Reading 'balance' as string.
UsingreadUint64String()is consistent with earlier changes.
17900-17905: Conditional serialization of 'balance' in IdentityBalance.
Checking parseInt(...) before writing.
17951-17965: Getter/Setter for 'balance' in IdentityBalance.
Handling the field as a string with default "0".
23318-23321: Moved 'startAtMs' to a string-based field.
Ensures no overflow for potentially large timestamps.
23371-23374: Reading 'startAtMs' as a string.
UsingreadUint64String()suits large numeric values.
23431-23435: Conditional writing of 'startAtMs'.
parseInt(...) check is consistent with skipping zero.
23565-23579: Getter/Setter for 'startAtMs'.
Returning and setting string-based timestamps is correct.
23975-23978: String-based 'date' in DataContractHistoryEntry.
Large timestamps as strings avoid numeric precision issues.
24014-24017: Reading 'date' as string.
Remains consistent with large numeric approach.
24051-24055: Conditional serialization for 'date'.
Skipping if parseInt(...) is zero.
24066-24083: Getter/Setter for 'date'.
Using standard Proto3 string fields for timestamps.
31699-31705: 'firstBlockHeight' and 'startTime' switched to strings.
Prevents overflow for block height/time.
31746-31757: Reading 'firstBlockHeight' and 'startTime' as strings.
readUint64String()is appropriate for large numeric data.
31799-31806: Conditional write for 'firstBlockHeight'.
Skipping zero value in string form.
31813-31820: Conditional write for 'startTime'.
Same approach of parseInt(...) check.
31856-31873: Getter/Setter for 'firstBlockHeight'.
Converts to/from string. Looks fine.
31892-31909: Getter/Setter for 'startTime'.
String-based time value ensures large timestamp support.
33963-33966: 'startTimeMs' uses a string-based field.
Consistent with large numeric timestamp handling.
34002-34005: Reading 'startTimeMs' as string.
Correct usage ofreadUint64String().
34039-34043: Conditional serialization of 'startTimeMs'.
Avoiding writing zero values.
34054-34071: Getter/Setter for 'startTimeMs'.
No issues with storing as string.
34123-34126: 'endTimeMs' as a string-based field.
Good for large timestamps.
34162-34165: Reading 'endTimeMs' as string.
UsingreadUint64String()maintains consistency.
34199-34203: Conditional write for 'endTimeMs'.
Skipping zero if parseInt(...) returns 0.
34214-34231: Getter/Setter for 'endTimeMs'.
Same string-based approach for 64-bit timestamps.
34816-34819: 'timestamp' shifted to string.
Ensures no overflow for large values.
34855-34858: Reading 'timestamp' as string.
Correct usage of readUint64String().
34892-34896: Conditional serialization of 'timestamp'.
Skipping if parseInt(...) is zero.
34907-34924: Getter/Setter for 'timestamp'.
Staying consistent with the string approach.
36518-36522: String-based fields: 'finishedAtBlockHeight', 'finishedAtBlockTimeMs'.
Large block heights/time handled safely.
36567-36578: Reading 'finishedAtBlockHeight' and 'finishedAtBlockTimeMs' as strings.
Correct for large numeric fields.
36623-36630: Conditional write for 'finishedAtBlockHeight'.
Skipping zero integer via parseInt.
36637-36644: Conditional write for 'finishedAtBlockTimeMs'.
Same skip-if-zero approach as above.
36742-36760: Getter/Setter for 'finishedAtBlockHeight'.
No overflow issues as it’s string-based.
36778-36796: Getter/Setter for 'finishedAtBlockTimeMs'.
Consistent string field usage.
41531-41534: String-based 'balance'.
Same established pattern for large numeric fields.
41571-41574: Reading 'balance' as string.
readUint64String()for safe large integer handling.
41613-41618: Conditional write of 'balance'.
Skipping zero in string form.
41638-41652: Getter/Setter for 'balance'.
Proto3 strings for big numeric values.
42289-42292: String field 'credits'.
Appropriate for large numeric totals.
42329-42332: Reading 'credits' as string.
Consistent usage ofreadUint64String().
42371-42376: Conditional serialization for 'credits'.
Skipping if parseInt(...) is zero.
42396-42410: Getter/Setter for 'credits'.
Employing string-based method for large amounts.
45220-45223: Strings for 'local', 'block', 'genesis' times.
Helps avoid integer overflow in JavaScript.
45261-45272: Reading 'local', 'block', 'genesis' as strings.
readUint64String()approach is consistent.
45306-45324: Conditional writes for 'local', 'block', 'genesis'.
Parse check to skip zero.
45335-45367: Getter/Setter for 'local' and 'block'.
Adopts string-based pattern. No concerns.
45389-45403: Getter/Setter for 'genesis'.
Consistent with the other time fields.
45723-45730: Switched 'latestBlockHeight', 'earliestBlockHeight', 'maxPeerBlockHeight' to strings.
Proper for large block heights in JS.
45778-45781: Reading 'latestBlockHeight' as string.
Aligned with the new string-based approach.
45790-45797: Reading 'earliestBlockHeight' and 'maxPeerBlockHeight' as strings.
Protects from overflow.
45849-45856: Conditional write of 'latestBlockHeight'.
Skipping zero ensures minimal output.
45870-45884: Conditional write of 'earliestBlockHeight' and 'maxPeerBlockHeight'.
Continued parseInt-zero check.
45997-46013: Getter/Setter for 'latestBlockHeight'.
Uses default "0" string. Approved.
46099-46133: Getter/Setter for 'earliestBlockHeight' and 'maxPeerBlockHeight'.
String-based fields for block heights.
46394-46404: String-based fields in StateSync: 'totalSyncedTime', 'remainingTime', etc.
Ensures large numeric values aren't truncated.
46439-46470: Reading multiple fields ('totalSyncedTime', 'remainingTime', etc.) as strings.
Unified approach for all time-based fields.
46497-46511: Conditional write of 'totalSyncedTime' and 'remainingTime'.
Skipping zero values with parseInt(...).
46518-46553: Conditional write for 'chunkProcessAvgTime', 'snapshotHeight', 'snapshotChunksCount', 'backfilledBlocks', 'backfillBlocksTotal'.
Same parseInt(...) approach to skip defaults.
46557-46701: Getter/Setter for all StateSync string fields.
All previously numeric fields now stored as string with default "0". This finalizes the shift to string-based representation.packages/dapi-grpc/clients/platform/v0/web/platform_pb.js (89)
6731-6731: Use of string-based fields for 64-bit integers is recommended
Reading and writing large integers as strings is recommended to avoid precision loss. This chunk looks good. Ensure that any numeric usage in the code is updated to parse them as needed.Also applies to: 6734-6734
6774-6774: Same pattern.
6786-6786: Same pattern.
6827-6827: Same pattern.Also applies to: 6828-6828
6848-6848: Same pattern.Also applies to: 6849-6849
6873-6873: Same pattern.Also applies to: 6876-6876, 6881-6881, 6884-6884, 6885-6885
6927-6927: Same pattern.Also applies to: 6930-6930, 6935-6935, 6939-6939
9975-9975: Same pattern.
10015-10015: Same pattern.
10057-10057: Same pattern.
10085-10085: Same pattern.Also applies to: 10088-10088, 10093-10093
10427-10427: Same pattern.
10467-10467: Same pattern.
10509-10509: Same pattern.
10537-10537: Same pattern.Also applies to: 10540-10540, 10545-10545
10879-10879: Same pattern.
10919-10919: Same pattern.
10961-10961: Same pattern.
10989-10989: Same pattern.
11473-11473: Same pattern.Also applies to: 11474-11474
11512-11512: Same pattern.Also applies to: 11516-11516
11549-11549: Same pattern.Also applies to: 11550-11550, 11557-11557, 11558-11558
11567-11567: Same pattern.Also applies to: 11570-11570, 11575-11575, 11579-11579, 11585-11585, 11588-11588, 11593-11593, 11597-11597
16062-16062: Same pattern.
16104-16104: Same pattern.
16144-16144: Same pattern.Also applies to: 16145-16145
16199-16199: Same pattern.Also applies to: 16205-16205, 16209-16209
17819-17819: Same pattern.
17861-17861: Same pattern.
17900-17900: Same pattern.Also applies to: 17902-17902
17954-17954: Same pattern.Also applies to: 17957-17957, 17962-17962, 17965-17965
23318-23318: Same pattern.
23371-23371: Same pattern.Also applies to: 23372-23372
23431-23431: Same pattern.Also applies to: 23432-23432
23565-23565: Same pattern.Also applies to: 23568-23568, 23573-23573, 23577-23577
23975-23975: Same pattern.
24014-24014: Same pattern.
24051-24051: Same pattern.Also applies to: 24052-24052
24069-24069: Same pattern.Also applies to: 24072-24072, 24077-24077, 24081-24081
31700-31700: Same pattern.Also applies to: 31702-31702
31746-31746: Same pattern.Also applies to: 31747-31747, 31754-31754, 31755-31755
31802-31802: Same pattern.Also applies to: 31803-31803
31816-31816: Same pattern.Also applies to: 31817-31817
31859-31859: Same pattern.Also applies to: 31862-31862, 31867-31867, 31871-31871
31895-31895: Same pattern.Also applies to: 31898-31898, 31903-31903, 31907-31907
33963-33963: Same pattern.
34002-34002: Same pattern.
34039-34039: Same pattern.Also applies to: 34040-34040
34057-34057: Same pattern.Also applies to: 34060-34060, 34065-34065, 34069-34069
34123-34123: Same pattern.
34162-34162: Same pattern.
34199-34199: Same pattern.Also applies to: 34200-34200
34217-34217: Same pattern.Also applies to: 34220-34220, 34225-34225, 34229-34229
34816-34816: Same pattern.
34855-34855: Same pattern.
34892-34892: Same pattern.Also applies to: 34893-34893
34910-34910: Same pattern.Also applies to: 34913-34913, 34918-34918, 34922-34922
36518-36518: Same pattern.Also applies to: 36520-36520
36567-36567: Same pattern.Also applies to: 36576-36576
36626-36626: Same pattern.Also applies to: 36627-36627
36640-36640: Same pattern.Also applies to: 36641-36641
36745-36745: Same pattern.Also applies to: 36748-36748, 36753-36753, 36757-36757
36781-36781: Same pattern.Also applies to: 36784-36784, 36789-36789, 36793-36793
41531-41531: Same pattern.
41571-41571: Same pattern.
41613-41613: Same pattern.
41641-41641: Same pattern.Also applies to: 41644-41644, 41649-41649
42289-42289: Same pattern.
42329-42329: Same pattern.
42371-42371: Same pattern.Also applies to: 42373-42373
42399-42399: Same pattern.Also applies to: 42402-42402, 42407-42407
45220-45220: Same pattern.Also applies to: 45221-45221, 45222-45222
45261-45261: Same pattern.Also applies to: 45265-45265, 45269-45269
45306-45306: Same pattern.Also applies to: 45307-45307, 45312-45312, 45314-45314, 45319-45319, 45321-45321
45338-45338: Same pattern.Also applies to: 45341-45341, 45346-45346, 45350-45350, 45356-45356, 45359-45359, 45364-45364, 45367-45367
45392-45392: Same pattern.Also applies to: 45395-45395, 45400-45400, 45403-45403
45723-45723: Same pattern.Also applies to: 45726-45726, 45727-45727
45778-45778: Same pattern.Also applies to: 45779-45779
45790-45790: Same pattern.Also applies to: 45791-45791, 45794-45794, 45795-45795
45852-45852: Same pattern.Also applies to: 45853-45853
45873-45873: Same pattern.Also applies to: 45874-45874, 45880-45880, 45881-45881
46000-46000: Same pattern.Also applies to: 46003-46003
46102-46102: Same pattern.Also applies to: 46105-46105, 46110-46110, 46114-46114, 46120-46120, 46123-46123, 46128-46128, 46132-46132
46394-46394: Same pattern.Also applies to: 46395-46395, 46397-46397, 46398-46398, 46399-46399, 46400-46400, 46401-46401
46439-46439: Same pattern.Also applies to: 46440-46440, 46443-46443, 46444-46444, 46451-46451, 46452-46452, 46455-46455, 46456-46456, 46459-46459, 46460-46460, 46463-46463, 46464-46464, 46467-46467, 46468-46468
46500-46500: Same pattern.Also applies to: 46501-46501
46507-46507: Same pattern.Also applies to: 46508-46508, 46521-46521, 46522-46522, 46528-46528, 46529-46529, 46535-46535, 46536-46536, 46542-46542, 46543-46543, 46549-46549, 46550-46550
46560-46560: Same pattern.Also applies to: 46563-46563, 46568-46568, 46572-46572, 46578-46578, 46581-46581, 46586-46586, 46590-46590
46649-46649: Same pattern.packages/dapi-grpc/protos/platform/v0/platform.proto (18)
83-89: Applied JS_STRING annotations for blockchain height and timestamp.
The updatedheightandtime_msfields in theResponseMetadatamessage now include[jstype = JS_STRING], ensuring that large numeric values are safely handled in JavaScript.
176-182: Updated identity_nonce field type for precise value handling.
In theGetIdentityNonceResponsemessage, theidentity_noncefield now uses[jstype = JS_STRING]to preserve numeric precision in JavaScript environments.
189-196: Updated identity_contract_nonce field type for consistent JS representation.
Theidentity_contract_noncefield in theGetIdentityContractNonceResponsemessage now uses[jstype = JS_STRING], which helps in avoiding precision issues in JavaScript.
201-208: Ensured balance field uses string type for correct numeric precision.
Thebalancefield in theGetIdentityBalanceResponsemessage has been updated with[jstype = JS_STRING]to manage large balance values more reliably in JavaScript.
215-219: Applied JS_STRING annotations for both balance and revision values.
In theGetIdentityBalanceAndRevisionResponsemessage, both thebalanceandrevisionfields in the nestedBalanceAndRevisionmessage now use[jstype = JS_STRING], ensuring precise handling of large numbers.
341-345: Updated count field for evonodes proposed epoch blocks.
In theGetEvonodesProposedEpochBlocksResponsemessage, thecountfield now uses[jstype = JS_STRING]to improve compatibility with JavaScript for large numerical counts.
389-392: Refined identities balance field type for accurate value representation.
The optionalbalancein theIdentityBalancemessage of theGetIdentitiesBalancesResponsenow utilizes[jstype = JS_STRING], ensuring high-precision handling of numeric balances.
537-542: Updated start_at_ms field for data contract history query.
Thestart_at_msfield in theGetDataContractHistoryRequestmessage now uses[jstype = JS_STRING]to reliably represent large millisecond timestamps.
549-553: Applied JS_STRING annotation for history entry date.
Thedatefield in theDataContractHistoryEntrymessage of theGetDataContractHistoryResponsenow uses[jstype = JS_STRING]to handle large date values accurately in JavaScript.
828-832: Updated start_time_ms field in vote polls request message.
Within theStartAtTimeInfomessage of theGetVotePollsByEndDateRequest, thestart_time_msfield now includes[jstype = JS_STRING]for improved precision in JavaScript.
851-855: Modified timestamp field in vote polls response for robust type handling.
In theSerializedVotePollsByTimestampmessage of theGetVotePollsByEndDateResponse, updatingtimestampto[jstype = JS_STRING]ensures that large timestamp values are processed correctly in JavaScript.
1053-1058: Ensured prefunded specialized balance is string-typed.
Thebalancefield in theGetPrefundedSpecializedBalanceResponsemessage now uses[jstype = JS_STRING], which is important for managing large financial values reliably.
1076-1081: Applied JS_STRING annotation for total credits.
Thecreditsfield in theGetTotalCreditsInPlatformResponsemessage has been updated with[jstype = JS_STRING]to avoid precision loss when handling large numerical values in JavaScript.
764-770: Updated epoch information fields to use JS_STRING.
In theEpochInfomessage of theGetEpochsInfoResponse, bothfirst_block_heightandstart_timenow include[jstype = JS_STRING], ensuring that large epoch-related numbers are represented accurately in JS.
910-916: Enhanced FinishedVoteInfo with string-typed fields.
The fieldsfinished_at_block_heightandfinished_at_block_time_msin theFinishedVoteInfomessage of theGetContestedResourceVoteStateResponsenow use[jstype = JS_STRING], which is crucial for retaining precision.
1158-1165: Updated Time fields in GetStatusResponse to JS_STRING.
Thelocal,block, andgenesistime fields in theTimemessage now include[jstype = JS_STRING], ensuring that large timestamp values are correctly handled in JavaScript.
1178-1185: Modified Chain fields for consistent numeric handling.
The fieldslatest_block_height,earliest_block_height, andmax_peer_block_heightin theChainmessage have been updated with[jstype = JS_STRING]to ensure precise processing of large numbers in JavaScript.
1195-1204: Refined StateSync fields for accurate time and snapshot metrics.
All numeric fields in theStateSyncmessage (total_synced_time,remaining_time,chunk_process_avg_time,snapshot_height,snapshot_chunks_count,backfilled_blocks, andbackfill_blocks_total) have been updated to[jstype = JS_STRING], ensuring robust handling of large values in JavaScript.
| id: new Uint8Array(Buffer.from('QbMI9zfKnjn2e1UxWJAxmKiMUW4=', 'base64')), | ||
| proTxHash: new Uint8Array(Buffer.from('s7V0hXG2D+mtEScV1qUXJdblpSqcOvX9NqFyTPUNhi8=', 'base64')), | ||
| }, |
There was a problem hiding this comment.
💡 Verification agent
🧩 Analysis chain
Consider adding validation for base64 encoded values.
The fixture uses base64 encoded values for binary data. Consider adding validation to ensure the base64 strings are valid.
🏁 Script executed:
#!/bin/bash
# Verify base64 strings are valid
echo "QbMI9zfKnjn2e1UxWJAxmKiMUW4=" | base64 -d > /dev/null 2>&1 && \
echo "s7V0hXG2D+mtEScV1qUXJdblpSqcOvX9NqFyTPUNhi8=" | base64 -d > /dev/null 2>&1 && \
echo "Base64 strings are valid" || echo "Invalid base64 strings detected"Length of output: 120
Invalid Base64 Strings in Fixture
The base64 check indicates that at least one of the provided strings (specifically "QbMI9zfKnjn2e1UxWJAxmKiMUW4=") fails to decode properly. Please update the fixture (located in packages/js-dapi-client/lib/test/fixtures/getStatusFixture.js at lines 24–26) with valid base64 values or add explicit validation to catch and handle invalid data.
| constructor( | ||
| catchingUp, | ||
| latestBlockHash, | ||
| latestAppHash, | ||
| latestBlockHeight, | ||
| earliestBlockHash, | ||
| earliestAppHash, | ||
| earliestBlockHeight, | ||
| maxPeerBlockHeight, | ||
| coreChainLockedHeight, | ||
| ) { | ||
| this.catchingUp = catchingUp; | ||
| this.latestBlockHash = latestBlockHash; | ||
| this.latestAppHash = latestAppHash; | ||
| this.latestBlockHeight = latestBlockHeight; | ||
| this.earliestBlockHash = earliestBlockHash; | ||
| this.earliestAppHash = earliestAppHash; | ||
| this.earliestBlockHeight = earliestBlockHeight; | ||
| this.maxPeerBlockHeight = maxPeerBlockHeight; | ||
| this.coreChainLockedHeight = coreChainLockedHeight || null; | ||
| } |
There was a problem hiding this comment.
🛠️ Refactor suggestion
Add input validation for block heights and hash values.
The constructor should validate the format of hash values and ensure block heights are non-negative.
constructor(
catchingUp,
latestBlockHash,
latestAppHash,
latestBlockHeight,
earliestBlockHash,
earliestAppHash,
earliestBlockHeight,
maxPeerBlockHeight,
coreChainLockedHeight,
) {
+ if (typeof catchingUp !== 'boolean') {
+ throw new Error('catchingUp must be a boolean');
+ }
+ if (!/^[0-9a-f]{64}$/i.test(latestBlockHash)) {
+ throw new Error('latestBlockHash must be a 32-byte hex string');
+ }
+ if (!/^[0-9a-f]{64}$/i.test(latestAppHash)) {
+ throw new Error('latestAppHash must be a 32-byte hex string');
+ }
+ if (typeof latestBlockHeight !== 'bigint' || latestBlockHeight < 0n) {
+ throw new Error('latestBlockHeight must be a non-negative bigint');
+ }
+ // Add similar validations for other parameters
this.catchingUp = catchingUp;
this.latestBlockHash = latestBlockHash;
this.latestAppHash = latestAppHash;
this.latestBlockHeight = latestBlockHeight;
this.earliestBlockHash = earliestBlockHash;
this.earliestAppHash = earliestAppHash;
this.earliestBlockHeight = earliestBlockHeight;
this.maxPeerBlockHeight = maxPeerBlockHeight;
this.coreChainLockedHeight = coreChainLockedHeight || null;
}📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| constructor( | |
| catchingUp, | |
| latestBlockHash, | |
| latestAppHash, | |
| latestBlockHeight, | |
| earliestBlockHash, | |
| earliestAppHash, | |
| earliestBlockHeight, | |
| maxPeerBlockHeight, | |
| coreChainLockedHeight, | |
| ) { | |
| this.catchingUp = catchingUp; | |
| this.latestBlockHash = latestBlockHash; | |
| this.latestAppHash = latestAppHash; | |
| this.latestBlockHeight = latestBlockHeight; | |
| this.earliestBlockHash = earliestBlockHash; | |
| this.earliestAppHash = earliestAppHash; | |
| this.earliestBlockHeight = earliestBlockHeight; | |
| this.maxPeerBlockHeight = maxPeerBlockHeight; | |
| this.coreChainLockedHeight = coreChainLockedHeight || null; | |
| } | |
| constructor( | |
| catchingUp, | |
| latestBlockHash, | |
| latestAppHash, | |
| latestBlockHeight, | |
| earliestBlockHash, | |
| earliestAppHash, | |
| earliestBlockHeight, | |
| maxPeerBlockHeight, | |
| coreChainLockedHeight, | |
| ) { | |
| if (typeof catchingUp !== 'boolean') { | |
| throw new Error('catchingUp must be a boolean'); | |
| } | |
| if (!/^[0-9a-f]{64}$/i.test(latestBlockHash)) { | |
| throw new Error('latestBlockHash must be a 32-byte hex string'); | |
| } | |
| if (!/^[0-9a-f]{64}$/i.test(latestAppHash)) { | |
| throw new Error('latestAppHash must be a 32-byte hex string'); | |
| } | |
| if (typeof latestBlockHeight !== 'bigint' || latestBlockHeight < 0n) { | |
| throw new Error('latestBlockHeight must be a non-negative bigint'); | |
| } | |
| // Add similar validations for other parameters | |
| this.catchingUp = catchingUp; | |
| this.latestBlockHash = latestBlockHash; | |
| this.latestAppHash = latestAppHash; | |
| this.latestBlockHeight = latestBlockHeight; | |
| this.earliestBlockHash = earliestBlockHash; | |
| this.earliestAppHash = earliestAppHash; | |
| this.earliestBlockHeight = earliestBlockHeight; | |
| this.maxPeerBlockHeight = maxPeerBlockHeight; | |
| this.coreChainLockedHeight = coreChainLockedHeight || null; | |
| } |
| // | ||
| // #[wasm_bindgen(js_name=createFromObject)] | ||
| // pub async fn create_from_object( | ||
| // &self, | ||
| // raw_document_js: JsValue, | ||
| // options: JsValue, | ||
| // ) -> Result<ExtendedDocumentWasm, JsValue> { | ||
| // let mut raw_document = raw_document_js.with_serde_to_platform_value()?; | ||
| // let options: FactoryOptions = if !options.is_undefined() && options.is_object() { | ||
| // let raw_options = options.with_serde_to_json_value()?; | ||
| // serde_json::from_value(raw_options).with_js_error()? | ||
| // } else { | ||
| // Default::default() | ||
| // }; | ||
| // raw_document | ||
| // .replace_at_paths( | ||
| // extended_document::IDENTIFIER_FIELDS, | ||
| // ReplacementType::Identifier, | ||
| // ) | ||
| // .map_err(ProtocolError::ValueError) | ||
| // .with_js_error()?; | ||
| // | ||
| // let mut document = self | ||
| // .0 | ||
| // .create_from_object(raw_document, options) | ||
| // .await | ||
| // .with_js_error()?; | ||
| // let (identifier_paths, binary_paths): (Vec<_>, Vec<_>) = document | ||
| // .get_identifiers_and_binary_paths_owned() | ||
| // .with_js_error()?; | ||
| // // When data contract is available, replace remaining dynamic paths | ||
| // let document_data = document.properties_as_mut(); | ||
| // document_data | ||
| // .replace_at_paths(identifier_paths, ReplacementType::Identifier) | ||
| // .map_err(ProtocolError::ValueError) | ||
| // .with_js_error()?; | ||
| // document_data | ||
| // .replace_at_paths(binary_paths, ReplacementType::BinaryBytes) | ||
| // .map_err(ProtocolError::ValueError) | ||
| // .with_js_error()?; | ||
| // Ok(document.into()) | ||
| // } | ||
| // | ||
| // #[wasm_bindgen(js_name=createFromBuffer)] | ||
| // pub async fn create_from_buffer( | ||
| // &self, | ||
| // buffer: Vec<u8>, | ||
| // options: &JsValue, | ||
| // ) -> Result<ExtendedDocumentWasm, JsValue> { | ||
| // // let options: FactoryOptions = if !options.is_undefined() && options.is_object() { | ||
| // // let raw_options = options.with_serde_to_json_value()?; | ||
| // // serde_json::from_value(raw_options).with_js_error()? | ||
| // // } else { | ||
| // // Default::default() | ||
| // // }; | ||
| // | ||
| // let document = self | ||
| // .0 | ||
| // .create_from_buffer(buffer, options) | ||
| // .await | ||
| // .with_js_error()?; | ||
| // | ||
| // Ok(document.into()) | ||
| // } |
There was a problem hiding this comment.
🛠️ Refactor suggestion
Remove duplicated commented-out code.
The commented-out code sections for createFromObject and createFromBuffer are duplicated. Remove one of the duplicates to maintain code cleanliness.
| const deserialized = dpp.identity.createFromBuffer(identity.toBuffer()); | ||
|
|
||
| expect(result).to.be.an.instanceOf(Identity); | ||
| expect(deserialized).to.be.an.instanceOf(Identity); | ||
|
|
||
| expect(result.toObject()).to.deep.equal(identity.toObject()); | ||
| expect(deserialized.toObject()).to.deep.equal(deserialized.toObject()); |
There was a problem hiding this comment.
🛠️ Refactor suggestion
Code simplification improves readability
The refactoring simplifies the code by removing the try-catch block and directly assigning to a descriptively named variable. However, line 69 has a minor issue - it's comparing deserialized.toObject() to itself rather than to identity.toObject().
-expect(deserialized.toObject()).to.deep.equal(deserialized.toObject());
+expect(deserialized.toObject()).to.deep.equal(identity.toObject());📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| const deserialized = dpp.identity.createFromBuffer(identity.toBuffer()); | |
| expect(result).to.be.an.instanceOf(Identity); | |
| expect(deserialized).to.be.an.instanceOf(Identity); | |
| expect(result.toObject()).to.deep.equal(identity.toObject()); | |
| expect(deserialized.toObject()).to.deep.equal(deserialized.toObject()); | |
| const deserialized = dpp.identity.createFromBuffer(identity.toBuffer()); | |
| expect(deserialized).to.be.an.instanceOf(Identity); | |
| expect(deserialized.toObject()).to.deep.equal(identity.toObject()); |
| let blocksPassed = BigInt(0); | ||
|
|
||
| // Wait for first withdrawal to broadcast | ||
| while (!withdrawalBroadcasted && blocksPassed === 0) { | ||
| while (!withdrawalBroadcasted && blocksPassed === BigInt(0)) { |
There was a problem hiding this comment.
🛠️ Refactor suggestion
Add a timeout to prevent infinite loop.
The while loop could potentially run indefinitely if the conditions are never met.
+ const startTime = Date.now();
+ const TIMEOUT_MS = 30000; // 30 seconds timeout
let blocksPassed = BigInt(0);
- while (!withdrawalBroadcasted && blocksPassed === BigInt(0)) {
+ while (!withdrawalBroadcasted && blocksPassed === BigInt(0) &&
+ Date.now() - startTime < TIMEOUT_MS) {📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| let blocksPassed = BigInt(0); | |
| // Wait for first withdrawal to broadcast | |
| while (!withdrawalBroadcasted && blocksPassed === 0) { | |
| while (!withdrawalBroadcasted && blocksPassed === BigInt(0)) { | |
| const startTime = Date.now(); | |
| const TIMEOUT_MS = 30000; // 30 seconds timeout | |
| let blocksPassed = BigInt(0); | |
| // Wait for first withdrawal to broadcast | |
| while (!withdrawalBroadcasted && blocksPassed === BigInt(0) && Date.now() - startTime < TIMEOUT_MS) { |
| public async bumpIdentityContractNonce( | ||
| identityId: Identifier, | ||
| contractId: Identifier, | ||
| ): Promise<number> { | ||
| const nextIdentityContractNonce = await this | ||
| .getIdentityContractNonce(identityId, contractId) + 1; | ||
| ): Promise<bigint> { | ||
| const identityContractNonce = await this.getIdentityContractNonce(identityId, contractId); | ||
| // @ts-ignore | ||
| const nextIdentityContractNonce = identityContractNonce + 1n; | ||
| this.setIdentityContractNonce(identityId, contractId, nextIdentityContractNonce); | ||
| return nextIdentityContractNonce; | ||
| } |
There was a problem hiding this comment.
Remove @ts-ignore by fixing the type issue.
The method correctly uses bigint arithmetic, but the @ts-ignore comment suggests a type issue that should be addressed rather than ignored.
Let's remove the comment and ensure proper typing:
- // @ts-ignore
- const nextIdentityContractNonce = identityContractNonce + 1n;
+ const nextIdentityContractNonce = identityContractNonce + BigInt(1);📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| public async bumpIdentityContractNonce( | |
| identityId: Identifier, | |
| contractId: Identifier, | |
| ): Promise<number> { | |
| const nextIdentityContractNonce = await this | |
| .getIdentityContractNonce(identityId, contractId) + 1; | |
| ): Promise<bigint> { | |
| const identityContractNonce = await this.getIdentityContractNonce(identityId, contractId); | |
| // @ts-ignore | |
| const nextIdentityContractNonce = identityContractNonce + 1n; | |
| this.setIdentityContractNonce(identityId, contractId, nextIdentityContractNonce); | |
| return nextIdentityContractNonce; | |
| } | |
| public async bumpIdentityContractNonce( | |
| identityId: Identifier, | |
| contractId: Identifier, | |
| ): Promise<bigint> { | |
| const identityContractNonce = await this.getIdentityContractNonce(identityId, contractId); | |
| const nextIdentityContractNonce = identityContractNonce + BigInt(1); | |
| this.setIdentityContractNonce(identityId, contractId, nextIdentityContractNonce); | |
| return nextIdentityContractNonce; | |
| } |
Issue being fixed or feature implemented
What was done?
How Has This Been Tested?
Breaking Changes
Checklist:
For repository code-owners and collaborators only
Summary by CodeRabbit
Below are the high-level release notes for this update:
These improvements strengthen the internal reliability and consistency of the system without affecting the user interface.