-
Notifications
You must be signed in to change notification settings - Fork 44
feat(platform): js sdk #2685
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat(platform): js sdk #2685
Conversation
Important Review skippedAuto reviews are disabled on base/target branches other than the default branch. Please check the settings in the CodeRabbit UI or the You can disable this status message by setting the WalkthroughThis update introduces a new, modular JavaScript/TypeScript SDK for Dash Platform, built atop a Rust-based WASM SDK. It adds comprehensive core modules, advanced context providers (including Bluetooth and web service), wallet adapters, contract and document management, and a robust error system. Extensive documentation, usage examples, tests, and CI/CD workflows are included. The WASM SDK is also enhanced with new features, documentation, build scripts, and configuration improvements for production readiness and optimization. Changes
Sequence Diagram(s)sequenceDiagram
participant App as Application
participant SDK as Dash SDK
participant Provider as Context Provider (WebService/Bluetooth/Priority)
participant WASM as WASM SDK
participant Wallet as Wallet Adapter
App->>SDK: Initialize (with options)
SDK->>Provider: Setup & validate connectivity
SDK->>WASM: Load WASM module (async)
SDK-->>App: Emit 'initialized' event
App->>SDK: Query (e.g., getIdentity)
SDK->>Provider: Fetch platform state / data
Provider->>Provider: (Fallback to next provider if needed)
Provider-->>SDK: Return data
SDK->>WASM: Pass context and call WASM method
WASM-->>SDK: Return result
SDK-->>App: Return result
App->>SDK: Register app / contract
SDK->>SDK: Store app definition
App->>SDK: Broadcast state transition
SDK->>Wallet: (If signing required) Sign transition
SDK->>WASM: Broadcast transition
WASM-->>SDK: Return transition result
SDK-->>App: Return result
App->>SDK: Destroy
SDK->>Provider: Cleanup
SDK->>WASM: Cleanup
SDK-->>App: Cleanup complete
Possibly related PRs
Suggested labels
Poem
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. 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 (
|
@CodeRabbit review |
✅ Actions performedReview triggered.
|
2 similar comments
✅ Actions performedReview triggered.
|
✅ Actions performedReview triggered.
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 49
🔭 Outside diff range comments (1)
packages/wasm-drive-verify/tests/document_tests.rs (1)
17-28
: Test does not actually pass the invalid contract id
_invalid_contract_id
is declared but never used; the call still passescontract_js
created from a valid 32-byte identifier, so the assertion will fail once Drive returnsOk(())
.- let _invalid_contract_id = Uint8Array::from(&[0u8; 20][..]); // Too short + let invalid_contract_id = Uint8Array::from(&[0u8; 20][..]); // Too short … - &contract_js, + &invalid_contract_id,Without this fix the negative-path test is a false positive.
♻️ Duplicate comments (1)
packages/js-dash-sdk/src/modules/contracts/ContractModule.ts (1)
182-186
: Fix: Use skipValidation from options parameterSame issue as in IdentityModule - the
skipValidation
parameter should use the value from options instead of being hardcoded tofalse
.
🧹 Nitpick comments (74)
packages/js-dash-sdk-original/.gitignore (1)
1-3
: Broaden ignore rules for parity with other SDK packagesThis
.gitignore
only excludesbuild
anddist
, while the siblingjs-dash-sdk
package ignores common artefacts such asnode_modules/
, logs, coverage, IDE files, etc. To avoid accidentally committing transient files, consider copying the richer rule-set used elsewhere.+# Dependencies +node_modules/ + +# Build outputs build dist + +# IDE / OS / misc +.DS_Store +.vscode/ +.idea/ +*.logpackages/js-dash-sdk/.gitignore (1)
1-36
: Avoid duplicated ignore logic across packagesThis file duplicates many patterns that already exist at the repo root and/or could be shared via a global
.gitignore
.
Duplications require manual sync and are easy to get out of date.If possible, keep only package-specific entries here and rely on the root ignore for generic patterns, or reference a shared template via Git’s
core.excludesFile
.packages/README.md (1)
20-20
: Clarify “original” vs. new SDK in docsGood to rename the link, but readers may not understand the distinction.
Add a short sentence explaining thatjs-dash-sdk-original
is the legacy monolithic SDK and recommend the new modular SDK when appropriate.packages/js-dash-sdk-original/src/index.ts (1)
1-3
: Prefer standard ESM re-export for TypeScript projects
export = SDK;
uses the older CommonJS compatibility syntax and can cause interop quirks in ESM-aware bundlers.
Unless you deliberately target CommonJS, switch to a default export:-import SDK from './SDK'; - -export = SDK; +export { default } from './SDK';Update
tsconfig.json
("module": "ESNext"
or"NodeNext"
) andpackage.json
("type": "module"
or export maps) accordingly.packages/wasm-drive-verify/tests/document_tests.rs (1)
85-93
: Magic number forcontested_status
obscures intent
0 /* NotContested */
works but future readers won’t know what 0 means. Consider an enum or at least a namedconst
in the test module:const NOT_CONTESTED: u8 = 0; … contested_status = NOT_CONTESTED,Makes the test self-descriptive without affecting compile time.
CLAUDE.md (1)
95-100
: Minor wording nitpick“Interfaces for building applications on Dash Platform” → “on the Dash Platform” reads more naturally.
-interfaces for building applications on Dash Platform. +interfaces for building applications on the Dash Platform.packages/js-dash-sdk/jest.config.js (1)
1-13
: Consider enablingclearMocks
for cleaner testsWhen using Jest with extensive integration tests, stale mocks can leak between tests. Adding:
testEnvironment: 'node', + clearMocks: true,
keeps each test isolated with virtually zero cost.
packages/js-dash-sdk-original/tsconfig.json (2)
3-4
: Consider alignment between target and module settings.Targeting ES2020 with CommonJS modules is unusual. Consider using ES modules for better tree-shaking and modern bundling:
"target": "es2020", - "module": "commonjs", + "module": "es2020",
8-8
: Remove allowUmdGlobalAccess if not needed.
allowUmdGlobalAccess: true
is typically only needed for legacy UMD libraries. If this isn't required for your specific use case, consider removing it for better type safety.packages/js-dash-sdk/tests/sdk.test.ts (2)
37-43
: Add test for duplicate app registration.Consider adding a test case to verify behavior when registering an app with the same name twice. This would ensure consistent behavior:
it('should handle duplicate app registration', () => { const appDef1 = { contractId: 'id1' }; const appDef2 = { contractId: 'id2' }; sdk.registerApp('testapp', appDef1); sdk.registerApp('testapp', appDef2); // Should this overwrite or throw? expect(sdk.getApp('testapp')).toEqual(appDef2); // Or expect error });
11-14
: Add validation test for invalid network configuration.Consider adding a test for invalid network values to ensure proper error handling:
it('should handle invalid network configuration', () => { expect(() => createSDK({ network: 'invalid-network' as any })) .toThrow('Invalid network type'); });packages/js-dash-sdk/docs/quickstart-webservice.md (1)
104-112
: Consider enhancing error handling with more specific error types.The current error handling relies on string matching which can be fragile. Consider checking for specific error types or status codes if available in the SDK.
} catch (error) { - if (error.message.includes('HTTP')) { - console.error('Network error:', error.message); - } else if (error.message.includes('timeout')) { - console.error('Request timed out'); - } else { - console.error('Unknown error:', error); - } + if (error instanceof NetworkError) { + console.error('Network error:', error.message); + } else if (error instanceof TimeoutError) { + console.error('Request timed out'); + } else { + console.error('Unknown error:', error); + } }packages/wasm-sdk/TODO_SUMMARY.md (2)
6-11
: Add language specifications to code blocks for better rendering.The code blocks lack language specifications which affects markdown rendering and syntax highlighting.
-### By Status -``` +### By Status +```text 🟢 Implementable Now: 20 (45%) 🟡 Blocked: 15 (34%) 🔵 Nice to Have: 9 (21%) Total: 44-### By Priority
-+### By Priority +
text
🔴 Critical (User Funds): 5 (withdrawals)
🟠 High (Core Features): 10 (serialization, fetching)
🟡 Medium (New Features): 14 (groups, monitoring)
🟢 Low (Improvements): 15 (validation, optimization)-### By Module Area -``` +### By Module Area +```text 📁 Group Operations: 11 █████████████████████ 📁 State Transitions: 8 ███████████████ 📁 Data Operations: 7 █████████████ 📁 User Funds: 5 █████████ 📁 Monitoring: 4 ███████ 📁 Validation: 4 ███████ 📁 Serialization: 3 █████ 📁 Other: 2 ███
Also applies to: 14-19, 22-31 --- `71-71`: **Fix grammar: Use "to-dos" instead of "TODOs" in prose.** The plural form of "to-do" should be hyphenated as "to-dos" in prose contexts. ```diff -#### Platform Proto Required (7) -- Response parsing (2) - Need protobuf definitions -- Group state transitions (5) - Need group proto types +#### Platform Proto Required (7) +- Response parsing (2) - Need protobuf definitions +- Group state transitions (5) - Need group protobuf types -These can be implemented in < 1 day each: -1. Unproved fetching (2 TODOs) - Just remove proof param -2. Batch operations (2 TODOs) - Use Promise.all -3. Basic monitoring (2 TODOs) - Use setInterval +These can be implemented in < 1 day each: +1. Unproved fetching (2 to-dos) - Just remove proof param +2. Batch operations (2 to-dos) - Use Promise.all +3. Basic monitoring (2 to-dos) - Use setInterval -1. [ ] Implement deserializers (3 TODOs) -2. [ ] Add unproved fetching (2 TODOs) -3. [ ] Create withdrawal module (5 TODOs) +1. [ ] Implement deserializers (3 to-dos) +2. [ ] Add unproved fetching (2 to-dos) +3. [ ] Create withdrawal module (5 to-dos) -1. [ ] Implement group actions (6 TODOs) -2. [ ] Add batch operations (2 TODOs) -3. [ ] Basic monitoring (2 TODOs) +1. [ ] Implement group actions (6 to-dos) +2. [ ] Add batch operations (2 to-dos) +3. [ ] Basic monitoring (2 to-dos) -- **Most TODOs are features, not bugs** - SDK is stable but incomplete +- **Most to-dos are features, not bugs** - SDK is stable but incomplete -- [ ] Only platform-blocked TODOs remain +- [ ] Only platform-blocked to-dos remain
Also applies to: 85-87, 110-112, 115-117, 128-128, 137-137
packages/js-dash-sdk/examples/modular-usage.ts (1)
42-44
: Consider more specific error handling in production examples.While the generic error handling is fine for an example, consider showing more specific error handling patterns that developers might use in production.
} catch (error) { - console.error('Error:', error); + if (error instanceof NetworkError) { + console.error('Network error:', error.message); + } else if (error instanceof ValidationError) { + console.error('Validation error:', error.message); + } else { + console.error('Unexpected error:', error); + } }packages/js-dash-sdk/src/core/WasmLoader.ts (1)
14-24
: Consider resetting initPromise on failure for retry capability.Currently, if WASM loading fails, subsequent calls to
loadWasmSdk()
will continue to await the failed promise rather than attempting to reload.initPromise = (async () => { try { // Dynamic import to enable code splitting const wasm = await import('../../wasm/wasm_sdk'); await wasm.default(); wasmSdkModule = wasm; } catch (error) { + initPromise = null; // Reset to allow retry console.error('Failed to load WASM SDK:', error); throw new Error('Failed to initialize WASM SDK. Please ensure WASM is supported in your environment.'); } })();
packages/js-dash-sdk-original/package.json (1)
56-111
: Consider updating TypeScript and development tool versions.The devDependencies include several packages that may be outdated:
typescript": "^3.9.5"
- Very old TypeScript version (current is 5.x)@types/node": "^14.6.0"
- Old Node.js typeseslint": "^8.53.0"
- Could use latest ESLint 9.xmocha": "^11.1.0"
- Recent version, goodUpgrading TypeScript would provide better type checking, performance, and modern language features.
Consider upgrading to modern versions:
- "typescript": "^3.9.5", + "typescript": "^5.6.0", - "@types/node": "^14.6.0", + "@types/node": "^20.0.0", - "eslint": "^8.53.0", + "eslint": "^9.0.0",packages/js-dash-sdk-original/README.md (3)
42-44
: Add language specification to code fence.The CDN example should specify the language for better syntax highlighting and clarity.
-``` +```html <script src="https://unpkg.com/dash"></script>--- `31-31`: **Minor: Use official Node.js spelling.** Following the static analysis suggestion for consistency with official documentation. ```diff -Having [NodeJS](https://nodejs.org/) installed, just type : `npm install dash` in your terminal. +Having [Node.js](https://nodejs.org/) installed, just type : `npm install dash` in your terminal.
133-133
: Grammar correction: Use "fewer" for countable nouns.-Some features might be more extensive in those libs, as Dash SDK only wraps around them to provide a single interface that is easy to use (and thus has less features). +Some features might be more extensive in those libs, as Dash SDK only wraps around them to provide a single interface that is easy to use (and thus has fewer features).packages/wasm-sdk/build-optimized.sh (2)
24-30
: Improve cross-platform tool installation guidance.The installation instructions are limited and don't cover all platforms. Consider adding more comprehensive guidance.
if ! command -v wasm-opt &> /dev/null; then echo "wasm-opt not found. Please install binaryen:" echo " brew install binaryen # macOS" echo " apt-get install binaryen # Ubuntu/Debian" + echo " pacman -S binaryen # Arch Linux" + echo " dnf install binaryen # Fedora" + echo " Or download from: https://github.com/WebAssembly/binaryen/releases" exit 1 fi
48-50
: Document the commented wasm-snip usage.The commented wasm-snip step should include usage guidance since it can significantly reduce bundle size.
-# Optional: Use wasm-snip to remove unused functions -# wasm-snip pkg/wasm_sdk_bg.wasm -o pkg/wasm_sdk_bg.wasm +# Optional: Use wasm-snip to remove unused functions (requires manual function identification) +# Install: cargo install wasm-snip +# Usage: wasm-snip pkg/wasm_sdk_bg.wasm --snip-rust-panicking-code -o pkg/wasm_sdk_bg.wasmpackages/js-dash-sdk/tests/providers/WebServiceProvider.test.ts (1)
257-272
: Consider making timeout test more deterministic.The timeout test uses a promise that never resolves and a 100ms timeout, which could be flaky in slower test environments.
Consider using a more controlled timeout test:
it('should timeout long requests', async () => { - // Mock fetch that never resolves - (global.fetch as jest.Mock).mockImplementationOnce(() => - new Promise(() => {}) // Never resolves - ); + // Mock fetch that resolves after timeout period + (global.fetch as jest.Mock).mockImplementationOnce(() => + new Promise(resolve => setTimeout(resolve, 200)) // Resolves after 200ms + ); const provider = new WebServiceProvider({ timeout: 100 // 100ms timeout }); - // This should timeout await expect(provider.getLatestPlatformBlockHeight()) - .rejects.toThrow(); + .rejects.toThrow(/timeout/i); });packages/wasm-sdk/docs/TROUBLESHOOTING.md (1)
23-34
: Code block is labelled as JSON but contains comments – switch tojs
or remove comments.Using
json
fencing with line comments breaks syntax highlighting and automated lint checks that parse code blocks. Either:-```json +```jsor delete the
// webpack.config.js
comment.packages/wasm-sdk/SECURITY.md (1)
156-167
: Comma-separated HTTP header list will be parsed as one header – show each on its own line or prefix with\n
.Some readers may copy/paste the block verbatim. Split for correctness:
-Content-Security-Policy: default-src 'self'; script-src 'self' 'wasm-unsafe-eval'; connect-src 'self' https://*.dash.org; -X-Content-Type-Options: nosniff +# Content-Security-Policy: … +# X-Content-Type-Options: nosniffpackages/js-dash-sdk-original/.eslintrc.js (1)
1-2
: Typos in header comments – fix for professionalism and grepability.-// A set of rules to easen misuse in the existing codebase -// We should fix these warnigns when possible +// Helper rules to reduce misuse in the existing codebase +// Fix these warnings when possiblepackages/wasm-sdk/.gitlab-ci.yml (1)
123-123
: Missing trailing newline.Some tools flag this; append a LF at EOF.
packages/wasm-sdk/PRODUCTION_CHECKLIST.md (1)
126-131
: Re-evaluate security header recommendations
script-src 'self' 'wasm-unsafe-eval'
– thewasm-unsafe-eval
keyword is still experimental and unsupported in several major browsers.X-XSS-Protection
is obsolete and ignored by modern Chromium-based and Firefox browsers.
Consider documenting modern CSP alternatives and dropping stale headers to avoid a false sense of security.packages/wasm-sdk/Makefile (2)
3-4
: Missing canonicalall
phony targetMany CI systems expect
make
(without args) to succeed. Define a lightweightall
target (aliasingbuild
) and add it to.PHONY
to satisfy thecheckmake
warning and improve DX..PHONY: all help install build build-dev build-release test test-unit test-wasm lint fmt clean docs serve + +all: build
91-93
: Avoid serving the entire project root
python3 -m http.server --directory .
exposes the whole repo (including.git
, credentials, etc.) if run on a public network. Limit the scope:- @python3 -m http.server 8080 --directory . + @python3 -m http.server 8080 --directory ./examplespackages/wasm-sdk/docs/MIGRATION_GUIDE.md (1)
320-330
: Explicit WASM initialisation step is easy to missConsider adding a one-liner emphasising that
init()
must be awaited before any import side-effects (tree-shaken builds sometimes drop it). A bold note here would save newcomers hours.packages/js-dash-sdk/src/modules/names/types.ts (1)
1-10
: Make domain name objects immutable & refine naming
- Prefix fields with
readonly
to prevent accidental mutation of cached objects.contractId
→dataContractId
for clarity and consistency with DPP terminology.-export interface DPNSName { - label: string; - normalizedLabel: string; - normalizedParentDomainName: string; - preorderSalt: Uint8Array; - records: DPNSRecord; - subdomainRules?: SubdomainRules; - ownerId: string; - contractId: string; +export interface DPNSName { + readonly label: string; + readonly normalizedLabel: string; + readonly normalizedParentDomainName: string; + readonly preorderSalt: Uint8Array; + readonly records: DPNSRecord; + readonly subdomainRules?: SubdomainRules; + readonly ownerId: string; + readonly dataContractId: string; }packages/js-dash-sdk/examples/read-only-usage.ts (1)
137-137
: Use optional chaining for cleaner code.The condition can be simplified using optional chaining.
- if (provider.getCapabilities && provider.getCapabilities().includes('quorum_keys')) { + if (provider.getCapabilities?.().includes('quorum_keys')) {packages/js-dash-sdk/src/core/StateTransitionBroadcaster.ts (1)
99-99
: Use optional chaining for cleaner code.The condition can be simplified using optional chaining.
- if (result && result.metadata) { + if (result?.metadata) {packages/js-dash-sdk/src/modules/contracts/types.ts (3)
1-7
: Consider makingschema
property more specific.The
schema
property is typed asobject
, which is quite generic. Consider using a more specific type or interface for better type safety.export interface DataContract { id: string; ownerId: string; - schema: object; + schema: Record<string, any> | JSONSchema7; version: number; documentSchemas: Record<string, DocumentSchema>; }
17-23
: Index properties structure could be improved.The current
properties
array structure usingArray<{ [key: string]: 'asc' | 'desc' }>
might be confusing. Consider a more explicit structure.export interface Index { name: string; - properties: Array<{ - [key: string]: 'asc' | 'desc'; - }>; + properties: Array<{ + field: string; + order: 'asc' | 'desc'; + }>; unique?: boolean; }
36-43
: Add validation for operation type and enhance type safety.The
operation
field uses string literals, which is good. Consider adding JSDoc comments to clarify the purpose of each field, especiallychanges
array.packages/js-dash-sdk/src/bluetooth/setup.ts (1)
35-39
: Consider exposing timeout configuration more prominently.The 30-second default timeout might be too long for some use cases. Consider making this more configurable or documenting the rationale for this default.
packages/js-dash-sdk/src/core/ContextProvider.ts (2)
4-5
: Consider making cache configuration more flexible.The hardcoded 5-second cache duration and Map-based cache might not be suitable for all use cases. Consider making these configurable.
export abstract class AbstractContextProvider implements ContextProvider { - protected cacheDuration: number = 5000; // 5 seconds default cache - protected cache: Map<string, { value: any; timestamp: number }> = new Map(); + protected cacheDuration: number; + protected cache: Map<string, { value: any; timestamp: number }>; + + constructor(cacheDuration: number = 5000) { + this.cacheDuration = cacheDuration; + this.cache = new Map(); + }
7-13
: Cache implementation is sound but could be enhanced.The cache implementation correctly checks timestamps and handles cache misses. Consider adding cache size limits to prevent memory leaks in long-running applications.
packages/js-dash-sdk/examples/bluetooth-wallet.ts (1)
141-141
: Consider using a more explicit approach to keep the process running.While
await new Promise(() => {})
works, it creates a promise that never resolves. For better readability in examples, consider usingsetInterval
with a heartbeat or a more descriptive waiting mechanism.- // Keep the process running - await new Promise(() => {}); + // Keep the process running with a heartbeat + const heartbeat = setInterval(() => { + // Heartbeat to keep process alive + }, 60000); // Every minute + + // Wait for process termination + await new Promise((resolve) => { + process.on('SIGINT', () => { + clearInterval(heartbeat); + resolve(undefined); + }); + });packages/wasm-sdk/TODO_ANALYSIS.md (1)
59-59
: Add comma before 'but' for better grammar.- - Would improve security but basic validation exists + - Would improve security, but basic validation existspackages/wasm-sdk/examples/bls-signatures-example.js (2)
142-144
: Improve mock ECDSA public key generation.The mock ECDSA public key generation is overly simplistic. For a more realistic example, consider generating a proper compressed public key or clearly indicating this is mock data.
// Fill in mock ECDSA key - crypto.getRandomValues(publicKeys[0].data); - publicKeys[0].data[0] = 0x02; // Valid compressed key prefix + // Generate mock compressed ECDSA public key (demo purposes only) + crypto.getRandomValues(publicKeys[0].data.subarray(1)); + publicKeys[0].data[0] = 0x02; // Valid compressed key prefix
203-217
: Add error context for better debugging.The error handling in the main execution block could provide more context about which example failed, making debugging easier.
(async () => { try { await blsKeyExample(); await blsSignatureExample(); await wasmSignerBlsExample(); await identityWithBlsExample(); await blsThresholdExample(); await blsPerformanceTest(); console.log('\n✅ All BLS examples completed successfully!'); } catch (error) { - console.error('❌ Error in BLS examples:', error); + console.error('❌ Error in BLS examples:', error.message); + console.error('Stack trace:', error.stack); } })();packages/wasm-sdk/.github/workflows/ci.yml (3)
1-226
: Fix YAML formatting issues throughout the file.The file has trailing spaces on most lines and is missing a newline at the end, which violates YAML formatting standards.
Apply this fix to clean up the formatting:
Remove trailing spaces from all lines (too many to show individually) and add a newline at the end: - name: Upload coverage uses: codecov/codecov-action@v3 with: files: ./cobertura.xml - fail_ci_if_error: true + fail_ci_if_error: true +You can fix this automatically with:
sed -i 's/[[:space:]]*$//' packages/wasm-sdk/.github/workflows/ci.yml echo >> packages/wasm-sdk/.github/workflows/ci.yml
155-159
: Consider using a package manager for wasm-opt installation.The manual download and installation of wasm-opt could be simplified and made more maintainable using a package manager or GitHub Action.
- - name: Install wasm-opt - run: | - wget https://github.com/WebAssembly/binaryen/releases/download/version_116/binaryen-version_116-x86_64-linux.tar.gz - tar -xzf binaryen-version_116-x86_64-linux.tar.gz - sudo cp binaryen-version_116/bin/wasm-opt /usr/local/bin/ + - name: Install wasm-opt + run: | + # Use package manager for better maintenance + sudo apt-get update + sudo apt-get install -y binaryenAlternatively, consider using a dedicated GitHub Action like
jetli/wasm-opt-action
.
176-178
: Make bundle size threshold configurable.The hardcoded 2MB threshold should be configurable or at least documented why this specific size was chosen.
+ - name: Set bundle size limit + run: echo "WASM_SIZE_LIMIT=2097152" >> $GITHUB_ENV + - name: Check bundle size run: | ls -lh pkg/*.wasm size=$(stat -c%s pkg/wasm_sdk_bg_optimized.wasm) echo "WASM size: $size bytes" - if [ $size -gt 2097152 ]; then + if [ $size -gt $WASM_SIZE_LIMIT ]; then - echo "Warning: WASM file is larger than 2MB" + echo "Warning: WASM file is larger than ${WASM_SIZE_LIMIT} bytes (2MB)" fipackages/js-dash-sdk/README.md (1)
7-7
: Consider removing redundant hyphen for better readability.The hyphen in "WebAssembly-based" is unnecessary according to style guidelines.
-- 🚀 **WebAssembly-based** - Built on top of the Rust implementation for maximum performance +- 🚀 **WebAssembly based** - Built on top of the Rust implementation for maximum performancepackages/js-dash-sdk/src/utils/errors.ts (1)
29-34
: Consider making error code required for StateTransitionError.Since state transition errors typically have specific error codes from the platform, consider making the
code
parameter required rather than optional to ensure proper error reporting.export class StateTransitionError extends DashSDKError { - constructor(message: string, public code?: number) { + constructor(message: string, public code: number) { super(message); this.name = 'StateTransitionError'; } }Alternatively, provide a factory method for cases where the code is unknown:
export class StateTransitionError extends DashSDKError { constructor(message: string, public code?: number) { super(message); this.name = 'StateTransitionError'; } + + static withUnknownCode(message: string): StateTransitionError { + return new StateTransitionError(message, undefined); + } }packages/js-dash-sdk/src/providers/WebServiceProvider.ts (1)
224-230
: Consider logging when returning stale cached dataWhen an error occurs and stale cached data is returned, the caller has no way to know the data might be outdated. Consider adding a warning log or including metadata about cache freshness.
} catch (error) { // Return cached data if available if (this.quorumCache.size > 0) { + console.warn('Failed to fetch fresh quorum keys, returning cached data', error); return this.quorumCache; } throw error; }
packages/wasm-sdk/.github/workflows/release.yml (1)
51-54
: Consider using a more maintainable approach for wasm-opt installationThe hardcoded binaryen version may become outdated. Consider using an environment variable or installing via package manager.
- wget https://github.com/WebAssembly/binaryen/releases/download/version_116/binaryen-version_116-x86_64-linux.tar.gz - tar -xzf binaryen-version_116-x86_64-linux.tar.gz - sudo cp binaryen-version_116/bin/wasm-opt /usr/local/bin/ + sudo apt-get update && sudo apt-get install -y binaryenOr use a version variable:
env: BINARYEN_VERSION: version_116packages/js-dash-sdk/src/modules/documents/DocumentModule.ts (2)
217-220
: Implement wallet signing for state transitionsThe TODO indicates missing wallet integration for signing transitions, which is critical for document operations.
Would you like me to implement the wallet signing logic or create an issue to track this requirement? The implementation would involve:
- Checking if a wallet is configured
- Getting the appropriate key for signing
- Signing the state transition
- Handling signing errors
34-34
: Consider refactoring to avoid circular dependenciesUsing dynamic imports to resolve circular dependencies can impact performance and bundle optimization. Consider extracting shared interfaces or using dependency injection.
Potential solutions:
- Extract shared types/interfaces to a separate module
- Use dependency injection pattern instead of direct imports
- Restructure modules to have clearer boundaries
This would improve bundle size and loading performance.
Also applies to: 128-128
packages/js-dash-sdk/IMPLEMENTATION_SUMMARY.md (1)
188-188
: Add missing comma for clarity-The new js-dash-sdk provides a solid foundation for building Dash Platform applications with modern JavaScript/TypeScript tooling while maintaining compatibility and feature parity with the original implementation. +The new js-dash-sdk provides a solid foundation for building Dash Platform applications with modern JavaScript/TypeScript tooling, while maintaining compatibility and feature parity with the original implementation.packages/js-dash-sdk/src/modules/identities/IdentityModule.ts (1)
23-52
: Missing implementation for identity registrationThe method is not implemented and requires wallet integration. This is a core feature of the identity module that users will expect to work.
Would you like me to help implement the identity registration logic once the wallet integration is available, or create a GitHub issue to track this missing feature?
packages/js-dash-sdk/src/bluetooth/BluetoothConnection.ts (3)
149-149
: Use optional chaining for cleaner code- if (this.server && this.server.connected) { + if (this.server?.connected) {
229-233
: Consider making chunk delay configurableThe 50ms delay between chunks is hardcoded. Different devices or network conditions might benefit from different delays.
Add a configurable delay:
+ const chunkDelay = this.options.chunkDelay || 50; // Send each chunk for (const chunk of chunks) { await this.commandChar.writeValueWithResponse(chunk); // Small delay between chunks - await new Promise(resolve => setTimeout(resolve, 50)); + await new Promise(resolve => setTimeout(resolve, chunkDelay)); }
296-298
: Emit error event for consistencyStatus parsing errors are only logged, not emitted. For consistency with other error handling in the class, emit the error.
} catch (error) { console.error('Failed to parse status update:', error); + this.emit('error', new Error(`Failed to parse status update: ${error.message}`)); }
packages/js-dash-sdk/examples/priority-providers.ts (1)
104-107
: Clarify placeholder URL in exampleThe URL
https://backup-quorum.example.com
should be clearly marked as a placeholder to avoid confusion.provider: new WebServiceProvider({ network: 'testnet', - url: 'https://backup-quorum.example.com' // Backup service + url: 'https://backup-quorum.example.com' // PLACEHOLDER - Replace with your backup service URL }),packages/wasm-sdk/examples/contract-cache-example.js (1)
321-335
: Consider demonstrating actual fetch_data_contract usageWhile the simulation is helpful for understanding the caching pattern, consider adding a commented example showing how to use the actual
fetch_data_contract
function that was imported.// Simulate network fetch // In real usage, this would call fetch_data_contract + // Example: + // const contractBytes = await fetch_data_contract(sdk, contractId); const contract = {packages/js-dash-sdk/src/providers/ProviderFactory.ts (1)
53-228
: Consider using a namespace or plain functions instead of a static-only classSince this class contains only static members, consider refactoring to use a namespace or plain functions for a more idiomatic approach.
Example refactor to namespace:
export namespace ProviderFactory { export async function create(options: ProviderFactoryOptions = {}): Promise<ContextProvider> { // ... implementation } export async function createWithBluetooth(options: ProviderFactoryOptions = {}): Promise<ContextProvider> { // ... implementation } // ... other functions }Or as plain exported functions:
export async function createProvider(options: ProviderFactoryOptions = {}): Promise<ContextProvider> { // ... implementation } export async function createProviderWithBluetooth(options: ProviderFactoryOptions = {}): Promise<ContextProvider> { // ... implementation }packages/wasm-sdk/examples/group-actions-example.js (1)
326-348
: Clarify expected behavior in SDK integration exampleThe try-catch block with a generic message might confuse users. Consider making it clearer that this is demonstrating the API structure.
try { + // Note: These operations require an active Platform connection + // This example demonstrates the API structure // Fetch group information const group = await fetchGroup(sdk, 'GWRSAVFMjXx8HpQFaNJMqBV7MBgMK4br5UESsB4S3Qdq');Or consider mocking the responses to show expected data structure:
- } catch (error) { - console.log('SDK operations would work with actual Platform connection'); + } catch (error) { + console.log('SDK operations require Platform connection. Expected response structure:'); + console.log('Group:', { id: 'string', name: 'string', type: 'string', memberCount: 0, threshold: 0, active: true }); + console.log('Members:', [{ id: 'string', power: 100, role: 'member' }]); + console.log('Proposals:', [{ id: 'string', title: 'string', status: 'active' }]); }packages/js-dash-sdk/src/bluetooth/MOBILE_INTERFACE.md (1)
341-388
: Enhance React Native example with security implementationThe example should demonstrate the security requirements mentioned earlier in the document, including encryption and authentication.
Consider adding:
class DashBluetoothService { constructor() { this.security = new BluetoothSecurity(); this.isAuthenticated = false; } async handleCommand(data, offset, withoutResponse, callback) { try { // Decrypt if session is established let messageData = data; if (this.security.hasSession()) { messageData = await this.security.decrypt(data); } const message = JSON.parse(messageData.toString('utf8')); // Check authentication for sensitive operations if (this.requiresAuth(message.type) && !this.isAuthenticated) { throw new Error('AUTH_REQUIRED'); } const response = await this.processMessage(message); await this.sendResponse(response); callback(BleManager.RESULT_SUCCESS); } catch (error) { await this.sendError(error); callback(BleManager.RESULT_UNLIKELY_ERROR); } } }packages/js-dash-sdk/src/core/CentralizedProvider.ts (1)
9-16
: Unused field in PlatformStatus interfaceThe
epoch
field is defined in thePlatformStatus
interface but is never cached or used in any of the methods. Consider either utilizing this field or removing it if not needed.packages/js-dash-sdk/src/providers/PriorityContextProvider.ts (1)
218-234
: Consider adding timeout for provider availability checksThe
getActiveProvider
method usesgetLatestPlatformBlockHeight
as a health check for providers without anisAvailable
method. This could hang if a provider is unresponsive.Consider wrapping the health check in a timeout:
// Try a simple operation with timeout to check availability const timeoutPromise = new Promise((_, reject) => setTimeout(() => reject(new Error('Timeout')), 5000) ); await Promise.race([ provider.provider.getLatestPlatformBlockHeight(), timeoutPromise ]);packages/wasm-sdk/Cargo.toml (1)
43-64
: Document WASM compatibility issuesGood practice documenting why certain dependencies are commented out. Consider adding a dedicated WASM compatibility section to the README or documentation to help future developers understand these constraints.
packages/js-dash-sdk/src/bluetooth/BluetoothWallet.ts (1)
247-268
: Consider using a dedicated message type for data signingThe
signData
method reusesMessageType.SIGN_STATE_TRANSITION
with a special identifier "data-signing". This could be confusing and might cause issues if the mobile app doesn't handle this special case properly.Consider adding a dedicated
MessageType.SIGN_DATA
to make the intent clearer and avoid potential conflicts:async signData( data: Uint8Array, accountIndex: number = 0 ): Promise<Uint8Array> { const request = BluetoothProtocol.createRequest( - MessageType.SIGN_STATE_TRANSITION, // Reuse signing endpoint + MessageType.SIGN_DATA, // Use dedicated message type { - stateTransition: Buffer.from(data).toString('base64'), - identityId: 'data-signing', // Special identifier for raw data signing + data: Buffer.from(data).toString('base64'), - keyIndex: accountIndex, + accountIndex, keyType: 'ECDSA' } );packages/js-dash-sdk/docs/api/providers.md (1)
36-50
: Improve method description variety.Several consecutive method descriptions start with "Gets". Consider varying the descriptions for better readability.
-#### `getLatestPlatformBlockHeight(): Promise<number>` -Gets the latest platform block height. +#### `getLatestPlatformBlockHeight(): Promise<number>` +Returns the latest platform block height. -#### `getLatestPlatformBlockTime(): Promise<number>` -Gets the latest platform block timestamp. +#### `getLatestPlatformBlockTime(): Promise<number>` +Retrieves the latest platform block timestamp. -#### `getLatestPlatformCoreChainLockedHeight(): Promise<number>` -Gets the core chain locked height. +#### `getLatestPlatformCoreChainLockedHeight(): Promise<number>` +Fetches the core chain locked height. -#### `getLatestPlatformVersion(): Promise<string>` -Gets the platform version. +#### `getLatestPlatformVersion(): Promise<string>` +Obtains the current platform version.packages/wasm-sdk/API_REFERENCE.md (4)
1-4
: Add basic doc metadata (title, version, date).A header with version/date helps readers quickly determine which SDK build this reference applies to and avoids future ambiguity when breaking changes are introduced.
# Dash Platform WASM SDK API Reference + +<!-- +Version: 0.1.0-alpha • Generated: 2025-06-?? • Applies to: @dash/wasm-sdk >=0.1.0 +-->
28-35
: Usetypescript
for typed import snippet to avoid losing types in copy-paste.The sample already imports a typed API; marking the code block as
typescript
instead ofjavascript
keeps type hints and prevents editors from flagging unknown types.-```javascript -import { start } from 'dash-wasm-sdk'; +```typescript +import { start } from 'dash-wasm-sdk'; await start();
561-580
: Minor punctuation fix in prose beforeWasmCoreClient
.Static-analysis flagged a missing comma which slightly breaks the sentence flow.
-Core chain DAPI client. +Core-chain DAPI client, providing low-level access to Core RPC endpoints.
804-818
: Reduce repetitive “Verify … proof” sentence starts.Three consecutive bullet descriptions begin with “Verify”. Re-phrasing one avoids mechanical repetition without altering meaning.
-Verify documents proof. +Performs proof verification for documents.packages/wasm-sdk/docs/API_DOCUMENTATION.md (2)
24-35
: Exposenetwork
as a readonly property, not a zero-arg method
network(): string;
reads like a function call but conceptually represents immutable state.
Idiomatic TS docs (and generated d.ts) usually expose this as:readonly network: string;This small change improves clarity and avoids confusion with the constructor parameter of the same name.
338-354
: Clarify transport layer (gRPC vs HTTP) inrawRequest
rawRequest(path, payload)
implies an HTTP-style interaction, while DAPI currently exposes gRPC methods.
Add one sentence indicating the underlying transport (gRPC
,https
, or auto-detect) so integrators pick the correct endpoint format.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (107)
.gitignore
(1 hunks)CLAUDE.md
(2 hunks)packages/README.md
(1 hunks)packages/js-dash-sdk-original/.eslintrc.js
(1 hunks)packages/js-dash-sdk-original/.gitignore
(1 hunks)packages/js-dash-sdk-original/README.md
(1 hunks)packages/js-dash-sdk-original/package.json
(1 hunks)packages/js-dash-sdk-original/src/index.ts
(1 hunks)packages/js-dash-sdk-original/tsconfig.json
(1 hunks)packages/js-dash-sdk/.eslintrc.js
(1 hunks)packages/js-dash-sdk/.gitignore
(1 hunks)packages/js-dash-sdk/BLUETOOTH_IMPLEMENTATION_SUMMARY.md
(1 hunks)packages/js-dash-sdk/IMPLEMENTATION_SUMMARY.md
(1 hunks)packages/js-dash-sdk/README.md
(1 hunks)packages/js-dash-sdk/docs/api/providers.md
(1 hunks)packages/js-dash-sdk/docs/providers.md
(1 hunks)packages/js-dash-sdk/docs/quickstart-webservice.md
(1 hunks)packages/js-dash-sdk/examples/basic-usage.ts
(1 hunks)packages/js-dash-sdk/examples/bluetooth-secure-pairing.ts
(1 hunks)packages/js-dash-sdk/examples/bluetooth-wallet.ts
(1 hunks)packages/js-dash-sdk/examples/modular-usage.ts
(1 hunks)packages/js-dash-sdk/examples/priority-providers.ts
(1 hunks)packages/js-dash-sdk/examples/read-only-usage.ts
(1 hunks)packages/js-dash-sdk/examples/read-only-website.html
(1 hunks)packages/js-dash-sdk/examples/webservice-quorum.ts
(1 hunks)packages/js-dash-sdk/jest.config.js
(1 hunks)packages/js-dash-sdk/package.json
(1 hunks)packages/js-dash-sdk/rollup.config.js
(1 hunks)packages/js-dash-sdk/scripts/build-wasm.sh
(1 hunks)packages/js-dash-sdk/src/SDK.ts
(1 hunks)packages/js-dash-sdk/src/bluetooth/BluetoothConnection.ts
(1 hunks)packages/js-dash-sdk/src/bluetooth/BluetoothProvider.ts
(1 hunks)packages/js-dash-sdk/src/bluetooth/BluetoothWallet.ts
(1 hunks)packages/js-dash-sdk/src/bluetooth/MOBILE_INTERFACE.md
(1 hunks)packages/js-dash-sdk/src/bluetooth/README.md
(1 hunks)packages/js-dash-sdk/src/bluetooth/index.ts
(1 hunks)packages/js-dash-sdk/src/bluetooth/protocol.ts
(1 hunks)packages/js-dash-sdk/src/bluetooth/security/BluetoothSecurity.ts
(1 hunks)packages/js-dash-sdk/src/bluetooth/setup.ts
(1 hunks)packages/js-dash-sdk/src/bluetooth/types.ts
(1 hunks)packages/js-dash-sdk/src/core/CentralizedProvider.ts
(1 hunks)packages/js-dash-sdk/src/core/ContextProvider.ts
(1 hunks)packages/js-dash-sdk/src/core/StateTransitionBroadcaster.ts
(1 hunks)packages/js-dash-sdk/src/core/WasmLoader.ts
(1 hunks)packages/js-dash-sdk/src/core/index.ts
(1 hunks)packages/js-dash-sdk/src/core/types.ts
(1 hunks)packages/js-dash-sdk/src/index.ts
(1 hunks)packages/js-dash-sdk/src/modules/contracts/ContractModule.ts
(1 hunks)packages/js-dash-sdk/src/modules/contracts/index.ts
(1 hunks)packages/js-dash-sdk/src/modules/contracts/types.ts
(1 hunks)packages/js-dash-sdk/src/modules/documents/DocumentModule.ts
(1 hunks)packages/js-dash-sdk/src/modules/documents/index.ts
(1 hunks)packages/js-dash-sdk/src/modules/documents/types.ts
(1 hunks)packages/js-dash-sdk/src/modules/identities/IdentityModule.ts
(1 hunks)packages/js-dash-sdk/src/modules/identities/index.ts
(1 hunks)packages/js-dash-sdk/src/modules/identities/types.ts
(1 hunks)packages/js-dash-sdk/src/modules/names/NamesModule.ts
(1 hunks)packages/js-dash-sdk/src/modules/names/index.ts
(1 hunks)packages/js-dash-sdk/src/modules/names/types.ts
(1 hunks)packages/js-dash-sdk/src/modules/wallet/types.ts
(1 hunks)packages/js-dash-sdk/src/providers/PriorityContextProvider.ts
(1 hunks)packages/js-dash-sdk/src/providers/ProviderFactory.ts
(1 hunks)packages/js-dash-sdk/src/providers/WebServiceProvider.ts
(1 hunks)packages/js-dash-sdk/src/providers/index.ts
(1 hunks)packages/js-dash-sdk/src/providers/types.ts
(1 hunks)packages/js-dash-sdk/src/utils/errors.ts
(1 hunks)packages/js-dash-sdk/src/utils/index.ts
(1 hunks)packages/js-dash-sdk/tests/bluetooth/protocol.test.ts
(1 hunks)packages/js-dash-sdk/tests/bluetooth/security.test.ts
(1 hunks)packages/js-dash-sdk/tests/providers/PriorityContextProvider.test.ts
(1 hunks)packages/js-dash-sdk/tests/providers/WebServiceProvider.test.ts
(1 hunks)packages/js-dash-sdk/tests/sdk.test.ts
(1 hunks)packages/js-dash-sdk/tsconfig.json
(1 hunks)packages/wasm-drive-verify/src/lib.rs
(1 hunks)packages/wasm-drive-verify/src/native.rs
(1 hunks)packages/wasm-drive-verify/src/utils/getters.rs
(0 hunks)packages/wasm-drive-verify/tests/contract_tests.rs
(3 hunks)packages/wasm-drive-verify/tests/document_tests.rs
(5 hunks)packages/wasm-drive-verify/tests/fuzz_tests.rs
(2 hunks)packages/wasm-drive-verify/tests/identity_tests.rs
(2 hunks)packages/wasm-drive-verify/tests/token_tests.rs
(2 hunks)packages/wasm-sdk/.github/workflows/ci.yml
(1 hunks)packages/wasm-sdk/.github/workflows/release.yml
(1 hunks)packages/wasm-sdk/.gitignore
(1 hunks)packages/wasm-sdk/.gitlab-ci.yml
(1 hunks)packages/wasm-sdk/API_REFERENCE.md
(1 hunks)packages/wasm-sdk/Cargo.deny.toml
(1 hunks)packages/wasm-sdk/Cargo.toml
(3 hunks)packages/wasm-sdk/IMPLEMENTATION_SUMMARY.md
(1 hunks)packages/wasm-sdk/Makefile
(1 hunks)packages/wasm-sdk/OPTIMIZATION_GUIDE.md
(1 hunks)packages/wasm-sdk/PRODUCTION_CHECKLIST.md
(1 hunks)packages/wasm-sdk/PROOF_VERIFICATION_STATUS.md
(1 hunks)packages/wasm-sdk/README.md
(1 hunks)packages/wasm-sdk/SECURITY.md
(1 hunks)packages/wasm-sdk/TODO_ANALYSIS.md
(1 hunks)packages/wasm-sdk/TODO_IMPLEMENTATION_PLAN.md
(1 hunks)packages/wasm-sdk/TODO_SUMMARY.md
(1 hunks)packages/wasm-sdk/USAGE_EXAMPLES.md
(1 hunks)packages/wasm-sdk/build-optimized.sh
(1 hunks)packages/wasm-sdk/docs/API_DOCUMENTATION.md
(1 hunks)packages/wasm-sdk/docs/MIGRATION_GUIDE.md
(1 hunks)packages/wasm-sdk/docs/TROUBLESHOOTING.md
(1 hunks)packages/wasm-sdk/examples/bls-signatures-example.js
(1 hunks)packages/wasm-sdk/examples/contract-cache-example.js
(1 hunks)packages/wasm-sdk/examples/group-actions-example.js
(1 hunks)packages/wasm-sdk/examples/identity-creation-example.js
(1 hunks)
⛔ Files not processed due to max files limit (9)
- packages/wasm-sdk/examples/state-transition-example.js
- packages/wasm-sdk/examples/transport-example.js
- packages/wasm-sdk/package.json
- packages/wasm-sdk/run-tests.sh
- packages/wasm-sdk/scripts/security-audit.sh
- packages/wasm-sdk/src/asset_lock.rs
- packages/wasm-sdk/src/asset_lock_implementation.md
- packages/wasm-sdk/src/bincode_reexport.rs
- packages/wasm-sdk/src/bip39.rs
💤 Files with no reviewable changes (1)
- packages/wasm-drive-verify/src/utils/getters.rs
🧰 Additional context used
🧠 Learnings (69)
📓 Common learnings
Learnt from: QuantumExplorer
PR: dashpay/platform#2673
File: packages/rs-drive-abci/src/execution/validation/state_transition/state_transitions/identity_update/mod.rs:1164-1197
Timestamp: 2025-06-18T03:44:14.385Z
Learning: QuantumExplorer determined that a CodeRabbit suggestion about fixing signable_bytes calculation in identity update tests with contract-bound keys was incorrect - the code flow is working as intended without the suggested changes.
Learnt from: shumkov
PR: dashpay/platform#2206
File: packages/rs-platform-version/src/version/protocol_version.rs:155-157
Timestamp: 2024-10-04T09:08:48.470Z
Learning: In the dashmate default configurations, the default protocol version for local networks has been removed, and an update mechanism for the protocol version in the consensus parameters has been implemented.
Learnt from: shumkov
PR: dashpay/platform#2206
File: packages/rs-platform-version/src/version/protocol_version.rs:155-157
Timestamp: 2024-10-09T00:22:57.778Z
Learning: In the dashmate default configurations, the default protocol version for local networks has been removed, and an update mechanism for the protocol version in the consensus parameters has been implemented.
Learnt from: shumkov
PR: dashpay/platform#2270
File: packages/dapi/lib/grpcServer/handlers/platform/broadcastStateTransitionHandlerFactory.js:19-19
Timestamp: 2024-10-24T04:58:02.843Z
Learning: For operations involving Tenderdash where no client library exists yet, it's acceptable to use the Node.js built-in `crypto` module.
Learnt from: CR
PR: dashpay/platform#0
File: CLAUDE.md:0-0
Timestamp: 2025-06-24T08:18:22.301Z
Learning: Platform data contracts define application data schemas for core features such as naming services, social payments, feature flags, masternode reward shares, and withdrawals.
Learnt from: CR
PR: dashpay/platform#0
File: CLAUDE.md:0-0
Timestamp: 2025-06-24T08:18:22.301Z
Learning: The repository uses a monorepo structure managed by Yarn workspaces, allowing multiple packages (in Rust, JavaScript, and WebAssembly) to be developed and tested together.
Learnt from: QuantumExplorer
PR: dashpay/platform#2257
File: packages/rs-drive-abci/src/mimic/test_quorum.rs:159-164
Timestamp: 2024-11-20T16:16:01.830Z
Learning: QuantumExplorer prefers not to receive auto-generated messages asking to post on social media.
Learnt from: QuantumExplorer
PR: dashpay/platform#2439
File: packages/rs-dpp/src/errors/consensus/state/token/mod.rs:4-22
Timestamp: 2025-01-23T02:10:08.979Z
Learning: The user QuantumExplorer prefers to handle documentation of breaking changes separately from the code changes, particularly for token-related error types and validation rules.
packages/js-dash-sdk-original/.gitignore (1)
Learnt from: CR
PR: dashpay/platform#0
File: CLAUDE.md:0-0
Timestamp: 2025-06-24T08:18:22.301Z
Learning: The repository uses a monorepo structure managed by Yarn workspaces, allowing multiple packages (in Rust, JavaScript, and WebAssembly) to be developed and tested together.
CLAUDE.md (9)
Learnt from: shumkov
PR: dashpay/platform#2249
File: packages/dashmate/test/unit/status/scopes/platform.spec.js:466-467
Timestamp: 2024-10-18T15:37:21.329Z
Learning: In test files for the dashmate project, such as `packages/dashmate/test/unit/status/scopes/platform.spec.js`, prefer to keep mocks explicitly in tests rather than consolidating them, to increase readability.
Learnt from: CR
PR: dashpay/platform#0
File: CLAUDE.md:0-0
Timestamp: 2025-06-24T08:18:22.301Z
Learning: The repository uses a monorepo structure managed by Yarn workspaces, allowing multiple packages (in Rust, JavaScript, and WebAssembly) to be developed and tested together.
Learnt from: shumkov
PR: dashpay/platform#2249
File: packages/dashmate/test/unit/status/scopes/platform.spec.js:77-78
Timestamp: 2024-10-18T15:37:36.387Z
Learning: In `packages/dashmate/test/unit/status/scopes/platform.spec.js`, prefer to keep mocks explicitly in tests to increase readability, rather than refactoring them into shared `beforeEach` blocks or helper functions.
Learnt from: shumkov
PR: dashpay/platform#2314
File: packages/wallet-contract/test/bootstrap.js:14-16
Timestamp: 2024-11-06T07:27:01.722Z
Learning: In `packages/wallet-contract/test/bootstrap.js`, for Mocha tests in Node.js, async functions like `loadWasmDpp` can be assigned directly to `beforeAll` without wrapping them in another async function.
Learnt from: CR
PR: dashpay/platform#0
File: CLAUDE.md:0-0
Timestamp: 2025-06-24T08:18:22.301Z
Learning: Testing is comprehensive and includes unit, integration, and end-to-end (e2e) test suites.
Learnt from: shumkov
PR: dashpay/platform#2489
File: packages/rs-dpp/Cargo.toml:32-32
Timestamp: 2025-03-11T09:39:23.071Z
Learning: In the Dash Platform project, dependencies are currently managed using Git repository references with tags (repo+tag format in Cargo.toml) rather than published crates, as the team is not currently publishing crates to crates.io.
Learnt from: CR
PR: dashpay/platform#0
File: CLAUDE.md:0-0
Timestamp: 2025-06-24T08:18:22.301Z
Learning: Platform versioning is handled by the rs-platform-version package, ensuring protocol compatibility across components.
Learnt from: CR
PR: dashpay/platform#0
File: CLAUDE.md:0-0
Timestamp: 2025-06-24T08:18:22.301Z
Learning: The rs-platform-value package is used for cross-language data representation, facilitating interoperability between Rust and JavaScript.
Learnt from: CR
PR: dashpay/platform#0
File: CLAUDE.md:0-0
Timestamp: 2025-06-24T08:18:22.301Z
Learning: Platform data contracts define application data schemas for core features such as naming services, social payments, feature flags, masternode reward shares, and withdrawals.
packages/README.md (6)
Learnt from: CR
PR: dashpay/platform#0
File: CLAUDE.md:0-0
Timestamp: 2025-06-24T08:18:22.301Z
Learning: Platform versioning is handled by the rs-platform-version package, ensuring protocol compatibility across components.
Learnt from: shumkov
PR: dashpay/platform#2206
File: packages/rs-platform-version/src/version/protocol_version.rs:155-157
Timestamp: 2024-10-09T00:22:57.778Z
Learning: In the dashmate default configurations, the default protocol version for local networks has been removed, and an update mechanism for the protocol version in the consensus parameters has been implemented.
Learnt from: shumkov
PR: dashpay/platform#2206
File: packages/rs-platform-version/src/version/protocol_version.rs:155-157
Timestamp: 2024-10-04T09:08:48.470Z
Learning: In the dashmate default configurations, the default protocol version for local networks has been removed, and an update mechanism for the protocol version in the consensus parameters has been implemented.
Learnt from: shumkov
PR: dashpay/platform#2270
File: packages/dapi/lib/grpcServer/handlers/platform/broadcastStateTransitionHandlerFactory.js:19-19
Timestamp: 2024-10-24T04:58:02.843Z
Learning: For operations involving Tenderdash where no client library exists yet, it's acceptable to use the Node.js built-in `crypto` module.
Learnt from: shumkov
PR: dashpay/platform#2489
File: packages/rs-dpp/Cargo.toml:32-32
Timestamp: 2025-03-11T09:39:23.071Z
Learning: In the Dash Platform project, dependencies are currently managed using Git repository references with tags (repo+tag format in Cargo.toml) rather than published crates, as the team is not currently publishing crates to crates.io.
Learnt from: CR
PR: dashpay/platform#0
File: CLAUDE.md:0-0
Timestamp: 2025-06-24T08:18:22.301Z
Learning: The repository uses a monorepo structure managed by Yarn workspaces, allowing multiple packages (in Rust, JavaScript, and WebAssembly) to be developed and tested together.
packages/wasm-drive-verify/src/lib.rs (12)
Learnt from: CR
PR: dashpay/platform#0
File: CLAUDE.md:0-0
Timestamp: 2025-06-24T08:18:22.301Z
Learning: Cross-language integration is achieved using WebAssembly (WASM) bindings to connect Rust and JavaScript codebases.
Learnt from: lklimek
PR: dashpay/platform#2254
File: packages/rs-sdk/src/sdk.rs:585-585
Timestamp: 2024-10-18T15:39:51.172Z
Learning: The 'platform' project uses Rust version 1.80, so code in 'packages/rs-sdk' can use features available in Rust 1.80, such as the `abs_diff()` method.
Learnt from: QuantumExplorer
PR: dashpay/platform#2215
File: packages/rs-drive-abci/src/execution/platform_events/core_based_updates/update_masternode_identities/create_owner_identity/v1/mod.rs:19-30
Timestamp: 2024-10-06T16:11:34.946Z
Learning: In the Rust file `packages/rs-drive-abci/src/execution/platform_events/core_based_updates/update_masternode_identities/create_owner_identity/v1/mod.rs`, within the `create_owner_identity_v1` function, the `add_public_keys` method of the `Identity` struct cannot fail and does not require explicit error handling.
Learnt from: QuantumExplorer
PR: dashpay/platform#2215
File: packages/rs-drive-abci/src/execution/platform_events/core_based_updates/update_masternode_identities/create_owner_identity/v1/mod.rs:19-30
Timestamp: 2024-10-09T00:22:57.778Z
Learning: In the Rust file `packages/rs-drive-abci/src/execution/platform_events/core_based_updates/update_masternode_identities/create_owner_identity/v1/mod.rs`, within the `create_owner_identity_v1` function, the `add_public_keys` method of the `Identity` struct cannot fail and does not require explicit error handling.
Learnt from: shumkov
PR: dashpay/platform#2248
File: packages/rs-drive-abci/src/main.rs:106-111
Timestamp: 2024-10-17T08:52:54.300Z
Learning: In this project, the environment variable `CARGO_PKG_RUST_VERSION` is defined and can be used safely with the `env!` macro.
Learnt from: lklimek
PR: dashpay/platform#2277
File: packages/rs-sdk/tests/fetch/config.rs:233-233
Timestamp: 2024-10-30T11:19:59.163Z
Learning: In the Rust SDK's `rs-sdk/tests` integration tests (e.g., in `packages/rs-sdk/tests/fetch/config.rs`), we cannot create objects during tests because there is no support for object creation in this context. Therefore, hardcoded values for test identities must be used.
Learnt from: shumkov
PR: dashpay/platform#2345
File: packages/wallet-utils-contract/src/lib.rs:14-17
Timestamp: 2024-11-25T07:48:09.831Z
Learning: In the `wallet-utils-contract` (file `packages/wallet-utils-contract/src/lib.rs`), the `OWNER_ID_BYTES` constant is intentionally initialized to all zeros.
Learnt from: QuantumExplorer
PR: dashpay/platform#2235
File: packages/rs-dpp/src/identity/identity_public_key/v0/methods/mod.rs:8-9
Timestamp: 2024-10-10T05:10:50.059Z
Learning: In the codebase, importing `Secp256k1` from `dashcore::key::Secp256k1` is acceptable.
Learnt from: lklimek
PR: dashpay/platform#2405
File: packages/rs-sdk/src/sync.rs:88-95
Timestamp: 2025-01-23T09:23:32.740Z
Learning: The `block_on` function in `packages/rs-sdk/src/sync.rs` is currently only used in tests, and its WebAssembly implementation is deferred until there's a user request for it.
Learnt from: lklimek
PR: dashpay/platform#2277
File: packages/rs-dapi-client/src/executor.rs:38-38
Timestamp: 2024-10-29T14:44:01.184Z
Learning: In `packages/rs-dapi-client/src/executor.rs`, for the structs `ExecutionError<E>` and `ExecutionResponse<R>`, only the serde derives (`Serialize`, `Deserialize`) should be conditional based on the "mocks" feature; the other derives (`Debug`, `Clone`, `Eq`, `PartialEq`) should always be present.
Learnt from: QuantumExplorer
PR: dashpay/platform#2257
File: packages/rs-drive-abci/src/platform_types/platform_state/v0/old_structures/mod.rs:94-94
Timestamp: 2024-11-20T10:01:50.837Z
Learning: In `packages/rs-drive-abci/src/platform_types/platform_state/v0/old_structures/mod.rs`, when converting with `PublicKey::try_from`, it's acceptable to use `.expect()` to handle potential conversion errors.
Learnt from: QuantumExplorer
PR: dashpay/platform#2227
File: packages/rs-dpp/src/core_types/validator_set/v0/mod.rs:299-299
Timestamp: 2024-10-21T01:03:42.458Z
Learning: In the `test_serialize_deserialize_validator_set_v0` test within `packages/rs-dpp/src/core_types/validator_set/v0/mod.rs`, deterministic BLS keys cannot be easily used; therefore, using `BlsPublicKey::generate()` is acceptable.
packages/wasm-drive-verify/tests/token_tests.rs (12)
Learnt from: QuantumExplorer
PR: dashpay/platform#2347
File: packages/rs-drive/tests/query_tests.rs:438-460
Timestamp: 2024-11-25T01:17:02.001Z
Learning: In Rust test files (`packages/rs-drive/tests/query_tests.rs`), when code is used only in tests, defining explicit enums for fields (like the `status` field in the `Withdrawal` struct) may not be necessary; using primitive types is acceptable.
Learnt from: lklimek
PR: dashpay/platform#2277
File: packages/rs-sdk/tests/fetch/config.rs:233-233
Timestamp: 2024-10-30T11:19:59.163Z
Learning: In the Rust SDK's `rs-sdk/tests` integration tests (e.g., in `packages/rs-sdk/tests/fetch/config.rs`), we cannot create objects during tests because there is no support for object creation in this context. Therefore, hardcoded values for test identities must be used.
Learnt from: lklimek
PR: dashpay/platform#2405
File: packages/wasm-sdk/src/verify.rs:26-68
Timestamp: 2025-02-10T11:26:36.709Z
Learning: In the wasm-sdk package, empty vectors and placeholder values are intentionally used in verification functions during the proof-of-concept stage to ensure proper compilation and type checking.
Learnt from: QuantumExplorer
PR: dashpay/platform#2227
File: packages/rs-dpp/src/core_types/validator_set/v0/mod.rs:299-299
Timestamp: 2024-10-21T01:03:42.458Z
Learning: In the `test_serialize_deserialize_validator_set_v0` test within `packages/rs-dpp/src/core_types/validator_set/v0/mod.rs`, deterministic BLS keys cannot be easily used; therefore, using `BlsPublicKey::generate()` is acceptable.
Learnt from: QuantumExplorer
PR: dashpay/platform#2215
File: packages/rs-drive-abci/src/execution/platform_events/core_based_updates/update_masternode_identities/create_owner_identity/v1/mod.rs:19-30
Timestamp: 2024-10-06T16:11:34.946Z
Learning: In the Rust file `packages/rs-drive-abci/src/execution/platform_events/core_based_updates/update_masternode_identities/create_owner_identity/v1/mod.rs`, within the `create_owner_identity_v1` function, the `add_public_keys` method of the `Identity` struct cannot fail and does not require explicit error handling.
Learnt from: QuantumExplorer
PR: dashpay/platform#2215
File: packages/rs-drive-abci/src/execution/platform_events/core_based_updates/update_masternode_identities/create_owner_identity/v1/mod.rs:19-30
Timestamp: 2024-10-09T00:22:57.778Z
Learning: In the Rust file `packages/rs-drive-abci/src/execution/platform_events/core_based_updates/update_masternode_identities/create_owner_identity/v1/mod.rs`, within the `create_owner_identity_v1` function, the `add_public_keys` method of the `Identity` struct cannot fail and does not require explicit error handling.
Learnt from: lklimek
PR: dashpay/platform#2405
File: packages/rs-sdk/src/sync.rs:88-95
Timestamp: 2025-01-23T09:23:32.740Z
Learning: The `block_on` function in `packages/rs-sdk/src/sync.rs` is currently only used in tests, and its WebAssembly implementation is deferred until there's a user request for it.
Learnt from: QuantumExplorer
PR: dashpay/platform#2257
File: packages/rs-drive-abci/src/platform_types/signature_verification_quorum_set/v0/for_saving.rs:148-151
Timestamp: 2024-11-20T16:05:40.200Z
Learning: In `packages/rs-drive-abci/src/platform_types/signature_verification_quorum_set/v0/for_saving.rs`, when converting public keys from `QuorumForSavingV0` to `VerificationQuorum`, it's acceptable to use `.expect()` for public key conversion, as the conversion has been verified and panics are acceptable in this context.
Learnt from: QuantumExplorer
PR: dashpay/platform#2257
File: packages/rs-drive-abci/tests/strategy_tests/masternodes.rs:212-220
Timestamp: 2024-11-20T20:43:41.185Z
Learning: In `packages/rs-drive-abci/tests/strategy_tests/masternodes.rs`, the pattern of generating a `PrivateKey`, converting it to bytes, and reconstructing a `BlsPrivateKey` from those bytes is intentional. Avoid suggesting to simplify this code in future reviews.
Learnt from: shumkov
PR: dashpay/platform#2206
File: packages/rs-drive-abci/tests/strategy_tests/main.rs:1162-1162
Timestamp: 2024-10-04T09:08:47.901Z
Learning: In the Rust test file `packages/rs-drive-abci/tests/strategy_tests/main.rs`, specific protocol versions like `PROTOCOL_VERSION_1` are intentionally used in tests instead of `PROTOCOL_VERSION_LATEST`.
Learnt from: lklimek
PR: dashpay/platform#2207
File: packages/rs-drive-proof-verifier/src/proof.rs:1646-1664
Timestamp: 2024-10-04T14:16:05.798Z
Learning: In the implementation of `FromProof<platform::GetContestedResourceIdentityVotesRequest>` in `packages/rs-drive-proof-verifier/src/proof.rs`, when matching `maybe_votes`, using `.expect()` on `v.into_iter().next()` is acceptable because the prior match arm `Some(v) if v.is_empty()` ensures that the map is not empty, preventing a panic.
Learnt from: lklimek
PR: dashpay/platform#2207
File: packages/rs-drive-proof-verifier/src/proof.rs:1646-1664
Timestamp: 2024-10-09T00:22:57.778Z
Learning: In the implementation of `FromProof<platform::GetContestedResourceIdentityVotesRequest>` in `packages/rs-drive-proof-verifier/src/proof.rs`, when matching `maybe_votes`, using `.expect()` on `v.into_iter().next()` is acceptable because the prior match arm `Some(v) if v.is_empty()` ensures that the map is not empty, preventing a panic.
packages/wasm-drive-verify/tests/document_tests.rs (14)
Learnt from: lklimek
PR: dashpay/platform#2405
File: packages/wasm-sdk/src/verify.rs:26-68
Timestamp: 2025-02-10T11:26:36.709Z
Learning: In the wasm-sdk package, empty vectors and placeholder values are intentionally used in verification functions during the proof-of-concept stage to ensure proper compilation and type checking.
Learnt from: QuantumExplorer
PR: dashpay/platform#2347
File: packages/rs-drive/tests/query_tests.rs:438-460
Timestamp: 2024-11-25T01:17:02.001Z
Learning: In Rust test files (`packages/rs-drive/tests/query_tests.rs`), when code is used only in tests, defining explicit enums for fields (like the `status` field in the `Withdrawal` struct) may not be necessary; using primitive types is acceptable.
Learnt from: CR
PR: dashpay/platform#0
File: CLAUDE.md:0-0
Timestamp: 2025-06-24T08:18:22.301Z
Learning: Cross-language integration is achieved using WebAssembly (WASM) bindings to connect Rust and JavaScript codebases.
Learnt from: QuantumExplorer
PR: dashpay/platform#2227
File: packages/rs-dpp/src/core_types/validator_set/v0/mod.rs:299-299
Timestamp: 2024-10-21T01:03:42.458Z
Learning: In the `test_serialize_deserialize_validator_set_v0` test within `packages/rs-dpp/src/core_types/validator_set/v0/mod.rs`, deterministic BLS keys cannot be easily used; therefore, using `BlsPublicKey::generate()` is acceptable.
Learnt from: lklimek
PR: dashpay/platform#2277
File: packages/rs-sdk/tests/fetch/config.rs:233-233
Timestamp: 2024-10-30T11:19:59.163Z
Learning: In the Rust SDK's `rs-sdk/tests` integration tests (e.g., in `packages/rs-sdk/tests/fetch/config.rs`), we cannot create objects during tests because there is no support for object creation in this context. Therefore, hardcoded values for test identities must be used.
Learnt from: QuantumExplorer
PR: dashpay/platform#2257
File: packages/rs-drive-abci/src/platform_types/signature_verification_quorum_set/v0/for_saving.rs:148-151
Timestamp: 2024-11-20T16:05:40.200Z
Learning: In `packages/rs-drive-abci/src/platform_types/signature_verification_quorum_set/v0/for_saving.rs`, when converting public keys from `QuorumForSavingV0` to `VerificationQuorum`, it's acceptable to use `.expect()` for public key conversion, as the conversion has been verified and panics are acceptable in this context.
Learnt from: lklimek
PR: dashpay/platform#2405
File: packages/rs-sdk/src/sync.rs:88-95
Timestamp: 2025-01-23T09:23:32.740Z
Learning: The `block_on` function in `packages/rs-sdk/src/sync.rs` is currently only used in tests, and its WebAssembly implementation is deferred until there's a user request for it.
Learnt from: shumkov
PR: dashpay/platform#2314
File: packages/wallet-contract/test/bootstrap.js:14-16
Timestamp: 2024-11-06T07:27:01.722Z
Learning: In `packages/wallet-contract/test/bootstrap.js`, for Mocha tests in Node.js, async functions like `loadWasmDpp` can be assigned directly to `beforeAll` without wrapping them in another async function.
Learnt from: lklimek
PR: dashpay/platform#2380
File: packages/rs-drive-proof-verifier/src/error.rs:122-125
Timestamp: 2024-12-06T14:15:49.367Z
Learning: All error variants in `ContextProviderError` within `packages/rs-drive-proof-verifier/src/error.rs` are designed to take `String` as their parameter.
Learnt from: lklimek
PR: dashpay/platform#2405
File: packages/rs-sdk/src/sync.rs:88-95
Timestamp: 2025-01-23T09:23:32.740Z
Learning: The `block_on` function in `packages/rs-sdk/src/sync.rs` requires true blocking behavior, which is why a non-blocking WebAssembly implementation using `wasm_bindgen_futures::spawn_local` is not suitable.
Learnt from: shumkov
PR: dashpay/platform#2422
File: packages/rs-drive-abci/src/execution/platform_events/protocol_upgrade/perform_events_on_first_block_of_protocol_change/v0/mod.rs:152-163
Timestamp: 2025-01-15T08:09:59.365Z
Learning: In the `transition_to_version_8` function, errors from `grove_get_path_query` when retrieving active contested resource votes are intentionally logged and ignored (returning `Ok(())`) to allow the protocol upgrade to proceed despite query failures.
Learnt from: lklimek
PR: dashpay/platform#2207
File: packages/rs-drive-proof-verifier/src/proof.rs:1646-1664
Timestamp: 2024-10-04T14:16:05.798Z
Learning: In the implementation of `FromProof<platform::GetContestedResourceIdentityVotesRequest>` in `packages/rs-drive-proof-verifier/src/proof.rs`, when matching `maybe_votes`, using `.expect()` on `v.into_iter().next()` is acceptable because the prior match arm `Some(v) if v.is_empty()` ensures that the map is not empty, preventing a panic.
Learnt from: lklimek
PR: dashpay/platform#2207
File: packages/rs-drive-proof-verifier/src/proof.rs:1646-1664
Timestamp: 2024-10-09T00:22:57.778Z
Learning: In the implementation of `FromProof<platform::GetContestedResourceIdentityVotesRequest>` in `packages/rs-drive-proof-verifier/src/proof.rs`, when matching `maybe_votes`, using `.expect()` on `v.into_iter().next()` is acceptable because the prior match arm `Some(v) if v.is_empty()` ensures that the map is not empty, preventing a panic.
Learnt from: lklimek
PR: dashpay/platform#2277
File: packages/rs-sdk/src/core/transaction.rs:0-0
Timestamp: 2024-10-29T14:40:54.727Z
Learning: In `packages/rs-sdk/src/platform/document_query.rs` and `packages/rs-sdk/src/core/transaction.rs`, certain places don't implement `IntoInner`, so direct error mappings cannot be simplified using `IntoInner`. A TODO comment has been added to address this in a future PR.
packages/js-dash-sdk/tests/sdk.test.ts (3)
Learnt from: shumkov
PR: dashpay/platform#2249
File: packages/dashmate/test/unit/status/scopes/platform.spec.js:77-78
Timestamp: 2024-10-18T15:37:36.387Z
Learning: In `packages/dashmate/test/unit/status/scopes/platform.spec.js`, prefer to keep mocks explicitly in tests to increase readability, rather than refactoring them into shared `beforeEach` blocks or helper functions.
Learnt from: shumkov
PR: dashpay/platform#2249
File: packages/dashmate/test/unit/status/scopes/platform.spec.js:466-467
Timestamp: 2024-10-18T15:37:21.329Z
Learning: In test files for the dashmate project, such as `packages/dashmate/test/unit/status/scopes/platform.spec.js`, prefer to keep mocks explicitly in tests rather than consolidating them, to increase readability.
Learnt from: lklimek
PR: dashpay/platform#2277
File: packages/rs-sdk/tests/fetch/config.rs:233-233
Timestamp: 2024-10-30T11:19:59.163Z
Learning: In the Rust SDK's `rs-sdk/tests` integration tests (e.g., in `packages/rs-sdk/tests/fetch/config.rs`), we cannot create objects during tests because there is no support for object creation in this context. Therefore, hardcoded values for test identities must be used.
packages/wasm-drive-verify/tests/fuzz_tests.rs (10)
Learnt from: QuantumExplorer
PR: dashpay/platform#2332
File: packages/rs-drive-proof-verifier/src/error.rs:21-23
Timestamp: 2024-11-15T14:39:23.704Z
Learning: In the `packages/rs-drive-proof-verifier`, avoid suggesting size limits for `proof_bytes` in errors unless there's a specific need, as it may not be necessary.
Learnt from: lklimek
PR: dashpay/platform#2277
File: packages/rs-sdk/src/core/transaction.rs:0-0
Timestamp: 2024-10-29T14:40:54.727Z
Learning: In `packages/rs-sdk/src/platform/document_query.rs` and `packages/rs-sdk/src/core/transaction.rs`, certain places don't implement `IntoInner`, so direct error mappings cannot be simplified using `IntoInner`. A TODO comment has been added to address this in a future PR.
Learnt from: lklimek
PR: dashpay/platform#2405
File: packages/wasm-sdk/src/verify.rs:26-68
Timestamp: 2025-02-10T11:26:36.709Z
Learning: In the wasm-sdk package, empty vectors and placeholder values are intentionally used in verification functions during the proof-of-concept stage to ensure proper compilation and type checking.
Learnt from: QuantumExplorer
PR: dashpay/platform#2347
File: packages/rs-drive/tests/query_tests.rs:438-460
Timestamp: 2024-11-25T01:17:02.001Z
Learning: In Rust test files (`packages/rs-drive/tests/query_tests.rs`), when code is used only in tests, defining explicit enums for fields (like the `status` field in the `Withdrawal` struct) may not be necessary; using primitive types is acceptable.
Learnt from: QuantumExplorer
PR: dashpay/platform#2257
File: packages/rs-drive-abci/tests/strategy_tests/masternodes.rs:212-220
Timestamp: 2024-11-20T20:43:41.185Z
Learning: In `packages/rs-drive-abci/tests/strategy_tests/masternodes.rs`, the pattern of generating a `PrivateKey`, converting it to bytes, and reconstructing a `BlsPrivateKey` from those bytes is intentional. Avoid suggesting to simplify this code in future reviews.
Learnt from: shumkov
PR: dashpay/platform#2317
File: packages/rs-dapi-client/src/address_list.rs:175-180
Timestamp: 2024-11-28T13:49:17.301Z
Learning: In Rust code in `packages/rs-dapi-client/src/address_list.rs`, do not change the interface of deprecated methods like `add_uri`, even to fix potential panics.
Learnt from: QuantumExplorer
PR: dashpay/platform#2257
File: packages/rs-drive-abci/src/platform_types/signature_verification_quorum_set/v0/for_saving.rs:148-151
Timestamp: 2024-11-20T16:05:40.200Z
Learning: In `packages/rs-drive-abci/src/platform_types/signature_verification_quorum_set/v0/for_saving.rs`, when converting public keys from `QuorumForSavingV0` to `VerificationQuorum`, it's acceptable to use `.expect()` for public key conversion, as the conversion has been verified and panics are acceptable in this context.
Learnt from: lklimek
PR: dashpay/platform#2207
File: packages/rs-drive-proof-verifier/src/proof.rs:1646-1664
Timestamp: 2024-10-09T00:22:57.778Z
Learning: In the implementation of `FromProof<platform::GetContestedResourceIdentityVotesRequest>` in `packages/rs-drive-proof-verifier/src/proof.rs`, when matching `maybe_votes`, using `.expect()` on `v.into_iter().next()` is acceptable because the prior match arm `Some(v) if v.is_empty()` ensures that the map is not empty, preventing a panic.
Learnt from: lklimek
PR: dashpay/platform#2207
File: packages/rs-drive-proof-verifier/src/proof.rs:1646-1664
Timestamp: 2024-10-04T14:16:05.798Z
Learning: In the implementation of `FromProof<platform::GetContestedResourceIdentityVotesRequest>` in `packages/rs-drive-proof-verifier/src/proof.rs`, when matching `maybe_votes`, using `.expect()` on `v.into_iter().next()` is acceptable because the prior match arm `Some(v) if v.is_empty()` ensures that the map is not empty, preventing a panic.
Learnt from: lklimek
PR: dashpay/platform#2277
File: packages/rs-sdk/src/platform/fetch_unproved.rs:0-0
Timestamp: 2024-10-30T11:04:33.634Z
Learning: In `packages/rs-sdk/src/platform/fetch_unproved.rs`, the `execute()` method consumes the request object, so cloning the request is necessary before passing it to `execute()` and `maybe_from_unproved_with_metadata`.
packages/js-dash-sdk/examples/basic-usage.ts (3)
Learnt from: lklimek
PR: dashpay/platform#2381
File: packages/rs-sdk/scripts/connect_to_remote.sh:0-0
Timestamp: 2024-12-10T12:39:38.182Z
Learning: When reviewing scripts in `packages/rs-sdk/scripts/`, avoid suggesting additional error handling and timeout management that complicate the script without adding significant value.
Learnt from: shumkov
PR: dashpay/platform#2314
File: packages/wallet-contract/test/bootstrap.js:14-16
Timestamp: 2024-11-06T07:27:01.722Z
Learning: In `packages/wallet-contract/test/bootstrap.js`, for Mocha tests in Node.js, async functions like `loadWasmDpp` can be assigned directly to `beforeAll` without wrapping them in another async function.
Learnt from: lklimek
PR: dashpay/platform#2277
File: packages/rs-sdk/tests/fetch/config.rs:233-233
Timestamp: 2024-10-30T11:19:59.163Z
Learning: In the Rust SDK's `rs-sdk/tests` integration tests (e.g., in `packages/rs-sdk/tests/fetch/config.rs`), we cannot create objects during tests because there is no support for object creation in this context. Therefore, hardcoded values for test identities must be used.
packages/wasm-drive-verify/tests/identity_tests.rs (13)
Learnt from: shumkov
PR: dashpay/platform#2201
File: packages/rs-platform-version/src/version/v2.rs:1186-1188
Timestamp: 2024-10-03T11:51:06.980Z
Learning: In the `IdentityTransitionVersions` structure within `packages/rs-platform-version/src/version/v2.rs`, the field `credit_withdrawal` does not need the `identity_` prefix since it is already encompassed within identity state transitions.
Learnt from: shumkov
PR: dashpay/platform#2201
File: packages/rs-platform-version/src/version/v2.rs:1186-1188
Timestamp: 2024-10-09T00:22:57.778Z
Learning: In the `IdentityTransitionVersions` structure within `packages/rs-platform-version/src/version/v2.rs`, the field `credit_withdrawal` does not need the `identity_` prefix since it is already encompassed within identity state transitions.
Learnt from: QuantumExplorer
PR: dashpay/platform#2347
File: packages/rs-drive/tests/query_tests.rs:438-460
Timestamp: 2024-11-25T01:17:02.001Z
Learning: In Rust test files (`packages/rs-drive/tests/query_tests.rs`), when code is used only in tests, defining explicit enums for fields (like the `status` field in the `Withdrawal` struct) may not be necessary; using primitive types is acceptable.
Learnt from: QuantumExplorer
PR: dashpay/platform#2257
File: packages/rs-drive-abci/tests/strategy_tests/masternodes.rs:212-220
Timestamp: 2024-11-20T20:43:41.185Z
Learning: In `packages/rs-drive-abci/tests/strategy_tests/masternodes.rs`, the pattern of generating a `PrivateKey`, converting it to bytes, and reconstructing a `BlsPrivateKey` from those bytes is intentional. Avoid suggesting to simplify this code in future reviews.
Learnt from: lklimek
PR: dashpay/platform#2277
File: packages/rs-sdk/tests/fetch/config.rs:233-233
Timestamp: 2024-10-30T11:19:59.163Z
Learning: In the Rust SDK's `rs-sdk/tests` integration tests (e.g., in `packages/rs-sdk/tests/fetch/config.rs`), we cannot create objects during tests because there is no support for object creation in this context. Therefore, hardcoded values for test identities must be used.
Learnt from: QuantumExplorer
PR: dashpay/platform#2215
File: packages/rs-drive-abci/src/execution/platform_events/core_based_updates/update_masternode_identities/create_owner_identity/v1/mod.rs:19-30
Timestamp: 2024-10-06T16:11:34.946Z
Learning: In the Rust file `packages/rs-drive-abci/src/execution/platform_events/core_based_updates/update_masternode_identities/create_owner_identity/v1/mod.rs`, within the `create_owner_identity_v1` function, the `add_public_keys` method of the `Identity` struct cannot fail and does not require explicit error handling.
Learnt from: QuantumExplorer
PR: dashpay/platform#2215
File: packages/rs-drive-abci/src/execution/platform_events/core_based_updates/update_masternode_identities/create_owner_identity/v1/mod.rs:19-30
Timestamp: 2024-10-09T00:22:57.778Z
Learning: In the Rust file `packages/rs-drive-abci/src/execution/platform_events/core_based_updates/update_masternode_identities/create_owner_identity/v1/mod.rs`, within the `create_owner_identity_v1` function, the `add_public_keys` method of the `Identity` struct cannot fail and does not require explicit error handling.
Learnt from: QuantumExplorer
PR: dashpay/platform#2673
File: packages/rs-drive-abci/src/execution/validation/state_transition/state_transitions/identity_update/mod.rs:1164-1197
Timestamp: 2025-06-18T03:44:14.385Z
Learning: QuantumExplorer determined that a CodeRabbit suggestion about fixing signable_bytes calculation in identity update tests with contract-bound keys was incorrect - the code flow is working as intended without the suggested changes.
Learnt from: lklimek
PR: dashpay/platform#2405
File: packages/wasm-sdk/src/verify.rs:26-68
Timestamp: 2025-02-10T11:26:36.709Z
Learning: In the wasm-sdk package, empty vectors and placeholder values are intentionally used in verification functions during the proof-of-concept stage to ensure proper compilation and type checking.
Learnt from: QuantumExplorer
PR: dashpay/platform#2257
File: packages/rs-drive-abci/src/platform_types/signature_verification_quorum_set/v0/for_saving.rs:148-151
Timestamp: 2024-11-20T16:05:40.200Z
Learning: In `packages/rs-drive-abci/src/platform_types/signature_verification_quorum_set/v0/for_saving.rs`, when converting public keys from `QuorumForSavingV0` to `VerificationQuorum`, it's acceptable to use `.expect()` for public key conversion, as the conversion has been verified and panics are acceptable in this context.
Learnt from: lklimek
PR: dashpay/platform#2207
File: packages/rs-drive-proof-verifier/src/proof.rs:1646-1664
Timestamp: 2024-10-09T00:22:57.778Z
Learning: In the implementation of `FromProof<platform::GetContestedResourceIdentityVotesRequest>` in `packages/rs-drive-proof-verifier/src/proof.rs`, when matching `maybe_votes`, using `.expect()` on `v.into_iter().next()` is acceptable because the prior match arm `Some(v) if v.is_empty()` ensures that the map is not empty, preventing a panic.
Learnt from: lklimek
PR: dashpay/platform#2207
File: packages/rs-drive-proof-verifier/src/proof.rs:1646-1664
Timestamp: 2024-10-04T14:16:05.798Z
Learning: In the implementation of `FromProof<platform::GetContestedResourceIdentityVotesRequest>` in `packages/rs-drive-proof-verifier/src/proof.rs`, when matching `maybe_votes`, using `.expect()` on `v.into_iter().next()` is acceptable because the prior match arm `Some(v) if v.is_empty()` ensures that the map is not empty, preventing a panic.
Learnt from: shumkov
PR: dashpay/platform#2345
File: packages/wallet-utils-contract/src/lib.rs:14-17
Timestamp: 2024-11-25T07:48:09.831Z
Learning: In the `wallet-utils-contract` (file `packages/wallet-utils-contract/src/lib.rs`), the `OWNER_ID_BYTES` constant is intentionally initialized to all zeros.
packages/js-dash-sdk/scripts/build-wasm.sh (2)
Learnt from: lklimek
PR: dashpay/platform#2381
File: packages/rs-sdk/scripts/connect_to_remote.sh:0-0
Timestamp: 2024-12-10T12:39:38.182Z
Learning: When reviewing scripts in `packages/rs-sdk/scripts/`, avoid suggesting additional error handling and timeout management that complicate the script without adding significant value.
Learnt from: CR
PR: dashpay/platform#0
File: CLAUDE.md:0-0
Timestamp: 2025-06-24T08:18:22.301Z
Learning: Cross-language integration is achieved using WebAssembly (WASM) bindings to connect Rust and JavaScript codebases.
packages/js-dash-sdk/jest.config.js (2)
Learnt from: shumkov
PR: dashpay/platform#2249
File: packages/dashmate/test/unit/status/scopes/platform.spec.js:466-467
Timestamp: 2024-10-18T15:37:21.329Z
Learning: In test files for the dashmate project, such as `packages/dashmate/test/unit/status/scopes/platform.spec.js`, prefer to keep mocks explicitly in tests rather than consolidating them, to increase readability.
Learnt from: shumkov
PR: dashpay/platform#2249
File: packages/dashmate/test/unit/status/scopes/platform.spec.js:77-78
Timestamp: 2024-10-18T15:37:36.387Z
Learning: In `packages/dashmate/test/unit/status/scopes/platform.spec.js`, prefer to keep mocks explicitly in tests to increase readability, rather than refactoring them into shared `beforeEach` blocks or helper functions.
.gitignore (6)
Learnt from: CR
PR: dashpay/platform#0
File: CLAUDE.md:0-0
Timestamp: 2025-06-24T08:18:22.301Z
Learning: The repository uses a monorepo structure managed by Yarn workspaces, allowing multiple packages (in Rust, JavaScript, and WebAssembly) to be developed and tested together.
Learnt from: lklimek
PR: dashpay/platform#2405
File: packages/wasm-sdk/src/verify.rs:26-68
Timestamp: 2025-02-10T11:26:36.709Z
Learning: In the wasm-sdk package, empty vectors and placeholder values are intentionally used in verification functions during the proof-of-concept stage to ensure proper compilation and type checking.
Learnt from: QuantumExplorer
PR: dashpay/platform#2431
File: packages/rs-drive/Cargo.toml:55-60
Timestamp: 2025-01-19T07:36:46.042Z
Learning: The grovedb dependencies in packages/rs-drive/Cargo.toml and related files are intentionally kept at specific revisions rather than using the latest stable version, with plans to update them at a later time.
Learnt from: lklimek
PR: dashpay/platform#2030
File: packages/rs-sdk/tests/vectors/test_asset_lock_proof/quorum_pubkey-100-4ce7fd81273c2b394c0f32367374fc5b09ba912e017aacb366d2171e9ca6f9d5.json:1-1
Timestamp: 2024-12-10T10:56:26.215Z
Learning: In the `packages/rs-sdk/tests/vectors/test_asset_lock_proof/` directory, files with the `.json` extension are mock data that may not follow standard JSON format; this is intentional and acceptable within the project's testing framework.
Learnt from: shumkov
PR: dashpay/platform#2375
File: packages/rs-drive-abci/Cargo.toml:61-63
Timestamp: 2024-12-05T09:29:38.918Z
Learning: In the `drive-abci` package, avoid adding unused dependencies like `hashbrown` to `Cargo.toml`. The team relies on CI to detect dependency version issues.
Learnt from: lklimek
PR: dashpay/platform#2405
File: packages/wasm-sdk/src/lib.rs:13-17
Timestamp: 2025-01-23T09:43:25.080Z
Learning: The codebase uses tracing_wasm for WebAssembly tracing as it provides sufficient functionality for the project's needs.
packages/js-dash-sdk/examples/modular-usage.ts (3)
Learnt from: shumkov
PR: dashpay/platform#2249
File: packages/dashmate/test/unit/status/scopes/platform.spec.js:466-467
Timestamp: 2024-10-18T15:37:21.329Z
Learning: In test files for the dashmate project, such as `packages/dashmate/test/unit/status/scopes/platform.spec.js`, prefer to keep mocks explicitly in tests rather than consolidating them, to increase readability.
Learnt from: lklimek
PR: dashpay/platform#2381
File: packages/rs-sdk/scripts/connect_to_remote.sh:0-0
Timestamp: 2024-12-10T12:39:38.182Z
Learning: When reviewing scripts in `packages/rs-sdk/scripts/`, avoid suggesting additional error handling and timeout management that complicate the script without adding significant value.
Learnt from: shumkov
PR: dashpay/platform#2314
File: packages/wallet-contract/test/bootstrap.js:14-16
Timestamp: 2024-11-06T07:27:01.722Z
Learning: In `packages/wallet-contract/test/bootstrap.js`, for Mocha tests in Node.js, async functions like `loadWasmDpp` can be assigned directly to `beforeAll` without wrapping them in another async function.
packages/wasm-sdk/docs/TROUBLESHOOTING.md (4)
Learnt from: lklimek
PR: dashpay/platform#2405
File: packages/wasm-sdk/src/verify.rs:26-68
Timestamp: 2025-02-10T11:26:36.709Z
Learning: In the wasm-sdk package, empty vectors and placeholder values are intentionally used in verification functions during the proof-of-concept stage to ensure proper compilation and type checking.
Learnt from: QuantumExplorer
PR: dashpay/platform#2439
File: packages/rs-dpp/src/errors/consensus/state/token/mod.rs:4-22
Timestamp: 2025-01-23T02:10:08.979Z
Learning: The user QuantumExplorer prefers to handle documentation of breaking changes separately from the code changes, particularly for token-related error types and validation rules.
Learnt from: lklimek
PR: dashpay/platform#2405
File: packages/wasm-sdk/src/lib.rs:13-17
Timestamp: 2025-01-23T09:43:25.080Z
Learning: The codebase uses tracing_wasm for WebAssembly tracing as it provides sufficient functionality for the project's needs.
Learnt from: CR
PR: dashpay/platform#0
File: CLAUDE.md:0-0
Timestamp: 2025-06-24T08:18:22.301Z
Learning: Cross-language integration is achieved using WebAssembly (WASM) bindings to connect Rust and JavaScript codebases.
packages/js-dash-sdk/src/core/index.ts (1)
Learnt from: shumkov
PR: dashpay/platform#2314
File: packages/wallet-contract/test/bootstrap.js:14-16
Timestamp: 2024-11-06T07:27:01.722Z
Learning: In `packages/wallet-contract/test/bootstrap.js`, for Mocha tests in Node.js, async functions like `loadWasmDpp` can be assigned directly to `beforeAll` without wrapping them in another async function.
packages/js-dash-sdk/tests/bluetooth/protocol.test.ts (2)
Learnt from: shumkov
PR: dashpay/platform#2249
File: packages/dashmate/test/unit/status/scopes/platform.spec.js:466-467
Timestamp: 2024-10-18T15:37:21.329Z
Learning: In test files for the dashmate project, such as `packages/dashmate/test/unit/status/scopes/platform.spec.js`, prefer to keep mocks explicitly in tests rather than consolidating them, to increase readability.
Learnt from: shumkov
PR: dashpay/platform#2249
File: packages/dashmate/test/unit/status/scopes/platform.spec.js:77-78
Timestamp: 2024-10-18T15:37:36.387Z
Learning: In `packages/dashmate/test/unit/status/scopes/platform.spec.js`, prefer to keep mocks explicitly in tests to increase readability, rather than refactoring them into shared `beforeEach` blocks or helper functions.
packages/js-dash-sdk-original/README.md (2)
Learnt from: shumkov
PR: dashpay/platform#2270
File: packages/dapi/lib/grpcServer/handlers/platform/broadcastStateTransitionHandlerFactory.js:19-19
Timestamp: 2024-10-24T04:58:02.843Z
Learning: For operations involving Tenderdash where no client library exists yet, it's acceptable to use the Node.js built-in `crypto` module.
Learnt from: shumkov
PR: dashpay/platform#2489
File: packages/rs-dpp/Cargo.toml:32-32
Timestamp: 2025-03-11T09:39:23.071Z
Learning: In the Dash Platform project, dependencies are currently managed using Git repository references with tags (repo+tag format in Cargo.toml) rather than published crates, as the team is not currently publishing crates to crates.io.
packages/js-dash-sdk/.gitignore (1)
Learnt from: CR
PR: dashpay/platform#0
File: CLAUDE.md:0-0
Timestamp: 2025-06-24T08:18:22.301Z
Learning: The repository uses a monorepo structure managed by Yarn workspaces, allowing multiple packages (in Rust, JavaScript, and WebAssembly) to be developed and tested together.
packages/wasm-sdk/README.md (1)
Learnt from: lklimek
PR: dashpay/platform#2405
File: packages/wasm-sdk/src/verify.rs:26-68
Timestamp: 2025-02-10T11:26:36.709Z
Learning: In the wasm-sdk package, empty vectors and placeholder values are intentionally used in verification functions during the proof-of-concept stage to ensure proper compilation and type checking.
packages/wasm-sdk/.gitignore (3)
Learnt from: CR
PR: dashpay/platform#0
File: CLAUDE.md:0-0
Timestamp: 2025-06-24T08:18:22.301Z
Learning: The repository uses a monorepo structure managed by Yarn workspaces, allowing multiple packages (in Rust, JavaScript, and WebAssembly) to be developed and tested together.
Learnt from: shumkov
PR: dashpay/platform#2248
File: packages/rs-drive-abci/src/main.rs:106-111
Timestamp: 2024-10-17T08:52:54.300Z
Learning: In this project, the environment variable `CARGO_PKG_RUST_VERSION` is defined and can be used safely with the `env!` macro.
Learnt from: lklimek
PR: dashpay/platform#2030
File: packages/rs-sdk/tests/vectors/test_asset_lock_proof/quorum_pubkey-100-4ce7fd81273c2b394c0f32367374fc5b09ba912e017aacb366d2171e9ca6f9d5.json:1-1
Timestamp: 2024-12-10T10:56:26.215Z
Learning: In the `packages/rs-sdk/tests/vectors/test_asset_lock_proof/` directory, files with the `.json` extension are mock data that may not follow standard JSON format; this is intentional and acceptable within the project's testing framework.
packages/js-dash-sdk-original/tsconfig.json (2)
Learnt from: shumkov
PR: dashpay/platform#2475
File: packages/js-dash-sdk/tsconfig.mocha.json:5-7
Timestamp: 2025-02-19T14:58:40.265Z
Learning: TypeScript configuration files (tsconfig.json) support JSON5 format, which allows trailing commas and comments. The TypeScript compiler (tsc) successfully parses these JSON5 features.
Learnt from: shumkov
PR: dashpay/platform#2475
File: packages/js-dash-sdk/tsconfig.mocha.json:5-7
Timestamp: 2025-02-19T14:58:40.265Z
Learning: TypeScript configuration files (tsconfig.json) use JSONC (JSON with Comments) format, which supports comments and trailing commas, but not full JSON5 features. The TypeScript compiler (tsc) successfully parses these JSONC features.
packages/wasm-drive-verify/tests/contract_tests.rs (8)
Learnt from: lklimek
PR: dashpay/platform#2207
File: packages/rs-drive-proof-verifier/src/proof.rs:1646-1664
Timestamp: 2024-10-04T14:16:05.798Z
Learning: In the implementation of `FromProof<platform::GetContestedResourceIdentityVotesRequest>` in `packages/rs-drive-proof-verifier/src/proof.rs`, when matching `maybe_votes`, using `.expect()` on `v.into_iter().next()` is acceptable because the prior match arm `Some(v) if v.is_empty()` ensures that the map is not empty, preventing a panic.
Learnt from: lklimek
PR: dashpay/platform#2207
File: packages/rs-drive-proof-verifier/src/proof.rs:1646-1664
Timestamp: 2024-10-09T00:22:57.778Z
Learning: In the implementation of `FromProof<platform::GetContestedResourceIdentityVotesRequest>` in `packages/rs-drive-proof-verifier/src/proof.rs`, when matching `maybe_votes`, using `.expect()` on `v.into_iter().next()` is acceptable because the prior match arm `Some(v) if v.is_empty()` ensures that the map is not empty, preventing a panic.
Learnt from: QuantumExplorer
PR: dashpay/platform#2215
File: packages/rs-drive-abci/src/execution/engine/run_block_proposal/mod.rs:105-105
Timestamp: 2024-10-06T16:17:34.571Z
Learning: In `run_block_proposal` in `packages/rs-drive-abci/src/execution/engine/run_block_proposal/mod.rs`, when retrieving `last_block_time_ms`, it's acceptable to use `platform_state` instead of `block_platform_state`, even after updating the protocol version.
Learnt from: QuantumExplorer
PR: dashpay/platform#2215
File: packages/rs-drive-abci/src/execution/engine/run_block_proposal/mod.rs:105-105
Timestamp: 2024-10-09T00:22:57.778Z
Learning: In `run_block_proposal` in `packages/rs-drive-abci/src/execution/engine/run_block_proposal/mod.rs`, when retrieving `last_block_time_ms`, it's acceptable to use `platform_state` instead of `block_platform_state`, even after updating the protocol version.
Learnt from: QuantumExplorer
PR: dashpay/platform#2227
File: packages/rs-drive-abci/src/platform_types/platform_state/mod.rs:141-141
Timestamp: 2024-10-08T13:28:03.529Z
Learning: When converting `PlatformStateV0` to `PlatformStateForSavingV1` in `packages/rs-drive-abci/src/platform_types/platform_state/mod.rs`, only version `0` needs to be handled in the match on `platform_state_for_saving_structure_default` because the changes are retroactive.
Learnt from: QuantumExplorer
PR: dashpay/platform#2182
File: packages/strategy-tests/src/transitions.rs:182-247
Timestamp: 2024-09-29T09:34:16.953Z
Learning: In test code, input validation in functions like `instant_asset_lock_proof_transaction_fixture_with_dynamic_amount` is not required.
Learnt from: QuantumExplorer
PR: dashpay/platform#2182
File: packages/strategy-tests/src/transitions.rs:182-247
Timestamp: 2024-10-09T00:22:57.778Z
Learning: In test code, input validation in functions like `instant_asset_lock_proof_transaction_fixture_with_dynamic_amount` is not required.
Learnt from: QuantumExplorer
PR: dashpay/platform#2215
File: packages/rs-drive-abci/src/execution/engine/run_block_proposal/mod.rs:119-120
Timestamp: 2024-10-06T16:18:07.994Z
Learning: In the `run_block_proposal` function in `packages/rs-drive-abci/src/execution/engine/run_block_proposal/mod.rs`, it's acceptable to pass `platform_state` to `perform_events_on_first_block_of_protocol_change`, even if `block_platform_state` has been updated.
packages/wasm-sdk/TODO_SUMMARY.md (1)
Learnt from: lklimek
PR: dashpay/platform#2405
File: packages/wasm-sdk/src/verify.rs:26-68
Timestamp: 2025-02-10T11:26:36.709Z
Learning: In the wasm-sdk package, empty vectors and placeholder values are intentionally used in verification functions during the proof-of-concept stage to ensure proper compilation and type checking.
packages/wasm-sdk/PROOF_VERIFICATION_STATUS.md (6)
Learnt from: lklimek
PR: dashpay/platform#2405
File: packages/wasm-sdk/src/verify.rs:26-68
Timestamp: 2025-02-10T11:26:36.709Z
Learning: In the wasm-sdk package, empty vectors and placeholder values are intentionally used in verification functions during the proof-of-concept stage to ensure proper compilation and type checking.
Learnt from: CR
PR: dashpay/platform#0
File: CLAUDE.md:0-0
Timestamp: 2025-06-24T08:18:22.301Z
Learning: Cryptographic proof verification is handled by the rs-drive-proof-verifier package, ensuring data integrity and authenticity.
Learnt from: QuantumExplorer
PR: dashpay/platform#2332
File: packages/rs-drive-proof-verifier/src/error.rs:21-23
Timestamp: 2024-11-15T14:39:23.704Z
Learning: In the `packages/rs-drive-proof-verifier`, avoid suggesting size limits for `proof_bytes` in errors unless there's a specific need, as it may not be necessary.
Learnt from: QuantumExplorer
PR: dashpay/platform#2644
File: packages/rs-drive/src/cache/system_contracts.rs:18-19
Timestamp: 2025-05-28T16:22:26.334Z
Learning: In packages/rs-drive/src/cache/system_contracts.rs, the `active_since_protocol_version` field in `ActiveSystemDataContract` struct is intentionally added for future use, not current implementation. QuantumExplorer confirmed this is "meant for later" when questioned about the `#[allow(unused)]` attribute.
Learnt from: QuantumExplorer
PR: dashpay/platform#2439
File: packages/rs-dpp/src/errors/consensus/state/token/mod.rs:4-22
Timestamp: 2025-01-23T02:10:08.979Z
Learning: The user QuantumExplorer prefers to handle documentation of breaking changes separately from the code changes, particularly for token-related error types and validation rules.
Learnt from: QuantumExplorer
PR: dashpay/platform#2257
File: packages/rs-drive-abci/src/platform_types/signature_verification_quorum_set/v0/for_saving.rs:148-151
Timestamp: 2024-11-20T16:05:40.200Z
Learning: In `packages/rs-drive-abci/src/platform_types/signature_verification_quorum_set/v0/for_saving.rs`, when converting public keys from `QuorumForSavingV0` to `VerificationQuorum`, it's acceptable to use `.expect()` for public key conversion, as the conversion has been verified and panics are acceptable in this context.
packages/wasm-sdk/SECURITY.md (2)
Learnt from: lklimek
PR: dashpay/platform#2405
File: packages/wasm-sdk/src/verify.rs:26-68
Timestamp: 2025-02-10T11:26:36.709Z
Learning: In the wasm-sdk package, empty vectors and placeholder values are intentionally used in verification functions during the proof-of-concept stage to ensure proper compilation and type checking.
Learnt from: QuantumExplorer
PR: dashpay/platform#2439
File: packages/rs-dpp/src/errors/consensus/state/token/mod.rs:4-22
Timestamp: 2025-01-23T02:10:08.979Z
Learning: The user QuantumExplorer prefers to handle documentation of breaking changes separately from the code changes, particularly for token-related error types and validation rules.
packages/js-dash-sdk/rollup.config.js (1)
Learnt from: CR
PR: dashpay/platform#0
File: CLAUDE.md:0-0
Timestamp: 2025-06-24T08:18:22.301Z
Learning: The repository uses a monorepo structure managed by Yarn workspaces, allowing multiple packages (in Rust, JavaScript, and WebAssembly) to be developed and tested together.
packages/wasm-sdk/Cargo.deny.toml (8)
Learnt from: shumkov
PR: dashpay/platform#2375
File: packages/rs-drive-abci/Cargo.toml:61-63
Timestamp: 2024-12-05T09:29:38.918Z
Learning: In the `drive-abci` package, avoid adding unused dependencies like `hashbrown` to `Cargo.toml`. The team relies on CI to detect dependency version issues.
Learnt from: lklimek
PR: dashpay/platform#2277
File: packages/rs-dapi-client/Cargo.toml:22-22
Timestamp: 2024-10-29T10:42:00.521Z
Learning: In `packages/rs-dapi-client/Cargo.toml`, `backon` will not work without the `tokio-sleep` feature in our setup, so it's unnecessary to declare `tokio-sleep` as a separate feature in the `[features]` section.
Learnt from: shumkov
PR: dashpay/platform#2248
File: packages/rs-drive-abci/src/main.rs:106-111
Timestamp: 2024-10-17T08:52:54.300Z
Learning: In this project, the environment variable `CARGO_PKG_RUST_VERSION` is defined and can be used safely with the `env!` macro.
Learnt from: CR
PR: dashpay/platform#0
File: CLAUDE.md:0-0
Timestamp: 2025-06-24T08:18:22.301Z
Learning: The repository uses a monorepo structure managed by Yarn workspaces, allowing multiple packages (in Rust, JavaScript, and WebAssembly) to be developed and tested together.
Learnt from: QuantumExplorer
PR: dashpay/platform#2431
File: packages/rs-drive/Cargo.toml:55-60
Timestamp: 2025-01-19T07:36:46.042Z
Learning: The grovedb dependencies in packages/rs-drive/Cargo.toml and related files are intentionally kept at specific revisions rather than using the latest stable version, with plans to update them at a later time.
Learnt from: lklimek
PR: dashpay/platform#2405
File: packages/rs-sdk/src/sync.rs:88-95
Timestamp: 2025-01-23T09:23:32.740Z
Learning: The `block_on` function in `packages/rs-sdk/src/sync.rs` is currently only used in tests, and its WebAssembly implementation is deferred until there's a user request for it.
Learnt from: shumkov
PR: dashpay/platform#2489
File: packages/rs-dpp/Cargo.toml:32-32
Timestamp: 2025-03-11T09:39:23.071Z
Learning: In the Dash Platform project, dependencies are currently managed using Git repository references with tags (repo+tag format in Cargo.toml) rather than published crates, as the team is not currently publishing crates to crates.io.
Learnt from: lklimek
PR: dashpay/platform#2254
File: packages/rs-sdk/src/sdk.rs:585-585
Timestamp: 2024-10-18T15:39:51.172Z
Learning: The 'platform' project uses Rust version 1.80, so code in 'packages/rs-sdk' can use features available in Rust 1.80, such as the `abs_diff()` method.
packages/js-dash-sdk/tsconfig.json (4)
Learnt from: shumkov
PR: dashpay/platform#2475
File: packages/js-dash-sdk/tsconfig.mocha.json:5-7
Timestamp: 2025-02-19T14:58:40.265Z
Learning: TypeScript configuration files (tsconfig.json) support JSON5 format, which allows trailing commas and comments. The TypeScript compiler (tsc) successfully parses these JSON5 features.
Learnt from: shumkov
PR: dashpay/platform#2475
File: packages/js-dash-sdk/tsconfig.mocha.json:5-7
Timestamp: 2025-02-19T14:58:40.265Z
Learning: TypeScript configuration files (tsconfig.json) use JSONC (JSON with Comments) format, which supports comments and trailing commas, but not full JSON5 features. The TypeScript compiler (tsc) successfully parses these JSONC features.
Learnt from: shumkov
PR: dashpay/platform#2365
File: packages/dashmate/src/listr/tasks/ssl/VerificationServer.js:6-6
Timestamp: 2024-12-03T05:49:08.409Z
Learning: The project requires Node.js version 20 or higher, so features available from Node.js 20 onwards can be used without concern for backward compatibility.
Learnt from: CR
PR: dashpay/platform#0
File: CLAUDE.md:0-0
Timestamp: 2025-06-24T08:18:22.301Z
Learning: The repository uses a monorepo structure managed by Yarn workspaces, allowing multiple packages (in Rust, JavaScript, and WebAssembly) to be developed and tested together.
packages/js-dash-sdk/tests/bluetooth/security.test.ts (3)
Learnt from: shumkov
PR: dashpay/platform#2249
File: packages/dashmate/test/unit/status/scopes/platform.spec.js:466-467
Timestamp: 2024-10-18T15:37:21.329Z
Learning: In test files for the dashmate project, such as `packages/dashmate/test/unit/status/scopes/platform.spec.js`, prefer to keep mocks explicitly in tests rather than consolidating them, to increase readability.
Learnt from: shumkov
PR: dashpay/platform#2249
File: packages/dashmate/test/unit/status/scopes/platform.spec.js:77-78
Timestamp: 2024-10-18T15:37:36.387Z
Learning: In `packages/dashmate/test/unit/status/scopes/platform.spec.js`, prefer to keep mocks explicitly in tests to increase readability, rather than refactoring them into shared `beforeEach` blocks or helper functions.
Learnt from: CR
PR: dashpay/platform#0
File: CLAUDE.md:0-0
Timestamp: 2025-06-24T08:18:22.301Z
Learning: Testing is comprehensive and includes unit, integration, and end-to-end (e2e) test suites.
packages/js-dash-sdk/tests/providers/WebServiceProvider.test.ts (3)
Learnt from: shumkov
PR: dashpay/platform#2249
File: packages/dashmate/test/unit/status/scopes/platform.spec.js:77-78
Timestamp: 2024-10-18T15:37:36.387Z
Learning: In `packages/dashmate/test/unit/status/scopes/platform.spec.js`, prefer to keep mocks explicitly in tests to increase readability, rather than refactoring them into shared `beforeEach` blocks or helper functions.
Learnt from: shumkov
PR: dashpay/platform#2249
File: packages/dashmate/test/unit/status/scopes/platform.spec.js:466-467
Timestamp: 2024-10-18T15:37:21.329Z
Learning: In test files for the dashmate project, such as `packages/dashmate/test/unit/status/scopes/platform.spec.js`, prefer to keep mocks explicitly in tests rather than consolidating them, to increase readability.
Learnt from: CR
PR: dashpay/platform#0
File: CLAUDE.md:0-0
Timestamp: 2025-06-24T08:18:22.301Z
Learning: Testing is comprehensive and includes unit, integration, and end-to-end (e2e) test suites.
packages/js-dash-sdk-original/.eslintrc.js (1)
Learnt from: shumkov
PR: dashpay/platform#2249
File: packages/dashmate/test/unit/status/scopes/platform.spec.js:466-467
Timestamp: 2024-10-18T15:37:21.329Z
Learning: In test files for the dashmate project, such as `packages/dashmate/test/unit/status/scopes/platform.spec.js`, prefer to keep mocks explicitly in tests rather than consolidating them, to increase readability.
packages/js-dash-sdk/src/modules/wallet/types.ts (1)
Learnt from: shumkov
PR: dashpay/platform#2345
File: packages/wallet-utils-contract/schema/v1/wallet-utils-contract-documents.json:49-55
Timestamp: 2024-11-25T07:49:05.419Z
Learning: In the schema definitions for the `wallet-utils-contract` (file `packages/wallet-utils-contract/schema/v1/wallet-utils-contract-documents.json`), the `$createdAt` field is a system field augmented by DPP and does not need to be defined explicitly in the schema's properties.
packages/js-dash-sdk/src/utils/errors.ts (1)
Learnt from: QuantumExplorer
PR: dashpay/platform#2439
File: packages/rs-dpp/src/errors/consensus/state/token/mod.rs:4-22
Timestamp: 2025-01-23T02:10:08.979Z
Learning: The user QuantumExplorer prefers to handle documentation of breaking changes separately from the code changes, particularly for token-related error types and validation rules.
packages/wasm-sdk/docs/MIGRATION_GUIDE.md (4)
Learnt from: QuantumExplorer
PR: dashpay/platform#2439
File: packages/rs-dpp/src/errors/consensus/state/token/mod.rs:4-22
Timestamp: 2025-01-23T02:10:08.979Z
Learning: The user QuantumExplorer prefers to handle documentation of breaking changes separately from the code changes, particularly for token-related error types and validation rules.
Learnt from: lklimek
PR: dashpay/platform#2405
File: packages/wasm-sdk/src/verify.rs:26-68
Timestamp: 2025-02-10T11:26:36.709Z
Learning: In the wasm-sdk package, empty vectors and placeholder values are intentionally used in verification functions during the proof-of-concept stage to ensure proper compilation and type checking.
Learnt from: shumkov
PR: dashpay/platform#2270
File: packages/dapi/lib/grpcServer/handlers/platform/broadcastStateTransitionHandlerFactory.js:19-19
Timestamp: 2024-10-24T04:58:02.843Z
Learning: For operations involving Tenderdash where no client library exists yet, it's acceptable to use the Node.js built-in `crypto` module.
Learnt from: shumkov
PR: dashpay/platform#2314
File: packages/wallet-contract/test/bootstrap.js:14-16
Timestamp: 2024-11-06T07:27:01.722Z
Learning: In `packages/wallet-contract/test/bootstrap.js`, for Mocha tests in Node.js, async functions like `loadWasmDpp` can be assigned directly to `beforeAll` without wrapping them in another async function.
packages/js-dash-sdk/examples/read-only-usage.ts (2)
Learnt from: lklimek
PR: dashpay/platform#2381
File: packages/rs-sdk/scripts/connect_to_remote.sh:0-0
Timestamp: 2024-12-10T12:39:38.182Z
Learning: When reviewing scripts in `packages/rs-sdk/scripts/`, avoid suggesting additional error handling and timeout management that complicate the script without adding significant value.
Learnt from: shumkov
PR: dashpay/platform#2249
File: packages/dashmate/test/unit/status/scopes/platform.spec.js:466-467
Timestamp: 2024-10-18T15:37:21.329Z
Learning: In test files for the dashmate project, such as `packages/dashmate/test/unit/status/scopes/platform.spec.js`, prefer to keep mocks explicitly in tests rather than consolidating them, to increase readability.
packages/js-dash-sdk/src/core/WasmLoader.ts (4)
Learnt from: shumkov
PR: dashpay/platform#2314
File: packages/wallet-contract/test/bootstrap.js:14-16
Timestamp: 2024-11-06T07:27:01.722Z
Learning: In `packages/wallet-contract/test/bootstrap.js`, for Mocha tests in Node.js, async functions like `loadWasmDpp` can be assigned directly to `beforeAll` without wrapping them in another async function.
Learnt from: lklimek
PR: dashpay/platform#2232
File: packages/rs-sdk/src/mock/sdk.rs:90-95
Timestamp: 2024-10-10T10:30:19.883Z
Learning: In `packages/rs-sdk/src/mock/sdk.rs`, the `load_expectations` method in `MockDashPlatformSdk` remains asynchronous (`async`) for backward compatibility, even though it now delegates to the synchronous `load_expectations_sync` method.
Learnt from: CR
PR: dashpay/platform#0
File: CLAUDE.md:0-0
Timestamp: 2025-06-24T08:18:22.301Z
Learning: Cross-language integration is achieved using WebAssembly (WASM) bindings to connect Rust and JavaScript codebases.
Learnt from: lklimek
PR: dashpay/platform#2405
File: packages/wasm-sdk/src/verify.rs:26-68
Timestamp: 2025-02-10T11:26:36.709Z
Learning: In the wasm-sdk package, empty vectors and placeholder values are intentionally used in verification functions during the proof-of-concept stage to ensure proper compilation and type checking.
packages/wasm-sdk/OPTIMIZATION_GUIDE.md (3)
Learnt from: lklimek
PR: dashpay/platform#2405
File: packages/wasm-sdk/src/verify.rs:26-68
Timestamp: 2025-02-10T11:26:36.709Z
Learning: In the wasm-sdk package, empty vectors and placeholder values are intentionally used in verification functions during the proof-of-concept stage to ensure proper compilation and type checking.
Learnt from: lklimek
PR: dashpay/platform#2405
File: packages/wasm-sdk/src/lib.rs:13-17
Timestamp: 2025-01-23T09:43:25.080Z
Learning: The codebase uses tracing_wasm for WebAssembly tracing as it provides sufficient functionality for the project's needs.
Learnt from: CR
PR: dashpay/platform#0
File: CLAUDE.md:0-0
Timestamp: 2025-06-24T08:18:22.301Z
Learning: Cross-language integration is achieved using WebAssembly (WASM) bindings to connect Rust and JavaScript codebases.
packages/js-dash-sdk/examples/read-only-website.html (1)
Learnt from: shumkov
PR: dashpay/platform#2255
File: packages/dashmate/src/status/scopes/platform.js:112-116
Timestamp: 2024-10-19T06:10:00.808Z
Learning: In the Dashmate project, when fetching from Tenderdash RPC endpoints like `/status`, `/net_info`, and `/abci_info`, if one request fails, it's likely that the others will fail as well, so individual error handling for each fetch may not be necessary.
packages/wasm-sdk/IMPLEMENTATION_SUMMARY.md (2)
Learnt from: CR
PR: dashpay/platform#0
File: CLAUDE.md:0-0
Timestamp: 2025-06-24T08:18:22.301Z
Learning: Cross-language integration is achieved using WebAssembly (WASM) bindings to connect Rust and JavaScript codebases.
Learnt from: lklimek
PR: dashpay/platform#2405
File: packages/wasm-sdk/src/verify.rs:26-68
Timestamp: 2025-02-10T11:26:36.709Z
Learning: In the wasm-sdk package, empty vectors and placeholder values are intentionally used in verification functions during the proof-of-concept stage to ensure proper compilation and type checking.
packages/js-dash-sdk/src/bluetooth/README.md (1)
Learnt from: shumkov
PR: dashpay/platform#2270
File: packages/dapi/lib/grpcServer/handlers/platform/broadcastStateTransitionHandlerFactory.js:19-19
Timestamp: 2024-10-24T04:58:02.843Z
Learning: For operations involving Tenderdash where no client library exists yet, it's acceptable to use the Node.js built-in `crypto` module.
packages/js-dash-sdk/examples/bluetooth-secure-pairing.ts (2)
Learnt from: lklimek
PR: dashpay/platform#2381
File: packages/rs-sdk/scripts/connect_to_remote.sh:0-0
Timestamp: 2024-12-10T12:39:38.182Z
Learning: When reviewing scripts in `packages/rs-sdk/scripts/`, avoid suggesting additional error handling and timeout management that complicate the script without adding significant value.
Learnt from: shumkov
PR: dashpay/platform#2270
File: packages/dapi/lib/grpcServer/handlers/platform/broadcastStateTransitionHandlerFactory.js:19-19
Timestamp: 2024-10-24T04:58:02.843Z
Learning: For operations involving Tenderdash where no client library exists yet, it's acceptable to use the Node.js built-in `crypto` module.
packages/js-dash-sdk/README.md (3)
Learnt from: QuantumExplorer
PR: dashpay/platform#2439
File: packages/rs-dpp/src/errors/consensus/state/token/mod.rs:4-22
Timestamp: 2025-01-23T02:10:08.979Z
Learning: The user QuantumExplorer prefers to handle documentation of breaking changes separately from the code changes, particularly for token-related error types and validation rules.
Learnt from: shumkov
PR: dashpay/platform#2206
File: packages/rs-platform-version/src/version/protocol_version.rs:155-157
Timestamp: 2024-10-04T09:08:48.470Z
Learning: In the dashmate default configurations, the default protocol version for local networks has been removed, and an update mechanism for the protocol version in the consensus parameters has been implemented.
Learnt from: shumkov
PR: dashpay/platform#2206
File: packages/rs-platform-version/src/version/protocol_version.rs:155-157
Timestamp: 2024-10-09T00:22:57.778Z
Learning: In the dashmate default configurations, the default protocol version for local networks has been removed, and an update mechanism for the protocol version in the consensus parameters has been implemented.
packages/js-dash-sdk/tests/providers/PriorityContextProvider.test.ts (2)
Learnt from: shumkov
PR: dashpay/platform#2249
File: packages/dashmate/test/unit/status/scopes/platform.spec.js:466-467
Timestamp: 2024-10-18T15:37:21.329Z
Learning: In test files for the dashmate project, such as `packages/dashmate/test/unit/status/scopes/platform.spec.js`, prefer to keep mocks explicitly in tests rather than consolidating them, to increase readability.
Learnt from: shumkov
PR: dashpay/platform#2249
File: packages/dashmate/test/unit/status/scopes/platform.spec.js:77-78
Timestamp: 2024-10-18T15:37:36.387Z
Learning: In `packages/dashmate/test/unit/status/scopes/platform.spec.js`, prefer to keep mocks explicitly in tests to increase readability, rather than refactoring them into shared `beforeEach` blocks or helper functions.
packages/wasm-sdk/TODO_ANALYSIS.md (7)
Learnt from: lklimek
PR: dashpay/platform#2277
File: packages/rs-sdk/src/core/transaction.rs:0-0
Timestamp: 2024-10-29T14:40:54.727Z
Learning: In `packages/rs-sdk/src/platform/document_query.rs` and `packages/rs-sdk/src/core/transaction.rs`, certain places don't implement `IntoInner`, so direct error mappings cannot be simplified using `IntoInner`. A TODO comment has been added to address this in a future PR.
Learnt from: shumkov
PR: dashpay/platform#2259
File: packages/rs-dapi-client/src/address_list.rs:217-217
Timestamp: 2024-10-28T10:33:49.019Z
Learning: Addressing TODO comments in code may be considered out of scope for this project.
Learnt from: shumkov
PR: dashpay/platform#2182
File: packages/rs-platform-version/src/version/drive_abci_versions.rs:116-121
Timestamp: 2024-09-29T13:13:54.230Z
Learning: Adding Rust doc comments to structs and fields is recommended to enhance clarity and documentation.
Learnt from: lklimek
PR: dashpay/platform#2405
File: packages/wasm-sdk/src/verify.rs:26-68
Timestamp: 2025-02-10T11:26:36.709Z
Learning: In the wasm-sdk package, empty vectors and placeholder values are intentionally used in verification functions during the proof-of-concept stage to ensure proper compilation and type checking.
Learnt from: QuantumExplorer
PR: dashpay/platform#2439
File: packages/rs-dpp/src/errors/consensus/state/token/mod.rs:4-22
Timestamp: 2025-01-23T02:10:08.979Z
Learning: The user QuantumExplorer prefers to handle documentation of breaking changes separately from the code changes, particularly for token-related error types and validation rules.
Learnt from: lklimek
PR: dashpay/platform#2405
File: packages/rs-sdk/src/sync.rs:88-95
Timestamp: 2025-01-23T09:23:32.740Z
Learning: The `block_on` function in `packages/rs-sdk/src/sync.rs` is currently only used in tests, and its WebAssembly implementation is deferred until there's a user request for it.
Learnt from: lklimek
PR: dashpay/platform#2232
File: packages/rs-sdk/src/mock/sdk.rs:90-95
Timestamp: 2024-10-10T10:30:19.883Z
Learning: In `packages/rs-sdk/src/mock/sdk.rs`, the `load_expectations` method in `MockDashPlatformSdk` remains asynchronous (`async`) for backward compatibility, even though it now delegates to the synchronous `load_expectations_sync` method.
packages/wasm-sdk/build-optimized.sh (7)
Learnt from: CR
PR: dashpay/platform#0
File: CLAUDE.md:0-0
Timestamp: 2025-06-24T08:18:22.301Z
Learning: Cross-language integration is achieved using WebAssembly (WASM) bindings to connect Rust and JavaScript codebases.
Learnt from: lklimek
PR: dashpay/platform#2318
File: Dockerfile:0-0
Timestamp: 2024-11-13T10:31:39.746Z
Learning: In the `Dockerfile`, when building the RocksDB static library, the command `make static_lib` compiles in release mode with optimizations enabled by default, so additional optimization flags are unnecessary.
Learnt from: lklimek
PR: dashpay/platform#2254
File: packages/rs-sdk/src/sdk.rs:585-585
Timestamp: 2024-10-18T15:39:51.172Z
Learning: The 'platform' project uses Rust version 1.80, so code in 'packages/rs-sdk' can use features available in Rust 1.80, such as the `abs_diff()` method.
Learnt from: lklimek
PR: dashpay/platform#2405
File: packages/wasm-sdk/src/verify.rs:26-68
Timestamp: 2025-02-10T11:26:36.709Z
Learning: In the wasm-sdk package, empty vectors and placeholder values are intentionally used in verification functions during the proof-of-concept stage to ensure proper compilation and type checking.
Learnt from: CR
PR: dashpay/platform#0
File: CLAUDE.md:0-0
Timestamp: 2025-06-24T08:18:22.301Z
Learning: The repository uses a monorepo structure managed by Yarn workspaces, allowing multiple packages (in Rust, JavaScript, and WebAssembly) to be developed and tested together.
Learnt from: lklimek
PR: dashpay/platform#2381
File: packages/rs-sdk/scripts/connect_to_remote.sh:0-0
Timestamp: 2024-12-10T12:39:38.182Z
Learning: When reviewing scripts in `packages/rs-sdk/scripts/`, avoid suggesting additional error handling and timeout management that complicate the script without adding significant value.
Learnt from: lklimek
PR: dashpay/platform#2405
File: packages/wasm-sdk/src/lib.rs:13-17
Timestamp: 2025-01-23T09:43:25.080Z
Learning: The codebase uses tracing_wasm for WebAssembly tracing as it provides sufficient functionality for the project's needs.
packages/js-dash-sdk/examples/webservice-quorum.ts (1)
Learnt from: lklimek
PR: dashpay/platform#2381
File: packages/rs-sdk/scripts/connect_to_remote.sh:0-0
Timestamp: 2024-12-10T12:39:38.182Z
Learning: When reviewing scripts in `packages/rs-sdk/scripts/`, avoid suggesting additional error handling and timeout management that complicate the script without adding significant value.
packages/wasm-sdk/.github/workflows/ci.yml (5)
Learnt from: CR
PR: dashpay/platform#0
File: CLAUDE.md:0-0
Timestamp: 2025-06-24T08:18:22.301Z
Learning: The repository uses a monorepo structure managed by Yarn workspaces, allowing multiple packages (in Rust, JavaScript, and WebAssembly) to be developed and tested together.
Learnt from: lklimek
PR: dashpay/platform#2344
File: .github/workflows/release-docker-image.yml:66-70
Timestamp: 2024-11-25T12:59:11.416Z
Learning: In the CI workflows (e.g., `.github/workflows/release-docker-image.yml` and `tests-build-image.yml`), we do not add validation steps for cache configuration variables. We rely on the build process to quickly reveal any misconfigurations.
Learnt from: CR
PR: dashpay/platform#0
File: CLAUDE.md:0-0
Timestamp: 2025-06-24T08:18:22.301Z
Learning: Cross-language integration is achieved using WebAssembly (WASM) bindings to connect Rust and JavaScript codebases.
Learnt from: lklimek
PR: dashpay/platform#2318
File: .github/workflows/tests-build-image.yml:45-45
Timestamp: 2024-11-13T10:31:30.891Z
Learning: In the dashpay/platform repository, changes to `.github/workflows/tests-build-image.yml` that switch the Docker image platform from `linux/arm64` to `linux/amd64` for testing purposes are acceptable when required to run on GitHub-hosted runners. ARM64 testing is covered on the testnet.
Learnt from: lklimek
PR: dashpay/platform#2405
File: packages/wasm-sdk/src/verify.rs:26-68
Timestamp: 2025-02-10T11:26:36.709Z
Learning: In the wasm-sdk package, empty vectors and placeholder values are intentionally used in verification functions during the proof-of-concept stage to ensure proper compilation and type checking.
packages/js-dash-sdk/src/modules/contracts/ContractModule.ts (2)
Learnt from: CR
PR: dashpay/platform#0
File: CLAUDE.md:0-0
Timestamp: 2025-06-24T08:18:22.301Z
Learning: Platform data contracts define application data schemas for core features such as naming services, social payments, feature flags, masternode reward shares, and withdrawals.
Learnt from: CR
PR: dashpay/platform#0
File: CLAUDE.md:0-0
Timestamp: 2025-06-24T08:18:22.301Z
Learning: Documents and data contracts on the platform use state transitions for updates, supporting robust and auditable data changes.
packages/js-dash-sdk/src/modules/identities/types.ts (3)
Learnt from: shumkov
PR: dashpay/platform#2201
File: packages/rs-platform-version/src/version/v2.rs:1186-1188
Timestamp: 2024-10-03T11:51:06.980Z
Learning: In the `IdentityTransitionVersions` structure within `packages/rs-platform-version/src/version/v2.rs`, the field `credit_withdrawal` does not need the `identity_` prefix since it is already encompassed within identity state transitions.
Learnt from: shumkov
PR: dashpay/platform#2201
File: packages/rs-platform-version/src/version/v2.rs:1186-1188
Timestamp: 2024-10-09T00:22:57.778Z
Learning: In the `IdentityTransitionVersions` structure within `packages/rs-platform-version/src/version/v2.rs`, the field `credit_withdrawal` does not need the `identity_` prefix since it is already encompassed within identity state transitions.
Learnt from: CR
PR: dashpay/platform#0
File: CLAUDE.md:0-0
Timestamp: 2025-06-24T08:18:22.301Z
Learning: Platform data contracts define application data schemas for core features such as naming services, social payments, feature flags, masternode reward shares, and withdrawals.
packages/js-dash-sdk/examples/priority-providers.ts (1)
Learnt from: lklimek
PR: dashpay/platform#2381
File: packages/rs-sdk/scripts/connect_to_remote.sh:0-0
Timestamp: 2024-12-10T12:39:38.182Z
Learning: When reviewing scripts in `packages/rs-sdk/scripts/`, avoid suggesting additional error handling and timeout management that complicate the script without adding significant value.
packages/js-dash-sdk/src/core/StateTransitionBroadcaster.ts (4)
Learnt from: shumkov
PR: dashpay/platform#2270
File: packages/dapi/lib/grpcServer/handlers/platform/broadcastStateTransitionHandlerFactory.js:90-96
Timestamp: 2024-10-24T05:01:51.097Z
Learning: In `broadcastStateTransitionHandlerFactory.js`, error handling when querying transaction status is handled in the API script.
Learnt from: shumkov
PR: dashpay/platform#2270
File: packages/dapi/lib/grpcServer/handlers/platform/broadcastStateTransitionHandlerFactory.js:83-85
Timestamp: 2024-10-24T05:00:56.657Z
Learning: An upcoming filter will be introduced to the `unconfirmed_txs` endpoint in `broadcastStateTransitionHandlerFactory.js`, as noted in the TODO comment. Therefore, optimizing transaction existence checks may not be necessary at this time.
Learnt from: shumkov
PR: dashpay/platform#2270
File: packages/dapi/lib/grpcServer/handlers/platform/broadcastStateTransitionHandlerFactory.js:81-85
Timestamp: 2024-10-24T04:59:50.270Z
Learning: In `packages/dapi/lib/grpcServer/handlers/platform/broadcastStateTransitionHandlerFactory.js`, the code fetching unconfirmed transactions with a limit of 100 is temporary and will be replaced when a filter for transactions is available.
Learnt from: shumkov
PR: dashpay/platform#2270
File: packages/dapi/lib/grpcServer/handlers/platform/broadcastStateTransitionHandlerFactory.js:75-77
Timestamp: 2024-10-24T04:59:20.436Z
Learning: Tenderdash's `tx` RPC method accepts transaction hashes in base64 encoding, or in hex encoding if prefixed with `0x`. Therefore, in `packages/dapi/lib/grpcServer/handlers/platform/broadcastStateTransitionHandlerFactory.js`, it's acceptable to use `stHash.toString('base64')` when calling `requestTenderRpc('tx', { hash: stHash.toString('base64') })`.
packages/wasm-sdk/Makefile (1)
Learnt from: CR
PR: dashpay/platform#0
File: CLAUDE.md:0-0
Timestamp: 2025-06-24T08:18:22.301Z
Learning: The repository uses a monorepo structure managed by Yarn workspaces, allowing multiple packages (in Rust, JavaScript, and WebAssembly) to be developed and tested together.
packages/js-dash-sdk/.eslintrc.js (2)
Learnt from: lklimek
PR: dashpay/platform#2381
File: packages/rs-sdk/scripts/connect_to_remote.sh:0-0
Timestamp: 2024-12-10T12:39:38.182Z
Learning: When reviewing scripts in `packages/rs-sdk/scripts/`, avoid suggesting additional error handling and timeout management that complicate the script without adding significant value.
Learnt from: shumkov
PR: dashpay/platform#2475
File: packages/js-dash-sdk/tsconfig.mocha.json:5-7
Timestamp: 2025-02-19T14:58:40.265Z
Learning: TypeScript configuration files (tsconfig.json) support JSON5 format, which allows trailing commas and comments. The TypeScript compiler (tsc) successfully parses these JSON5 features.
packages/wasm-sdk/examples/identity-creation-example.js (5)
Learnt from: lklimek
PR: dashpay/platform#2277
File: packages/rs-sdk/tests/fetch/config.rs:233-233
Timestamp: 2024-10-30T11:19:59.163Z
Learning: In the Rust SDK's `rs-sdk/tests` integration tests (e.g., in `packages/rs-sdk/tests/fetch/config.rs`), we cannot create objects during tests because there is no support for object creation in this context. Therefore, hardcoded values for test identities must be used.
Learnt from: lklimek
PR: dashpay/platform#2405
File: packages/wasm-sdk/src/verify.rs:26-68
Timestamp: 2025-02-10T11:26:36.709Z
Learning: In the wasm-sdk package, empty vectors and placeholder values are intentionally used in verification functions during the proof-of-concept stage to ensure proper compilation and type checking.
Learnt from: shumkov
PR: dashpay/platform#2314
File: packages/wallet-contract/test/bootstrap.js:14-16
Timestamp: 2024-11-06T07:27:01.722Z
Learning: In `packages/wallet-contract/test/bootstrap.js`, for Mocha tests in Node.js, async functions like `loadWasmDpp` can be assigned directly to `beforeAll` without wrapping them in another async function.
Learnt from: QuantumExplorer
PR: dashpay/platform#2215
File: packages/rs-drive-abci/src/execution/platform_events/core_based_updates/update_masternode_identities/create_owner_identity/v1/mod.rs:19-30
Timestamp: 2024-10-06T16:11:34.946Z
Learning: In the Rust file `packages/rs-drive-abci/src/execution/platform_events/core_based_updates/update_masternode_identities/create_owner_identity/v1/mod.rs`, within the `create_owner_identity_v1` function, the `add_public_keys` method of the `Identity` struct cannot fail and does not require explicit error handling.
Learnt from: QuantumExplorer
PR: dashpay/platform#2215
File: packages/rs-drive-abci/src/execution/platform_events/core_based_updates/update_masternode_identities/create_owner_identity/v1/mod.rs:19-30
Timestamp: 2024-10-09T00:22:57.778Z
Learning: In the Rust file `packages/rs-drive-abci/src/execution/platform_events/core_based_updates/update_masternode_identities/create_owner_identity/v1/mod.rs`, within the `create_owner_identity_v1` function, the `add_public_keys` method of the `Identity` struct cannot fail and does not require explicit error handling.
packages/wasm-sdk/examples/bls-signatures-example.js (5)
Learnt from: lklimek
PR: dashpay/platform#2405
File: packages/wasm-sdk/src/verify.rs:26-68
Timestamp: 2025-02-10T11:26:36.709Z
Learning: In the wasm-sdk package, empty vectors and placeholder values are intentionally used in verification functions during the proof-of-concept stage to ensure proper compilation and type checking.
Learnt from: QuantumExplorer
PR: dashpay/platform#2227
File: packages/rs-dpp/src/core_types/validator_set/v0/mod.rs:299-299
Timestamp: 2024-10-21T01:03:42.458Z
Learning: In the `test_serialize_deserialize_validator_set_v0` test within `packages/rs-dpp/src/core_types/validator_set/v0/mod.rs`, deterministic BLS keys cannot be easily used; therefore, using `BlsPublicKey::generate()` is acceptable.
Learnt from: shumkov
PR: dashpay/platform#2314
File: packages/wallet-contract/test/bootstrap.js:14-16
Timestamp: 2024-11-06T07:27:01.722Z
Learning: In `packages/wallet-contract/test/bootstrap.js`, for Mocha tests in Node.js, async functions like `loadWasmDpp` can be assigned directly to `beforeAll` without wrapping them in another async function.
Learnt from: CR
PR: dashpay/platform#0
File: CLAUDE.md:0-0
Timestamp: 2025-06-24T08:18:22.301Z
Learning: Cross-language integration is achieved using WebAssembly (WASM) bindings to connect Rust and JavaScript codebases.
Learnt from: lklimek
PR: dashpay/platform#2405
File: packages/rs-sdk/src/sync.rs:88-95
Timestamp: 2025-01-23T09:23:32.740Z
Learning: The `block_on` function in `packages/rs-sdk/src/sync.rs` is currently only used in tests, and its WebAssembly implementation is deferred until there's a user request for it.
packages/wasm-sdk/examples/contract-cache-example.js (2)
Learnt from: shumkov
PR: dashpay/platform#2314
File: packages/wallet-contract/test/bootstrap.js:14-16
Timestamp: 2024-11-06T07:27:01.722Z
Learning: In `packages/wallet-contract/test/bootstrap.js`, for Mocha tests in Node.js, async functions like `loadWasmDpp` can be assigned directly to `beforeAll` without wrapping them in another async function.
Learnt from: lklimek
PR: dashpay/platform#2405
File: packages/wasm-sdk/src/verify.rs:26-68
Timestamp: 2025-02-10T11:26:36.709Z
Learning: In the wasm-sdk package, empty vectors and placeholder values are intentionally used in verification functions during the proof-of-concept stage to ensure proper compilation and type checking.
packages/wasm-sdk/examples/group-actions-example.js (2)
Learnt from: shumkov
PR: dashpay/platform#2314
File: packages/wallet-contract/test/bootstrap.js:14-16
Timestamp: 2024-11-06T07:27:01.722Z
Learning: In `packages/wallet-contract/test/bootstrap.js`, for Mocha tests in Node.js, async functions like `loadWasmDpp` can be assigned directly to `beforeAll` without wrapping them in another async function.
Learnt from: lklimek
PR: dashpay/platform#2381
File: packages/rs-sdk/scripts/connect_to_remote.sh:0-0
Timestamp: 2024-12-10T12:39:38.182Z
Learning: When reviewing scripts in `packages/rs-sdk/scripts/`, avoid suggesting additional error handling and timeout management that complicate the script without adding significant value.
packages/js-dash-sdk/package.json (5)
Learnt from: shumkov
PR: dashpay/platform#2489
File: packages/rs-dpp/Cargo.toml:32-32
Timestamp: 2025-03-11T09:39:23.071Z
Learning: In the Dash Platform project, dependencies are currently managed using Git repository references with tags (repo+tag format in Cargo.toml) rather than published crates, as the team is not currently publishing crates to crates.io.
Learnt from: CR
PR: dashpay/platform#0
File: CLAUDE.md:0-0
Timestamp: 2025-06-24T08:18:22.301Z
Learning: The repository uses a monorepo structure managed by Yarn workspaces, allowing multiple packages (in Rust, JavaScript, and WebAssembly) to be developed and tested together.
Learnt from: shumkov
PR: dashpay/platform#2249
File: packages/dashmate/test/unit/status/scopes/platform.spec.js:466-467
Timestamp: 2024-10-18T15:37:21.329Z
Learning: In test files for the dashmate project, such as `packages/dashmate/test/unit/status/scopes/platform.spec.js`, prefer to keep mocks explicitly in tests rather than consolidating them, to increase readability.
Learnt from: shumkov
PR: dashpay/platform#2314
File: packages/wallet-contract/test/bootstrap.js:14-16
Timestamp: 2024-11-06T07:27:01.722Z
Learning: In `packages/wallet-contract/test/bootstrap.js`, for Mocha tests in Node.js, async functions like `loadWasmDpp` can be assigned directly to `beforeAll` without wrapping them in another async function.
Learnt from: shumkov
PR: dashpay/platform#2270
File: packages/dapi/lib/grpcServer/handlers/platform/broadcastStateTransitionHandlerFactory.js:19-19
Timestamp: 2024-10-24T04:58:02.843Z
Learning: For operations involving Tenderdash where no client library exists yet, it's acceptable to use the Node.js built-in `crypto` module.
packages/wasm-sdk/USAGE_EXAMPLES.md (6)
Learnt from: lklimek
PR: dashpay/platform#2405
File: packages/wasm-sdk/src/verify.rs:26-68
Timestamp: 2025-02-10T11:26:36.709Z
Learning: In the wasm-sdk package, empty vectors and placeholder values are intentionally used in verification functions during the proof-of-concept stage to ensure proper compilation and type checking.
Learnt from: QuantumExplorer
PR: dashpay/platform#2439
File: packages/rs-dpp/src/errors/consensus/state/token/mod.rs:4-22
Timestamp: 2025-01-23T02:10:08.979Z
Learning: The user QuantumExplorer prefers to handle documentation of breaking changes separately from the code changes, particularly for token-related error types and validation rules.
Learnt from: lklimek
PR: dashpay/platform#2232
File: packages/rs-sdk/src/mock/sdk.rs:90-95
Timestamp: 2024-10-10T10:30:19.883Z
Learning: In `packages/rs-sdk/src/mock/sdk.rs`, the `load_expectations` method in `MockDashPlatformSdk` remains asynchronous (`async`) for backward compatibility, even though it now delegates to the synchronous `load_expectations_sync` method.
Learnt from: shumkov
PR: dashpay/platform#2314
File: packages/wallet-contract/test/bootstrap.js:14-16
Timestamp: 2024-11-06T07:27:01.722Z
Learning: In `packages/wallet-contract/test/bootstrap.js`, for Mocha tests in Node.js, async functions like `loadWasmDpp` can be assigned directly to `beforeAll` without wrapping them in another async function.
Learnt from: shumkov
PR: dashpay/platform#2270
File: packages/dapi/lib/grpcServer/handlers/platform/broadcastStateTransitionHandlerFactory.js:19-19
Timestamp: 2024-10-24T04:58:02.843Z
Learning: For operations involving Tenderdash where no client library exists yet, it's acceptable to use the Node.js built-in `crypto` module.
Learnt from: shumkov
PR: dashpay/platform#2255
File: packages/dashmate/src/status/scopes/platform.js:112-116
Timestamp: 2024-10-19T06:10:00.808Z
Learning: In the Dashmate project, when fetching from Tenderdash RPC endpoints like `/status`, `/net_info`, and `/abci_info`, if one request fails, it's likely that the others will fail as well, so individual error handling for each fetch may not be necessary.
packages/js-dash-sdk/BLUETOOTH_IMPLEMENTATION_SUMMARY.md (1)
Learnt from: shumkov
PR: dashpay/platform#2345
File: packages/wallet-utils-contract/schema/v1/wallet-utils-contract-documents.json:27-48
Timestamp: 2024-11-25T07:48:48.027Z
Learning: The encryption implementation for AES-CBC-256 specified in `packages/wallet-utils-contract/schema/v1/wallet-utils-contract-documents.json` will be provided by another code, not included in this PR.
packages/wasm-sdk/TODO_IMPLEMENTATION_PLAN.md (6)
Learnt from: lklimek
PR: dashpay/platform#2277
File: packages/rs-sdk/src/core/transaction.rs:0-0
Timestamp: 2024-10-29T14:40:54.727Z
Learning: In `packages/rs-sdk/src/platform/document_query.rs` and `packages/rs-sdk/src/core/transaction.rs`, certain places don't implement `IntoInner`, so direct error mappings cannot be simplified using `IntoInner`. A TODO comment has been added to address this in a future PR.
Learnt from: lklimek
PR: dashpay/platform#2405
File: packages/wasm-sdk/src/verify.rs:26-68
Timestamp: 2025-02-10T11:26:36.709Z
Learning: In the wasm-sdk package, empty vectors and placeholder values are intentionally used in verification functions during the proof-of-concept stage to ensure proper compilation and type checking.
Learnt from: shumkov
PR: dashpay/platform#2259
File: packages/rs-dapi-client/src/address_list.rs:217-217
Timestamp: 2024-10-28T10:33:49.019Z
Learning: Addressing TODO comments in code may be considered out of scope for this project.
Learnt from: QuantumExplorer
PR: dashpay/platform#2439
File: packages/rs-dpp/src/errors/consensus/state/token/mod.rs:4-22
Timestamp: 2025-01-23T02:10:08.979Z
Learning: The user QuantumExplorer prefers to handle documentation of breaking changes separately from the code changes, particularly for token-related error types and validation rules.
Learnt from: lklimek
PR: dashpay/platform#2405
File: packages/rs-sdk/src/sync.rs:88-95
Timestamp: 2025-01-23T09:23:32.740Z
Learning: The `block_on` function in `packages/rs-sdk/src/sync.rs` is currently only used in tests, and its WebAssembly implementation is deferred until there's a user request for it.
Learnt from: shumkov
PR: dashpay/platform#2270
File: packages/dapi/lib/grpcServer/handlers/platform/broadcastStateTransitionHandlerFactory.js:69-125
Timestamp: 2024-10-24T05:07:35.892Z
Learning: Future development plans involve rewriting DAPI into Rust, as the rest of the project has already migrated.
packages/js-dash-sdk/src/providers/types.ts (1)
Learnt from: QuantumExplorer
PR: dashpay/platform#2439
File: packages/rs-dpp/src/errors/consensus/state/token/mod.rs:4-22
Timestamp: 2025-01-23T02:10:08.979Z
Learning: The user QuantumExplorer prefers to handle documentation of breaking changes separately from the code changes, particularly for token-related error types and validation rules.
packages/wasm-sdk/Cargo.toml (15)
Learnt from: shumkov
PR: dashpay/platform#2489
File: packages/rs-dpp/Cargo.toml:32-32
Timestamp: 2025-03-11T09:39:23.071Z
Learning: In the Dash Platform project, dependencies are currently managed using Git repository references with tags (repo+tag format in Cargo.toml) rather than published crates, as the team is not currently publishing crates to crates.io.
Learnt from: shumkov
PR: dashpay/platform#2375
File: packages/rs-drive-abci/Cargo.toml:61-63
Timestamp: 2024-12-05T09:29:38.918Z
Learning: In the `drive-abci` package, avoid adding unused dependencies like `hashbrown` to `Cargo.toml`. The team relies on CI to detect dependency version issues.
Learnt from: QuantumExplorer
PR: dashpay/platform#2431
File: packages/rs-drive/Cargo.toml:55-60
Timestamp: 2025-01-19T07:36:46.042Z
Learning: The grovedb dependencies in packages/rs-drive/Cargo.toml and related files are intentionally kept at specific revisions rather than using the latest stable version, with plans to update them at a later time.
Learnt from: lklimek
PR: dashpay/platform#2254
File: packages/rs-sdk/src/sdk.rs:585-585
Timestamp: 2024-10-18T15:39:51.172Z
Learning: The 'platform' project uses Rust version 1.80, so code in 'packages/rs-sdk' can use features available in Rust 1.80, such as the `abs_diff()` method.
Learnt from: CR
PR: dashpay/platform#0
File: CLAUDE.md:0-0
Timestamp: 2025-06-24T08:18:22.301Z
Learning: The repository uses a monorepo structure managed by Yarn workspaces, allowing multiple packages (in Rust, JavaScript, and WebAssembly) to be developed and tested together.
Learnt from: lklimek
PR: dashpay/platform#2277
File: packages/rs-dapi-client/Cargo.toml:22-22
Timestamp: 2024-10-29T10:42:00.521Z
Learning: In `packages/rs-dapi-client/Cargo.toml`, `backon` will not work without the `tokio-sleep` feature in our setup, so it's unnecessary to declare `tokio-sleep` as a separate feature in the `[features]` section.
Learnt from: lklimek
PR: dashpay/platform#2232
File: packages/rs-sdk/src/mock/sdk.rs:90-95
Timestamp: 2024-10-10T10:30:19.883Z
Learning: In `packages/rs-sdk/src/mock/sdk.rs`, the `load_expectations` method in `MockDashPlatformSdk` remains asynchronous (`async`) for backward compatibility, even though it now delegates to the synchronous `load_expectations_sync` method.
Learnt from: CR
PR: dashpay/platform#0
File: CLAUDE.md:0-0
Timestamp: 2025-06-24T08:18:22.301Z
Learning: The rs-platform-value package is used for cross-language data representation, facilitating interoperability between Rust and JavaScript.
Learnt from: shumkov
PR: dashpay/platform#2248
File: packages/rs-drive-abci/src/main.rs:106-111
Timestamp: 2024-10-17T08:52:54.300Z
Learning: In this project, the environment variable `CARGO_PKG_RUST_VERSION` is defined and can be used safely with the `env!` macro.
Learnt from: CR
PR: dashpay/platform#0
File: CLAUDE.md:0-0
Timestamp: 2025-06-24T08:18:22.301Z
Learning: Cross-language integration is achieved using WebAssembly (WASM) bindings to connect Rust and JavaScript codebases.
Learnt from: lklimek
PR: dashpay/platform#2405
File: packages/rs-sdk/src/sync.rs:88-95
Timestamp: 2025-01-23T09:23:32.740Z
Learning: The `block_on` function in `packages/rs-sdk/src/sync.rs` is currently only used in tests, and its WebAssembly implementation is deferred until there's a user request for it.
Learnt from: lklimek
PR: dashpay/platform#2405
File: packages/rs-sdk/src/sync.rs:88-95
Timestamp: 2025-01-23T09:23:32.740Z
Learning: The `block_on` function in `packages/rs-sdk/src/sync.rs` requires true blocking behavior, which is why a non-blocking WebAssembly implementation using `wasm_bindgen_futures::spawn_local` is not suitable.
Learnt from: lklimek
PR: dashpay/platform#2405
File: packages/wasm-sdk/src/lib.rs:13-17
Timestamp: 2025-01-23T09:43:25.080Z
Learning: The codebase uses tracing_wasm for WebAssembly tracing as it provides sufficient functionality for the project's needs.
Learnt from: lklimek
PR: dashpay/platform#1924
File: packages/rs-dapi-client/src/request_settings.rs:74-74
Timestamp: 2024-12-05T12:59:22.044Z
Learning: The `AppliedRequestSettings` struct in `packages/rs-dapi-client/src/request_settings.rs` is intended for internal use within the monorepo and is not part of the public API.
Learnt from: lklimek
PR: dashpay/platform#2277
File: packages/rs-dapi-client/src/executor.rs:38-38
Timestamp: 2024-10-29T14:44:01.184Z
Learning: In `packages/rs-dapi-client/src/executor.rs`, for the structs `ExecutionError<E>` and `ExecutionResponse<R>`, only the serde derives (`Serialize`, `Deserialize`) should be conditional based on the "mocks" feature; the other derives (`Debug`, `Clone`, `Eq`, `PartialEq`) should always be present.
packages/js-dash-sdk/src/bluetooth/security/BluetoothSecurity.ts (1)
Learnt from: shumkov
PR: dashpay/platform#2345
File: packages/wallet-utils-contract/schema/v1/wallet-utils-contract-documents.json:27-48
Timestamp: 2024-11-25T07:48:48.027Z
Learning: The encryption implementation for AES-CBC-256 specified in `packages/wallet-utils-contract/schema/v1/wallet-utils-contract-documents.json` will be provided by another code, not included in this PR.
packages/wasm-sdk/.github/workflows/release.yml (1)
Learnt from: CR
PR: dashpay/platform#0
File: CLAUDE.md:0-0
Timestamp: 2025-06-24T08:18:22.301Z
Learning: The repository uses a monorepo structure managed by Yarn workspaces, allowing multiple packages (in Rust, JavaScript, and WebAssembly) to be developed and tested together.
packages/wasm-sdk/docs/API_DOCUMENTATION.md (3)
Learnt from: lklimek
PR: dashpay/platform#2405
File: packages/wasm-sdk/src/verify.rs:26-68
Timestamp: 2025-02-10T11:26:36.709Z
Learning: In the wasm-sdk package, empty vectors and placeholder values are intentionally used in verification functions during the proof-of-concept stage to ensure proper compilation and type checking.
Learnt from: CR
PR: dashpay/platform#0
File: CLAUDE.md:0-0
Timestamp: 2025-06-24T08:18:22.301Z
Learning: Documents and data contracts on the platform use state transitions for updates, supporting robust and auditable data changes.
Learnt from: QuantumExplorer
PR: dashpay/platform#2439
File: packages/rs-dpp/src/errors/consensus/state/token/mod.rs:4-22
Timestamp: 2025-01-23T02:10:08.979Z
Learning: The user QuantumExplorer prefers to handle documentation of breaking changes separately from the code changes, particularly for token-related error types and validation rules.
packages/wasm-sdk/API_REFERENCE.md (1)
Learnt from: lklimek
PR: dashpay/platform#2405
File: packages/wasm-sdk/src/verify.rs:26-68
Timestamp: 2025-02-10T11:26:36.709Z
Learning: In the wasm-sdk package, empty vectors and placeholder values are intentionally used in verification functions during the proof-of-concept stage to ensure proper compilation and type checking.
🧬 Code Graph Analysis (18)
packages/wasm-drive-verify/tests/fuzz_tests.rs (1)
packages/wasm-drive-verify/src/document/verify_proof.rs (1)
verify_document_proof
(40-129)
packages/wasm-drive-verify/tests/identity_tests.rs (2)
packages/wasm-drive-verify/src/identity/verify_identity_balance_for_identity_id.rs (1)
verify_identity_balance_for_identity_id
(27-55)packages/wasm-drive-verify/src/identity/verify_identity_nonce.rs (1)
verify_identity_nonce
(27-55)
packages/js-dash-sdk/tests/bluetooth/protocol.test.ts (2)
packages/js-dash-sdk/src/bluetooth/index.ts (1)
BluetoothProtocol
(5-5)packages/js-dash-sdk/src/bluetooth/protocol.ts (1)
BluetoothProtocol
(7-216)
packages/wasm-drive-verify/tests/contract_tests.rs (1)
packages/wasm-drive-verify/src/contract/verify_contract_history.rs (1)
verify_contract_history
(28-76)
packages/js-dash-sdk/tests/bluetooth/security.test.ts (1)
packages/js-dash-sdk/src/bluetooth/security/BluetoothSecurity.ts (1)
BluetoothSecurity
(6-343)
packages/js-dash-sdk/src/modules/contracts/types.ts (1)
packages/js-dash-sdk/src/index.ts (7)
DataContract
(23-23)DocumentSchema
(24-24)Index
(25-25)ContractCreateOptions
(26-26)ContractUpdateOptions
(27-27)ContractHistoryEntry
(28-28)ContractVersion
(29-29)
packages/js-dash-sdk/src/modules/wallet/types.ts (2)
packages/wallet-lib/src/types/Wallet/methods/getAccount.js (1)
accountIndex
(27-29)packages/js-dash-sdk/src/core/types.ts (1)
WalletOptions
(15-21)
packages/js-dash-sdk/src/modules/documents/types.ts (2)
packages/js-dash-sdk/src/index.ts (6)
Document
(33-33)DocumentCreateOptions
(34-34)DocumentReplaceOptions
(35-35)DocumentDeleteOptions
(36-36)DocumentsBatchOptions
(37-37)DocumentQuery
(38-38)packages/js-dash-sdk/src/core/types.ts (1)
QueryOptions
(51-57)
packages/js-dash-sdk/src/core/WasmLoader.ts (3)
packages/js-dash-sdk/src/core/index.ts (3)
loadWasmSdk
(4-4)getWasmSdk
(4-4)isWasmLoaded
(4-4)packages/js-dash-sdk/src/index.ts (1)
loadWasmSdk
(7-7)packages/js-dash-sdk/src/SDK.ts (1)
getWasmSdk
(118-123)
packages/js-dash-sdk/src/modules/identities/types.ts (1)
packages/js-dash-sdk/src/index.ts (8)
Identity
(12-12)IdentityPublicKey
(13-13)IdentityCreateOptions
(14-14)IdentityTopUpOptions
(15-15)IdentityUpdateOptions
(16-16)AssetLockProof
(17-17)CreditTransferOptions
(18-18)CreditWithdrawalOptions
(19-19)
packages/js-dash-sdk/src/core/StateTransitionBroadcaster.ts (4)
packages/js-dash-sdk/src/SDK.ts (2)
SDK
(11-172)getWasmSdk
(118-123)packages/js-dash-sdk/src/core/types.ts (2)
BroadcastOptions
(71-74)StateTransitionResult
(39-49)packages/js-dash-sdk/src/core/WasmLoader.ts (1)
getWasmSdk
(30-35)packages/js-dash-sdk/src/utils/errors.ts (3)
StateTransitionError
(29-34)NetworkError
(15-20)TimeoutError
(50-55)
packages/wasm-sdk/examples/identity-creation-example.js (2)
packages/wasm-sdk/wasm-sdk.d.ts (1)
IdentityTransitionBuilder
(256-268)packages/js-dash-sdk-original/src/SDK/Client/Platform/createAssetLockTransaction.ts (1)
createAssetLockTransaction
(19-93)
packages/wasm-sdk/examples/bls-signatures-example.js (1)
packages/wasm-sdk/wasm-sdk.d.ts (1)
WasmSigner
(443-457)
packages/wasm-sdk/examples/group-actions-example.js (1)
packages/wasm-sdk/wasm-sdk.d.ts (1)
WasmSdk
(43-58)
packages/js-dash-sdk/src/core/ContextProvider.ts (3)
packages/js-dash-sdk/src/core/index.ts (1)
AbstractContextProvider
(2-2)packages/js-dash-sdk/src/index.ts (1)
AbstractContextProvider
(5-5)packages/js-dash-sdk/src/core/types.ts (1)
ContextProvider
(28-37)
packages/js-dash-sdk/src/providers/WebServiceProvider.ts (2)
packages/js-dash-sdk/src/providers/types.ts (4)
ProviderWithCapabilities
(62-66)QuorumInfo
(13-18)WebServiceProviderOptions
(28-36)QuorumServiceResponse
(20-26)packages/js-dash-sdk/src/core/CentralizedProvider.ts (1)
fetch
(38-57)
packages/js-dash-sdk/src/core/types.ts (1)
packages/js-dash-sdk/src/modules/wallet/types.ts (1)
WalletOptions
(25-30)
packages/js-dash-sdk/src/providers/types.ts (1)
packages/js-dash-sdk/src/core/types.ts (1)
ContextProvider
(28-37)
🪛 LanguageTool
CLAUDE.md
[uncategorized] ~98-~98: You might be missing the article “the” here.
Context: ...interfaces for building applications on Dash Platform. Dashmate (`packages/dash...
(AI_EN_LECTOR_MISSING_DETERMINER_THE)
packages/js-dash-sdk/docs/providers.md
[uncategorized] ~381-~381: Loose punctuation mark.
Context: ...king examples: - webservice-quorum.ts
: Web service provider usage - `priority-...
(UNLIKELY_OPENING_PUNCTUATION)
packages/js-dash-sdk-original/README.md
[style] ~28-~28: Consider a more concise word here.
Context: ...ense) ## Install ### ES5/ES6 via NPM In order to use this library, you will need to add ...
(IN_ORDER_TO_PREMIUM)
[uncategorized] ~31-~31: The official spelling of this programming framework is “Node.js”.
Context: ... your project as a dependency. Having NodeJS installed, just t...
(NODE_JS)
[grammar] ~133-~133: Did you mean “fewer”? The noun “features” is countable.
Context: ...rface that is easy to use (and thus has less features). ## Documentation More exte...
(FEWER_LESS)
[style] ~140-~140: Consider using a less common alternative to make your writing sound more unique and professional.
Context: ...hub.io/platform/SDK/. ## Contributing Feel free to dive in! [Open an issue](https://github...
(FEEL_FREE_TO_STYLE_ME)
packages/wasm-sdk/TODO_SUMMARY.md
[misspelling] ~71-~71: This word is normally spelled as one.
Context: ...roup state transitions (5) - Need group proto types #### API Not Available (4) - Group inf...
(EN_COMPOUNDS_PROTO_TYPES)
[grammar] ~85-~85: It appears that a hyphen is missing in the plural noun “to-dos”?
Context: ...n < 1 day each: 1. Unproved fetching (2 TODOs) - Just remove proof param 2. Batch ope...
(TO_DO_HYPHEN)
[grammar] ~86-~86: It appears that a hyphen is missing in the plural noun “to-dos”?
Context: ...move proof param 2. Batch operations (2 TODOs) - Use Promise.all 3. Basic monitoring ...
(TO_DO_HYPHEN)
[grammar] ~87-~87: It appears that a hyphen is missing in the plural noun “to-dos”?
Context: ... Use Promise.all 3. Basic monitoring (2 TODOs) - Use setInterval ## 📈 Progress Trac...
(TO_DO_HYPHEN)
[grammar] ~110-~110: It appears that a hyphen is missing in the plural noun “to-dos”?
Context: ...Week) 1. [ ] Implement deserializers (3 TODOs) 2. [ ] Add unproved fetching (2 TODOs)...
(TO_DO_HYPHEN)
[grammar] ~111-~111: It appears that a hyphen is missing in the plural noun “to-dos”?
Context: ... TODOs) 2. [ ] Add unproved fetching (2 TODOs) 3. [ ] Create withdrawal module (5 TOD...
(TO_DO_HYPHEN)
[grammar] ~112-~112: It appears that a hyphen is missing in the plural noun “to-dos”?
Context: ...DOs) 3. [ ] Create withdrawal module (5 TODOs) ### Short Term (Next 2 Weeks) 1. [ ] ...
(TO_DO_HYPHEN)
[grammar] ~115-~115: It appears that a hyphen is missing in the plural noun “to-dos”?
Context: ...eeks) 1. [ ] Implement group actions (6 TODOs) 2. [ ] Add batch operations (2 TODOs) ...
(TO_DO_HYPHEN)
[grammar] ~116-~116: It appears that a hyphen is missing in the plural noun “to-dos”?
Context: ...6 TODOs) 2. [ ] Add batch operations (2 TODOs) 3. [ ] Basic monitoring (2 TODOs) ###...
(TO_DO_HYPHEN)
[grammar] ~117-~117: It appears that a hyphen is missing in the plural noun “to-dos”?
Context: ...ns (2 TODOs) 3. [ ] Basic monitoring (2 TODOs) ### Long Term (When Unblocked) 1. [ ]...
(TO_DO_HYPHEN)
[grammar] ~128-~128: It appears that a hyphen is missing in the plural noun “to-dos”?
Context: ...cantly expand SDK capabilities - Most TODOs are features, not bugs - SDK is stabl...
(TO_DO_HYPHEN)
[grammar] ~137-~137: It appears that a hyphen is missing in the plural noun “to-dos”?
Context: ...e features) - [ ] Only platform-blocked TODOs remain - [ ] 90%+ test coverage maintai...
(TO_DO_HYPHEN)
packages/wasm-sdk/PROOF_VERIFICATION_STATUS.md
[uncategorized] ~44-~44: Possible missing preposition found.
Context: ...riveDocumentQuery` and related types 2. Construct complex queries with where clauses and ...
(AI_HYDRA_LEO_MISSING_TO)
packages/wasm-sdk/SECURITY.md
[uncategorized] ~4-~4: A comma may be missing after the conjunctive/linking adverb ‘Currently’.
Context: ...Security Policy ## Supported Versions Currently supported versions for security updates...
(SENT_START_CONJUNCTIVE_LINKING_ADVERB_COMMA)
[uncategorized] ~126-~126: If this is a compound adjective that modifies the following noun, use a hyphen.
Context: ... - Certificate pinning available 4. Rate Limiting - Built-in rate limiting for API c...
(EN_COMPOUND_ADJECTIVE_INTERNAL)
[uncategorized] ~153-~153: Possible missing preposition found.
Context: ...ed. Mitigation: - Use lockfiles - Verify package integrity - Regular security au...
(AI_HYDRA_LEO_MISSING_TO)
packages/js-dash-sdk/IMPLEMENTATION_SUMMARY.md
[uncategorized] ~188-~188: Possible missing comma found.
Context: ...tions with modern JavaScript/TypeScript tooling while maintaining compatibility and fea...
(AI_HYDRA_LEO_MISSING_COMMA)
packages/wasm-sdk/OPTIMIZATION_GUIDE.md
[grammar] ~280-~280: Did you mean “to Use”?
Context: ...nimal features** and add as needed 2. Use unproved fetching for read operations...
(MISSING_TO_BEFORE_A_VERB)
[grammar] ~285-~285: Did you mean “to Configure”?
Context: ...res that aren't immediately needed 7. Configure appropriate timeouts for your use cas...
(MISSING_TO_BEFORE_A_VERB)
packages/js-dash-sdk/README.md
[uncategorized] ~7-~7: The hyphen in WebAssembly-based is redundant.
Context: ...nimal bundle size. ## Features - 🚀 WebAssembly-based - Built on top of the Rust implementa...
(ADVERB_LY_HYPHEN_FIX)
packages/wasm-sdk/TODO_ANALYSIS.md
[grammar] ~7-~7: It appears that a hyphen is missing in the plural noun “to-dos”?
Context: ...and feasibility. ## Summary - Total TODOs: 44 - Files with TODOs: 16 - **Mo...
(TO_DO_HYPHEN)
[grammar] ~8-~8: It appears that a hyphen is missing in the plural noun “to-dos”?
Context: ...y - Total TODOs: 44 - Files with TODOs: 16 - Most TODOs: group_actions.r...
(TO_DO_HYPHEN)
[grammar] ~9-~9: It appears that a hyphen is missing in the plural noun “to-dos”?
Context: ... 44 - Files with TODOs: 16 - Most TODOs: group_actions.rs (11) ## Categoriza...
(TO_DO_HYPHEN)
[grammar] ~15-~15: It appears that a hyphen is missing in the plural noun “to-dos”?
Context: ...nal Dependencies (High Priority) These TODOs are blocked by missing platform feature...
(TO_DO_HYPHEN)
[grammar] ~18-~18: It appears that a hyphen is missing in the plural noun “to-dos”?
Context: ...tions - state_transitions/group.rs
: 4 TODOs waiting for group info API - Cannot s...
(TO_DO_HYPHEN)
[uncategorized] ~19-~19: You might be missing the article “the” here.
Context: ...set/get group info on transitions until API is available - broadcast.rs
: 2 TODOs ...
(AI_EN_LECTOR_MISSING_DETERMINER_THE)
[grammar] ~20-~20: It appears that a hyphen is missing in the plural noun “to-dos”?
Context: ...il API is available - broadcast.rs
: 2 TODOs waiting for platform_proto types - Ca...
(TO_DO_HYPHEN)
[misspelling] ~20-~20: This word is normally spelled as one.
Context: ...dcast.rs`: 2 TODOs waiting for platform_proto types - Cannot parse responses without prot...
(EN_COMPOUNDS_PROTO_TYPES)
[grammar] ~30-~30: It appears that a hyphen is missing in the plural noun “to-dos”?
Context: ...lementable Now (Medium Priority) These TODOs could be implemented with current techn...
(TO_DO_HYPHEN)
[grammar] ~33-~33: It appears that a hyphen is missing in the plural noun “to-dos”?
Context: ...sition Creation - group_actions.rs
: 6 TODOs for state transition creation - Group...
(TO_DO_HYPHEN)
[grammar] ~36-~36: It appears that a hyphen is missing in the plural noun “to-dos”?
Context: ... state transitions - withdrawal.rs
: 4 TODOs for withdrawal operations - Create, b...
(TO_DO_HYPHEN)
[grammar] ~41-~41: It appears that a hyphen is missing in the plural noun “to-dos”?
Context: ... Data Fetching - fetch_unproved.rs
: 2 TODOs for DAPI client calls - fetch_many.rs
...
(TO_DO_HYPHEN)
[grammar] ~42-~42: It appears that a hyphen is missing in the plural noun “to-dos”?
Context: ... DAPI client calls - fetch_many.rs
: 2 TODOs for batch fetching - `prefunded_balance...
(TO_DO_HYPHEN)
[grammar] ~47-~47: It appears that a hyphen is missing in the plural noun “to-dos”?
Context: ...ing Features - contract_history.rs
: 2 TODOs for monitoring - identity_info.rs
: 1 ...
(TO_DO_HYPHEN)
[grammar] ~54-~54: It appears that a hyphen is missing in the plural noun “to-dos”?
Context: ...# 3. Nice to Have (Low Priority) These TODOs are for improvements or optimizations: ...
(TO_DO_HYPHEN)
[grammar] ~57-~57: It appears that a hyphen is missing in the plural noun “to-dos”?
Context: ...alidation Enhancements - signer.rs
: 2 TODOs for BIP39 validation - Wordlist valid...
(TO_DO_HYPHEN)
[uncategorized] ~59-~59: Use a comma before ‘but’ if it connects two independent clauses (unless they are closely connected and short).
Context: ...um validation - Would improve security but basic validation exists - `withdrawal.r...
(COMMA_COMPOUND_SENTENCE_2)
[grammar] ~68-~68: It appears that a hyphen is missing in the plural noun “to-dos”?
Context: ...## Deserialization - serializer.rs
: 3 TODOs for deserialization methods - Current...
(TO_DO_HYPHEN)
[grammar] ~77-~77: It appears that a hyphen is missing in the plural noun “to-dos”?
Context: ...lysis by File ### group_actions.rs (11 TODOs) ```rust // State transition creation (...
(TO_DO_HYPHEN)
[grammar] ~97-~97: It appears that a hyphen is missing in the plural noun “to-dos”?
Context: ..._permission() ### withdrawal.rs (5 TODOs)
rust - create_withdrawal() - get_wi...
(TO_DO_HYPHEN)
[grammar] ~106-~106: It appears that a hyphen is missing in the plural noun “to-dos”?
Context: ... ### state_transitions/group.rs (5 TODOs)
rust - Deserialize GroupActionEvent...
(TO_DO_HYPHEN)
[grammar] ~112-~112: It appears that a hyphen is missing in the plural noun “to-dos”?
Context: ...4) - blocked by API ``` ### Others (23 TODOs) Various implementation tasks across ot...
(TO_DO_HYPHEN)
[grammar] ~134-~134: It appears that a hyphen is missing in the plural noun “to-dos”?
Context: .... Document Workarounds: For blocked TODOs, document temporary solutions 2. **Crea...
(TO_DO_HYPHEN)
[grammar] ~135-~135: It appears that a hyphen is missing in the plural noun “to-dos”?
Context: ...Create Issues*: Convert high-priority TODOs to GitHub issues 3. **Remove Stale TODO...
(TO_DO_HYPHEN)
[grammar] ~136-~136: It appears that a hyphen is missing in the plural noun “to-dos”?
Context: ...ODOs to GitHub issues 3. Remove Stale TODOs: Some TODOs might be outdated after r...
(TO_DO_HYPHEN)
[grammar] ~136-~136: It appears that a hyphen is missing in the plural noun “to-dos”?
Context: ... issues 3. Remove Stale TODOs: Some TODOs might be outdated after recent implemen...
(TO_DO_HYPHEN)
[grammar] ~137-~137: It appears that a hyphen is missing in the plural noun “to-dos”?
Context: ...mplementations 4. Add Context: Some TODOs lack context about why they're blocked ...
(TO_DO_HYPHEN)
[grammar] ~141-~141: It appears that a hyphen is missing in the plural noun “to-dos”?
Context: ...e blocked ## Code Quality Impact Most TODOs represent missing features rather than ...
(TO_DO_HYPHEN)
[grammar] ~144-~144: It appears that a hyphen is missing in the plural noun “to-dos”?
Context: ... ### Risk Assessment - High Risk: 0 TODOs (no security or stability issues) - **M...
(TO_DO_HYPHEN)
[grammar] ~145-~145: It appears that a hyphen is missing in the plural noun “to-dos”?
Context: ...stability issues) - Medium Risk: 11 TODOs (missing core features like withdrawals...
(TO_DO_HYPHEN)
[grammar] ~146-~146: It appears that a hyphen is missing in the plural noun “to-dos”?
Context: ...es like withdrawals) - Low Risk: 33 TODOs (nice-to-have features) ## Next Steps ...
(TO_DO_HYPHEN)
packages/wasm-sdk/TODO_IMPLEMENTATION_PLAN.md
[grammar] ~3-~3: It appears that a hyphen is missing in the plural noun “to-dos”?
Context: ...n actionable plan for addressing the 44 TODOs in the WASM SDK codebase. ## Executive...
(TO_DO_HYPHEN)
[grammar] ~7-~7: It appears that a hyphen is missing in the plural noun “to-dos”?
Context: ...ebase. ## Executive Summary Of the 44 TODOs: - 20 can be implemented now with e...
(TO_DO_HYPHEN)
[grammar] ~14-~14: It appears that a hyphen is missing in the plural noun “to-dos”?
Context: ...nities ### 1. Withdrawal Operations (5 TODOs) - HIGH PRIORITY File: `src/withdra...
(TO_DO_HYPHEN)
[uncategorized] ~14-~14: If this is a compound adjective that modifies the following noun, use a hyphen.
Context: ...## 1. Withdrawal Operations (5 TODOs) - HIGH PRIORITY File: src/withdrawal.rs
**Why Imp...
(EN_COMPOUND_ADJECTIVE_INTERNAL)
[grammar] ~41-~41: It appears that a hyphen is missing in the plural noun “to-dos”?
Context: ...lity ### 2. Deserialization Methods (3 TODOs) - HIGH PRIORITY File: `src/seriali...
(TO_DO_HYPHEN)
[uncategorized] ~41-~41: If this is a compound adjective that modifies the following noun, use a hyphen.
Context: ... 2. Deserialization Methods (3 TODOs) - HIGH PRIORITY File: src/serializer.rs
**Why Imp...
(EN_COMPOUND_ADJECTIVE_INTERNAL)
[grammar] ~54-~54: It appears that a hyphen is missing in the plural noun “to-dos”?
Context: ...ation ### 3. Unproved Data Fetching (2 TODOs) - MEDIUM PRIORITY File: `src/fetch...
(TO_DO_HYPHEN)
[uncategorized] ~54-~54: If this is a compound adjective that modifies the following noun, use a hyphen.
Context: ...# 3. Unproved Data Fetching (2 TODOs) - MEDIUM PRIORITY File: src/fetch_unproved.rs
**Why...
(EN_COMPOUND_ADJECTIVE_INTERNAL)
[grammar] ~68-~68: It appears that a hyphen is missing in the plural noun “to-dos”?
Context: ...await } ``` ### 4. Batch Operations (2 TODOs) - MEDIUM PRIORITY File: `src/fetch...
(TO_DO_HYPHEN)
[uncategorized] ~68-~68: If this is a compound adjective that modifies the following noun, use a hyphen.
Context: ...`` ### 4. Batch Operations (2 TODOs) - MEDIUM PRIORITY File: src/fetch_many.rs
**Why Imp...
(EN_COMPOUND_ADJECTIVE_INTERNAL)
[grammar] ~85-~85: It appears that a hyphen is missing in the plural noun “to-dos”?
Context: ...5. Group Actions - State Transitions (6 TODOs) - LOW PRIORITY File: `src/group_ac...
(TO_DO_HYPHEN)
[uncategorized] ~85-~85: If this is a compound adjective that modifies the following noun, use a hyphen.
Context: ...Actions - State Transitions (6 TODOs) - LOW PRIORITY File: src/group_actions.rs
**Why ...
(EN_COMPOUND_ADJECTIVE_INTERNAL)
[grammar] ~105-~105: It appears that a hyphen is missing in the plural noun “to-dos”?
Context: ...3. Sign and broadcast } ``` ## Blocked TODOs (Cannot Implement Yet) ### 1. Platform...
(TO_DO_HYPHEN)
[grammar] ~107-~107: It appears that a hyphen is missing in the plural noun “to-dos”?
Context: ... ### 1. Platform Proto Dependencies (7 TODOs) Blocker: Need platform_proto WASM ...
(TO_DO_HYPHEN)
[grammar] ~112-~112: It appears that a hyphen is missing in the plural noun “to-dos”?
Context: ...ons/group.rs ### 2. API Limitations (4 TODOs) Blocker: Platform API doesn't expo...
(TO_DO_HYPHEN)
[grammar] ~117-~117: It appears that a hyphen is missing in the plural noun “to-dos”?
Context: ...ils ### 3. External Library Support (4 TODOs) Blocker: Libraries not WASM-compat...
(TO_DO_HYPHEN)
[grammar] ~125-~125: It appears that a hyphen is missing in the plural noun “to-dos”?
Context: ... Priority Matrix | Priority | Effort | TODOs | Files | |----------|--------|-------|...
(TO_DO_HYPHEN)
[grammar] ~195-~195: It appears that a hyphen is missing in the plural noun “to-dos”?
Context: ...tions implemented - No security-related TODOs remaining - Clear documentation for blo...
(TO_DO_HYPHEN)
packages/js-dash-sdk/docs/api/providers.md
[style] ~42-~42: Three successive sentences begin with the same word. Consider rewording the sentence or use a thesaurus to find a synonym.
Context: ...reChainLockedHeight(): PromiseGets the core chain locked height. ####
ge...
(ENGLISH_WORD_REPEAT_BEGINNING_RULE)
[style] ~45-~45: Three successive sentences begin with the same word. Consider rewording the sentence or use a thesaurus to find a synonym.
Context: ...testPlatformVersion(): PromiseGets the platform version. ####
getQuorumK...
(ENGLISH_WORD_REPEAT_BEGINNING_RULE)
[style] ~119-~119: Three successive sentences begin with the same word. Consider rewording the sentence or use a thesaurus to find a synonym.
Context: ...) => void #### `provider:fallback` Emitted when fallback occurs.
typescript (fr...
(ENGLISH_WORD_REPEAT_BEGINNING_RULE)
[style] ~125-~125: Three successive sentences begin with the same word. Consider rewording the sentence or use a thesaurus to find a synonym.
Context: ... string) => void #### `all:failed` Emitted when all providers fail.
typescript ...
(ENGLISH_WORD_REPEAT_BEGINNING_RULE)
[style] ~163-~163: Three successive sentences begin with the same word. Consider rewording the sentence or use a thesaurus to find a synonym.
Context: ...toryOptions): Promise` Creates a priority provider with web service as...
(ENGLISH_WORD_REPEAT_BEGINNING_RULE)
packages/wasm-sdk/API_REFERENCE.md
[uncategorized] ~572-~572: Possible missing comma found.
Context: ... } ### `WasmCoreClient` Core chain DAPI client.
typescript class WasmC...
(AI_HYDRA_LEO_MISSING_COMMA)
[style] ~804-~804: Three successive sentences begin with the same word. Consider rewording the sentence or use a thesaurus to find a synonym.
Context: ... any ### `verifyDocumentsProof()` Verify documents proof.
typescript functio...
(ENGLISH_WORD_REPEAT_BEGINNING_RULE)
🪛 Shellcheck (0.10.0)
packages/js-dash-sdk/scripts/build-wasm.sh
[warning] 7-7: Use 'cd ... || exit' or 'cd ... || return' in case cd fails.
(SC2164)
[warning] 13-13: Use 'cd ... || exit' or 'cd ... || return' in case cd fails.
(SC2164)
🪛 markdownlint-cli2 (0.17.2)
packages/js-dash-sdk-original/README.md
42-42: Fenced code blocks should have a language specified
null
(MD040, fenced-code-language)
137-137: Bare URL used
null
(MD034, no-bare-urls)
packages/wasm-sdk/TODO_SUMMARY.md
6-6: Fenced code blocks should have a language specified
null
(MD040, fenced-code-language)
14-14: Fenced code blocks should have a language specified
null
(MD040, fenced-code-language)
22-22: Fenced code blocks should have a language specified
null
(MD040, fenced-code-language)
92-92: Fenced code blocks should have a language specified
null
(MD040, fenced-code-language)
100-100: Fenced code blocks should have a language specified
null
(MD040, fenced-code-language)
🪛 YAMLlint (1.37.1)
packages/wasm-sdk/.gitlab-ci.yml
[error] 123-123: no new line character at the end of file
(new-line-at-end-of-file)
packages/wasm-sdk/.github/workflows/ci.yml
[error] 19-19: trailing spaces
(trailing-spaces)
[error] 26-26: trailing spaces
(trailing-spaces)
[error] 32-32: trailing spaces
(trailing-spaces)
[error] 38-38: trailing spaces
(trailing-spaces)
[error] 44-44: trailing spaces
(trailing-spaces)
[error] 47-47: trailing spaces
(trailing-spaces)
[error] 61-61: trailing spaces
(trailing-spaces)
[error] 64-64: trailing spaces
(trailing-spaces)
[error] 70-70: trailing spaces
(trailing-spaces)
[error] 73-73: trailing spaces
(trailing-spaces)
[error] 79-79: trailing spaces
(trailing-spaces)
[error] 85-85: trailing spaces
(trailing-spaces)
[error] 91-91: trailing spaces
(trailing-spaces)
[error] 94-94: trailing spaces
(trailing-spaces)
[error] 97-97: trailing spaces
(trailing-spaces)
[error] 106-106: trailing spaces
(trailing-spaces)
[error] 113-113: trailing spaces
(trailing-spaces)
[error] 116-116: trailing spaces
(trailing-spaces)
[error] 119-119: trailing spaces
(trailing-spaces)
[error] 125-125: trailing spaces
(trailing-spaces)
[error] 131-131: trailing spaces
(trailing-spaces)
[error] 134-134: trailing spaces
(trailing-spaces)
[error] 143-143: trailing spaces
(trailing-spaces)
[error] 150-150: trailing spaces
(trailing-spaces)
[error] 153-153: trailing spaces
(trailing-spaces)
[error] 159-159: trailing spaces
(trailing-spaces)
[error] 165-165: trailing spaces
(trailing-spaces)
[error] 170-170: trailing spaces
(trailing-spaces)
[error] 179-179: trailing spaces
(trailing-spaces)
[error] 191-191: trailing spaces
(trailing-spaces)
[error] 197-197: trailing spaces
(trailing-spaces)
[error] 200-200: trailing spaces
(trailing-spaces)
[error] 209-209: trailing spaces
(trailing-spaces)
[error] 215-215: trailing spaces
(trailing-spaces)
[error] 218-218: trailing spaces
(trailing-spaces)
[error] 221-221: trailing spaces
(trailing-spaces)
[error] 226-226: no new line character at the end of file
(new-line-at-end-of-file)
packages/wasm-sdk/.github/workflows/release.yml
[error] 36-36: trailing spaces
(trailing-spaces)
[error] 39-39: trailing spaces
(trailing-spaces)
[error] 46-46: trailing spaces
(trailing-spaces)
[error] 49-49: trailing spaces
(trailing-spaces)
[error] 55-55: trailing spaces
(trailing-spaces)
[error] 63-63: trailing spaces
(trailing-spaces)
[error] 80-80: trailing spaces
(trailing-spaces)
[error] 86-86: trailing spaces
(trailing-spaces)
[error] 93-93: trailing spaces
(trailing-spaces)
[error] 96-96: trailing spaces
(trailing-spaces)
[error] 99-99: trailing spaces
(trailing-spaces)
[error] 116-116: trailing spaces
(trailing-spaces)
[error] 130-130: trailing spaces
(trailing-spaces)
[error] 136-136: trailing spaces
(trailing-spaces)
[error] 139-139: trailing spaces
(trailing-spaces)
[error] 145-145: no new line character at the end of file
(new-line-at-end-of-file)
🪛 Gitleaks (8.26.0)
packages/wasm-sdk/SECURITY.md
34-34: Detected a Generic API Key, potentially exposing access to various services and sensitive operations.
(generic-api-key)
🪛 Biome (1.9.4)
packages/js-dash-sdk/src/bluetooth/protocol.ts
[error] 7-216: Avoid classes that contain only static members.
Prefer using simple functions instead of classes with only static members.
(lint/complexity/noStaticOnlyClass)
[error] 16-16: Using this in a static context can be confusing.
this refers to the class.
Unsafe fix: Use the class name instead.
(lint/complexity/noThisInStatic)
[error] 30-30: Using this in a static context can be confusing.
this refers to the class.
Unsafe fix: Use the class name instead.
(lint/complexity/noThisInStatic)
[error] 48-48: Using this in a static context can be confusing.
this refers to the class.
Unsafe fix: Use the class name instead.
(lint/complexity/noThisInStatic)
[error] 62-62: Using this in a static context can be confusing.
this refers to the class.
Unsafe fix: Use the class name instead.
(lint/complexity/noThisInStatic)
[error] 81-81: Using this in a static context can be confusing.
this refers to the class.
Unsafe fix: Use the class name instead.
(lint/complexity/noThisInStatic)
[error] 84-84: Using this in a static context can be confusing.
this refers to the class.
Unsafe fix: Use the class name instead.
(lint/complexity/noThisInStatic)
[error] 85-85: Using this in a static context can be confusing.
this refers to the class.
Unsafe fix: Use the class name instead.
(lint/complexity/noThisInStatic)
[error] 141-141: Using this in a static context can be confusing.
this refers to the class.
Unsafe fix: Use the class name instead.
(lint/complexity/noThisInStatic)
packages/js-dash-sdk/examples/read-only-usage.ts
[error] 137-137: Change to an optional chain.
Unsafe fix: Change to an optional chain.
(lint/complexity/useOptionalChain)
packages/js-dash-sdk/src/core/StateTransitionBroadcaster.ts
[error] 99-99: Change to an optional chain.
Unsafe fix: Change to an optional chain.
(lint/complexity/useOptionalChain)
packages/wasm-sdk/examples/identity-creation-example.js
[error] 276-276: Expected an expression, or an assignment but instead found ']'.
Expected an expression, or an assignment here.
(parse)
packages/js-dash-sdk/src/bluetooth/BluetoothConnection.ts
[error] 149-149: Change to an optional chain.
Unsafe fix: Change to an optional chain.
(lint/complexity/useOptionalChain)
packages/js-dash-sdk/src/providers/ProviderFactory.ts
[error] 53-228: Avoid classes that contain only static members.
Prefer using simple functions instead of classes with only static members.
(lint/complexity/noStaticOnlyClass)
[error] 74-74: Using this in a static context can be confusing.
this refers to the class.
Unsafe fix: Use the class name instead.
(lint/complexity/noThisInStatic)
[error] 83-83: Using this in a static context can be confusing.
this refers to the class.
Unsafe fix: Use the class name instead.
(lint/complexity/noThisInStatic)
[error] 87-87: Using this in a static context can be confusing.
this refers to the class.
Unsafe fix: Use the class name instead.
(lint/complexity/noThisInStatic)
[error] 88-88: Using this in a static context can be confusing.
this refers to the class.
Unsafe fix: Use the class name instead.
(lint/complexity/noThisInStatic)
[error] 118-118: Using this in a static context can be confusing.
this refers to the class.
Unsafe fix: Use the class name instead.
(lint/complexity/noThisInStatic)
[error] 135-135: Using this in a static context can be confusing.
this refers to the class.
Unsafe fix: Use the class name instead.
(lint/complexity/noThisInStatic)
packages/js-dash-sdk/src/providers/PriorityContextProvider.ts
[error] 230-230: Unnecessary continue statement
Unsafe fix: Delete the unnecessary continue statement
(lint/correctness/noUnnecessaryContinue)
🪛 checkmake (0.2.2)
packages/wasm-sdk/Makefile
[warning] 6-6: Target body for "help" exceeds allowed length of 5 (12).
(maxbodylength)
[warning] 21-21: Target body for "install" exceeds allowed length of 5 (6).
(maxbodylength)
[warning] 111-111: Target body for "size" exceeds allowed length of 5 (9).
(maxbodylength)
[warning] 3-3: Missing required phony target "all"
(minphony)
🔇 Additional comments (102)
packages/js-dash-sdk/src/utils/index.ts (1)
1-1
: Barrel export looks good — watch out for accidental circular depsRe-exporting the new
errors
module from the utils index simplifies imports and LGTM.
Just keep an eye on future additions to this barrel file; as the SDK grows, barrel re-exports are prone to introduce circular-dependency chains in bundlers like Webpack/Rollup. A quickmadge --circular
check in CI can prevent surprises.packages/wasm-drive-verify/tests/document_tests.rs (1)
6-9
: Import ofSingleDocumentDriveQueryWasm
✅The added import aligns the test with the newer constructor exposed by
wasm_drive_verify::document_verification
. No issues spotted.packages/wasm-drive-verify/tests/token_tests.rs (2)
4-9
: Additional import LGTMThe new
verify_token_statuses_vec
import keeps the test file in sync with recently exposed helpers. No concerns.
97-101
: Line split is harmlessOnly a formatting tweak; functional behaviour unchanged.
CLAUDE.md (1)
35-40
: Clarify package name in test command – nice touchRenaming to “JavaScript SDK (original)” removes ambiguity now that two SDKs exist. Looks good.
.gitignore (1)
47-53
: Ignore rules forwasm-sdk
build artefacts approvedMirrors the pattern already used for
wasm-drive-verify
; prevents large artefacts from leaking into the repo.packages/js-dash-sdk/src/modules/documents/index.ts (1)
1-2
: LGTM! Clean modular export structure.The index file follows the established pattern across the SDK modules, providing a clean entry point for document-related exports while supporting tree-shaking and modular imports.
packages/js-dash-sdk/src/modules/identities/index.ts (1)
1-2
: LGTM! Consistent with established module pattern.The export structure is identical to other SDK modules, maintaining consistency across the modular architecture.
packages/js-dash-sdk/src/modules/contracts/index.ts (1)
1-2
: LGTM! Maintains consistent modular structure.The implementation follows the same clean pattern as other SDK modules, providing a unified entry point for contract-related exports.
packages/wasm-drive-verify/tests/fuzz_tests.rs (1)
93-105
: LGTM! Improved readability through multi-line formatting.The expansion of the
verify_document_proof
function calls from single-line to multi-line format significantly improves readability, making it easier to review the numerous parameters without changing any functionality.Also applies to: 193-205
packages/js-dash-sdk/src/modules/names/index.ts (1)
1-2
: LGTM! Completes the consistent modular export pattern.The names module index follows the same clean structure as other SDK modules, completing the consistent modular architecture across documents, identities, contracts, and names.
packages/wasm-drive-verify/tests/identity_tests.rs (2)
55-56
: Looks good – only readability re-wrap
No functional change is introduced; the multi-line wrapping is fine and keeps line length reasonable.
101-101
: LGTM
Same remark here – pure re-formatting, no issues spotted.packages/wasm-drive-verify/tests/contract_tests.rs (3)
19-26
: Double-check updatedverify_contract
signature
The call site now passes six arguments (proof, None, false, false, id, platform_version
).
If the upstream function signature was recently reorganised (e.g. boolean flags reordered or removed), this may compile but cause the wrong argument to be used.
Please grep for the function definition and confirm the new positional order matches this call.
40-41
: Minor style change only
Nothing to flag – re-wrap for readability is fine.
55-57
: LGTM
The large-limit test remains valid and self-documenting.packages/js-dash-sdk/src/providers/index.ts (1)
1-4
: Barrel export looks fine – watch for name collisions
Wildcard-re-exporting all oftypes
can occasionally shadow class exports with similarly-named types. No action required now, just keep an eye on it as the provider surface grows.packages/js-dash-sdk/tests/sdk.test.ts (1)
76-88
: Excellent cleanup testing.Good coverage of the cleanup functionality, ensuring proper resource management and event listener cleanup.
packages/wasm-sdk/.gitignore (1)
1-41
: Comprehensive and well-organized gitignore rules.Excellent expansion of the gitignore file to cover all relevant build artifacts, temporary files, and environment-specific files for a WASM project. The organization with clear section comments makes it maintainable and easy to understand.
packages/js-dash-sdk/examples/basic-usage.ts (2)
70-73
: Good resource cleanup pattern.Excellent practice of cleaning up SDK resources and providing user feedback about the cleanup process.
14-14
: Verify example identity ID exists on testnet.The hardcoded identity ID should be verified to exist on testnet to ensure the example works for users. Consider using a well-known identity or adding a comment about this being an example ID.
#!/bin/bash # Description: Check if the example identity ID format is valid # The ID should be a base58-encoded string of specific length for Dash Platform echo "Checking identity ID format..." echo "GWRSAVFMjXx8HpQFaNJMqBV7MBgMK4br5UESsB4S31iV" | wc -c echo "Expected length for Dash Platform identity ID is typically 44 characters"packages/js-dash-sdk/src/core/index.ts (1)
1-5
: Clean and well-organized core exports.The barrel export structure effectively consolidates core SDK components with appropriate use of both wildcard and named exports. This provides a clean API surface for consumers of the core module.
packages/js-dash-sdk/docs/quickstart-webservice.md (1)
1-170
: Excellent comprehensive documentation for web service provider.This quick start guide provides clear, practical examples covering all major use cases including setup, direct usage, quorum operations, fallback strategies, error handling, and performance optimization. The code examples are well-structured and demonstrate proper SDK usage patterns.
packages/wasm-sdk/TODO_SUMMARY.md (1)
1-138
: Excellent project management dashboard with comprehensive TODO tracking.This dashboard provides valuable insights into development progress with clear categorization, visual progress bars, and actionable items. The structure effectively communicates project status and priorities.
packages/js-dash-sdk/examples/modular-usage.ts (1)
1-61
: Excellent example demonstrating modular SDK usage and optimization techniques.This example effectively showcases the SDK's modular architecture, proper initialization patterns, and both runtime and compile-time optimizations. The code demonstrates good practices with error handling, resource cleanup, and tree-shaking techniques.
packages/js-dash-sdk/src/bluetooth/index.ts (1)
1-7
: Clean and well-organized module entry point.The Bluetooth module exports are properly structured with clear separation between types, classes, and setup functions. This follows standard module organization patterns and enables tree-shaking.
packages/js-dash-sdk/src/core/WasmLoader.ts (1)
1-39
: Well-implemented WASM loader with proper concurrency and error handling.This implementation correctly handles concurrent loading attempts with promise caching, implements the singleton pattern effectively, and provides clear error messages. The use of dynamic imports enables code splitting, and the API is clean and well-defined.
packages/js-dash-sdk/tsconfig.json (1)
3-21
: LGTM! Modern TypeScript configuration is well-structured.The updated configuration appropriately modernizes the build setup with ES2020 target, ESNext modules, and proper declaration file generation. The compiler options and exclude patterns are well-chosen for the SDK architecture.
packages/wasm-sdk/README.md (1)
1-410
: Excellent comprehensive documentation for the WASM SDK.This README provides thorough coverage of the SDK's capabilities, from basic setup to advanced features like Bluetooth integration and performance monitoring. The code examples are clear and the structure is well-organized for developers.
packages/js-dash-sdk/tests/bluetooth/protocol.test.ts (1)
1-189
: Comprehensive and well-structured test suite for BluetoothProtocol.The test coverage is excellent, covering all major functionality including encoding/decoding, chunking, validation, and edge cases. The test logic is sound and follows good testing practices.
packages/js-dash-sdk/docs/providers.md (1)
1-383
: Excellent comprehensive guide for SDK context providers.This documentation thoroughly covers all provider types, configuration options, and usage patterns. The examples are clear and the best practices section provides valuable guidance for developers implementing provider-based architectures.
packages/js-dash-sdk/rollup.config.js (1)
1-86
: Well-designed modular build configuration.This Rollup setup effectively supports the SDK's modular architecture with separate bundles for tree-shaking, proper external dependency handling, and comprehensive plugin configuration for browser compatibility. The dual CJS/ESM output format ensures broad compatibility.
packages/js-dash-sdk-original/package.json (3)
1-39
: LGTM! Package metadata is well-structured.The package name, version, description, and entry points are properly configured. The repository, author, and license information follows standard conventions.
40-55
: Review external dependency versions for security and compatibility.Several external dependencies have specific version constraints that should be verified:
@dashevo/bls": "~1.2.9"
- Using tilde range which allows patch updates@dashevo/dashcore-lib": "~0.22.0"
- Older version constraintbs58": "^4.0.1"
- Uses caret range allowing minor updateswinston": "^3.2.1"
- Potentially outdated versionWhat are the latest versions and security advisories for the following npm packages: @dashevo/bls, @dashevo/dashcore-lib, bs58, winston, node-inspect-extracted?
9-24
: Verify test script configurations and dependencies.The scripts are comprehensive but there are potential concerns:
- The
test:types
script usesyarn pnpify tsd
which may not work correctly if tsd isn't properly configured for PnP- The build process runs TypeScript compilation followed by webpack, but there's no validation that the TypeScript build succeeded before webpack runs
Run the following script to verify the test configuration:
#!/bin/bash # Check if tsd configuration exists and is compatible with PnP fd -t f "tsd.json|.tsdrc" # Check if TypeScript configs are properly set up cat packages/js-dash-sdk-original/tsconfig.build.json 2>/dev/null || echo "tsconfig.build.json not found" cat packages/js-dash-sdk-original/tsconfig.mocha.json 2>/dev/null || echo "tsconfig.mocha.json not found" # Verify webpack config exists fd -t f "webpack.config.js" packages/js-dash-sdk-original/packages/js-dash-sdk-original/README.md (1)
10-13
: Excellent security warning placement.The warning about proof verification and security implications is prominently placed and clearly communicates the trade-offs between ease of use and security. This is crucial for developers to understand the trust model.
packages/wasm-sdk/USAGE_EXAMPLES.md (3)
20-35
: LGTM! Clean SDK initialization pattern.The basic setup example correctly shows the required
start()
call before SDK usage and demonstrates proper TypeScript imports. The ready check is a good practice.
968-988
: Good pattern: Robust retry mechanism with exponential backoff.The retry implementation with configurable settings and exponential backoff is well-designed and follows best practices for handling transient failures.
1180-1234
: Excellent error handling pattern.The comprehensive error handling with categorized error types and user-friendly notifications is well-structured. The pattern correctly differentiates between different error categories and provides appropriate user feedback.
packages/wasm-sdk/build-optimized.sh (2)
1-11
: Good script setup with proper error handling.The script correctly uses
set -e
for early exit on errors and provides clear output. The cleanup of previous builds is appropriate.
12-14
: Inspectbuild-optimized.sh
usage and CI integrationTo determine if these flags conflict in practice, review how this script is used in CI and release builds:
• Check the full contents of
packages/wasm-sdk/build-optimized.sh
.
• Search CI/config files for its invocation.#!/bin/bash # List where the script is called and show its contents rg -n "build-optimized.sh" -C2 cat packages/wasm-sdk/build-optimized.shpackages/js-dash-sdk/tests/providers/WebServiceProvider.test.ts (5)
4-10
: LGTM! Proper test setup with global mock management.The global fetch mock setup and cleanup in beforeEach ensures test isolation and prevents test interference.
12-33
: Good test coverage for initialization scenarios.The initialization tests cover default configuration, custom URLs, and network-specific configurations appropriately.
74-96
: Excellent caching behavior verification.The caching test correctly verifies that subsequent calls within the cache duration don't trigger additional network requests. The assertion pattern is clear and effective.
175-232
: Comprehensive retry logic testing.The retry tests cover important scenarios:
- Successful retry after network failure
- No retry on client errors (4xx)
- Failure after exhausting retries
This demonstrates good understanding of retry patterns and appropriate test coverage.
98-173
: Well-structured quorum operation tests.The quorum tests comprehensively cover:
- Fetching all quorum keys with proper transformation
- Getting specific quorum by ID
- Active quorum filtering
The mock data structure and assertions appropriately test the provider's data transformation logic.
packages/wasm-sdk/PRODUCTION_CHECKLIST.md (1)
182-186
: Potentially misleading limitationThe “Browser-only – No Node.js support” statement conflicts with earlier checklist items (e.g., automated CI/CD, npm publishing, and
DAPI Client
usage) which imply Node.js consumption. Clarify whether Node.js is intentionally unsupported for the first release or if support is merely untested.packages/js-dash-sdk/src/modules/names/types.ts (1)
21-25
: Optionalrecords
field deserves a default
records
is optional inNameRegisterOptions
, yet many flows expect at least thedashUniqueIdentityId
. Document the behaviour whenrecords
is omitted or provide a sensible default inside the registration helper.packages/js-dash-sdk/tests/providers/PriorityContextProvider.test.ts (5)
5-63
: Well-structured mock provider implementation.The MockProvider class provides excellent test coverage capabilities with configurable failure modes and response delays.
64-145
: Comprehensive basic functionality tests.The test suite effectively validates priority selection, fallback behavior, and error handling scenarios.
147-179
: Effective caching behavior validation.The test correctly verifies that results are cached and that the cache can be cleared.
230-256
: Good provider management test coverage.The test effectively validates dynamic provider addition and removal functionality.
258-296
: Thorough event emission testing.The test comprehensively validates all expected events including error and all-failed scenarios.
packages/js-dash-sdk/examples/read-only-usage.ts (3)
158-197
: Well-structured data browser example.The example effectively demonstrates how to browse and query data contracts with proper error handling.
199-252
: Excellent monitoring dashboard example.The example effectively demonstrates real-time monitoring capabilities with platform statistics and block production tracking.
254-265
: Clean example orchestration.The main function properly executes all examples with appropriate error handling.
packages/wasm-sdk/Cargo.deny.toml (1)
1-86
: Well-configured security and license policies.The Cargo deny configuration implements comprehensive security best practices:
- Appropriate license restrictions for SDK distribution
- Security advisory enforcement
- Supply chain protection through source restrictions
- Reasonable exceptions (e.g., OpenSSL for ring crate)
packages/js-dash-sdk/src/core/StateTransitionBroadcaster.ts (2)
9-78
: Robust broadcast implementation with smart retry logic.The method correctly implements:
- Exponential backoff for retries
- Skipping retries for validation errors
- Proper error categorization
- Context-aware broadcasting
118-135
: Clean utility method implementations.The validate method properly wraps WASM validation with appropriate error handling, and the sleep utility is standard.
packages/js-dash-sdk/src/modules/wallet/types.ts (1)
1-44
: Well-designed wallet interfaces.The type definitions provide a comprehensive and type-safe contract for wallet functionality:
- Complete wallet operations in
WalletAdapter
- Flexible configuration options
- Proper use of optional parameters
- Security-conscious design (optional privateKey in Account)
packages/js-dash-sdk/src/modules/documents/types.ts (3)
3-12
: Well-designed Document interface.The Document interface correctly captures all essential document fields with appropriate types. The optional timestamps (
createdAt?
,updatedAt?
) provide flexibility for documents that may not have these fields populated immediately.
37-41
: Comprehensive batch operations type definition.The
DocumentsBatchOptions
union type correctly allows for all possible combinations of create, replace, and delete operations in a single batch. This provides excellent flexibility for batch document operations.
43-46
: Proper extension of QueryOptions for document queries.The
DocumentQuery
interface appropriately extends the baseQueryOptions
while adding the requireddataContractId
andtype
fields specific to document queries.packages/js-dash-sdk/tests/bluetooth/security.test.ts (3)
53-72
: Excellent constant-time comparison security test.This test is crucial for preventing timing attacks on pairing code verification. The variance-based approach to verify constant-time behavior is well-implemented and demonstrates security-conscious testing practices.
128-225
: Comprehensive challenge-response authentication testing.The test suite thoroughly covers the authentication flow including:
- Valid challenge response creation and verification
- Expired response rejection
- Tampered response detection
This comprehensive coverage ensures the security of the authentication mechanism.
110-126
: Proper error handling validation.The tests correctly verify that encryption and decryption operations fail when no session is established, ensuring the security model is enforced properly.
packages/wasm-sdk/TODO_IMPLEMENTATION_PLAN.md (3)
1-11
: Well-structured implementation plan with clear categorization.The document provides excellent organization of the 44 TODOs with actionable categorization into immediate, blocked, and nice-to-have items. The executive summary gives a clear overview of the work ahead.
18-32
: Concrete implementation guidance with code examples.The withdrawal operations section provides excellent implementation guidance with actual code patterns and clear task breakdown. This will help developers understand exactly what needs to be implemented.
123-133
: Effective priority matrix for implementation planning.The priority matrix clearly shows effort vs. impact, helping teams make informed decisions about implementation order. The blocking categorization prevents wasted effort on items that can't be completed yet.
packages/js-dash-sdk/examples/bluetooth-secure-pairing.ts (3)
20-47
: Comprehensive secure pairing demonstration.The step-by-step pairing process clearly demonstrates the security flow including device discovery, pairing code generation, key exchange, and secure channel establishment. The realistic crypto protocols (ECDH P-256, AES-256-GCM, ECDSA) show proper security practices.
88-132
: Valuable security best practices education.The security best practices section provides excellent educational content covering all key aspects: pairing security, encryption standards, authentication methods, message security, and session management. The practical demonstration of constant-time comparison is particularly valuable.
82-84
: Proper error handling with helpful guidance.The error handling provides meaningful feedback to users and could help with troubleshooting pairing issues in real scenarios.
packages/js-dash-sdk/examples/webservice-quorum.ts (4)
12-28
: Comprehensive provider setup with proper availability checking.The example properly demonstrates provider initialization with configuration options and includes important availability checking before proceeding. The error handling provides helpful endpoint information for troubleshooting.
39-52
: Effective parallel execution for platform status retrieval.Using
Promise.all()
to fetch platform status information concurrently is an excellent performance practice that demonstrates efficient API usage.
111-123
: Valuable caching behavior demonstration.The cache performance comparison effectively shows the benefits of the caching mechanism, providing concrete evidence of performance improvements for repeated calls.
125-183
: Well-implemented monitoring with graceful shutdown.The monitoring example demonstrates continuous monitoring with proper change detection and graceful shutdown handling. The use of
SIGINT
for cleanup is a good practice for long-running examples.packages/wasm-sdk/IMPLEMENTATION_SUMMARY.md (1)
1-196
: Comprehensive and well-structured implementation summary.This implementation summary effectively documents the completion of the WASM SDK development. The document is well-organized with clear sections covering completed tasks, module structure, achievements, and technical decisions.
The performance metrics and usage examples provide valuable information for developers, and the future considerations show thoughtful planning for continued development.
packages/js-dash-sdk/src/bluetooth/setup.ts (1)
28-32
: Good defensive programming with availability check.The Bluetooth availability check is well implemented and provides a clear error message for unsupported environments.
packages/wasm-sdk/OPTIMIZATION_GUIDE.md (2)
278-289
: Fix grammar issues in best practices list.The static analysis correctly identified missing "to" before verbs in the numbered list.
1. **Start with minimal features** and add as needed -2. **Use unproved fetching** for read operations +2. **Use unproved fetching** for read operations 3. **Batch operations** whenever possible 4. **Implement caching** for frequently accessed data 5. **Monitor performance** in production 6. **Lazy load** features that aren't immediately needed -7. **Configure appropriate timeouts** for your use case +7. **Configure appropriate timeouts** for your use case 8. **Use compression** for large data transfers 9. **Parallelize** independent operations 10. **Profile regularly** to identify bottlenecksNote: The grammar tool's suggestions about adding "to" are actually incorrect in this context - the current format is appropriate for a numbered list of action items.
11-25
: ```shell
#!/bin/bashDisplay the FeatureFlags implementation in wasm-sdk
sed -n '1,200p' packages/wasm-sdk/src/optimize.rs
Verify Rust setter methods for JS exports
rg "pub fn set_enable_tokens" -A3 packages/wasm-sdk/src/optimize.rs || true
rg "pub fn set_enable_withdrawals" -A3 packages/wasm-sdk/src/optimize.rs || true
rg "pub fn set_enable_cache" -A3 packages/wasm-sdk/src/optimize.rs || trueVerify the size reduction getter
rg "pub fn estimated_size_reduction" -A3 packages/wasm-sdk/src/optimize.rs || true
Check wasm_bindgen annotations for JS naming conventions
rg "#\[wasm_bindgen" -A2 packages/wasm-sdk/src/optimize.rs || true
</details> <details> <summary>packages/js-dash-sdk/src/core/ContextProvider.ts (1)</summary> `27-34`: **Good error handling in isValid method.** The try-catch block properly handles errors from the abstract method call and returns a sensible default. The logic is correct - a valid provider should be able to retrieve a positive block height. </details> <details> <summary>packages/js-dash-sdk/.eslintrc.js (1)</summary> `1-19`: **Clean and appropriate ESLint configuration.** The simplified ESLint setup with TypeScript support and focused rule set is well-suited for the new modular SDK architecture. The ignore patterns correctly exclude build outputs and WASM files. </details> <details> <summary>packages/js-dash-sdk/README.md (1)</summary> `1-345`: **Excellent comprehensive documentation update.** This README transformation provides a complete user guide with clear examples, comprehensive API coverage, and detailed provider documentation. The modular structure and extensive code examples make the SDK highly accessible to developers. </details> <details> <summary>packages/js-dash-sdk/src/utils/errors.ts (1)</summary> `1-55`: **Well-designed error hierarchy with meaningful error types.** This error module provides a clean, typed error hierarchy that will improve error handling throughout the SDK. Each error class has a specific purpose with meaningful messages and follows TypeScript best practices. </details> <details> <summary>packages/js-dash-sdk/src/index.ts (1)</summary> `1-89`: **Well-structured modular exports** The index file provides an excellent entry point with: - Clear separation of core and module exports - Proper TypeScript type exports for tree-shaking - Factory pattern implementation - Extended SDK class with pre-initialized modules This design allows users to choose between importing the full SDK or individual modules for optimized bundles. </details> <details> <summary>packages/js-dash-sdk/package.json (3)</summary> `3-3`: **Verify the version rollback from 5.0.0-rc.18 to 4.0.0-alpha.1.** The version rollback appears intentional for this major SDK rewrite, but please confirm this is the intended versioning strategy. --- `58-94`: **Well-structured modular exports!** The exports configuration provides excellent support for both CommonJS and ES modules with proper TypeScript declarations for each submodule. --- `19-19`: **Ensure the relative path to wasm-sdk exists in the build environment.** The build:wasm script references `../wasm-sdk`, which assumes a specific directory structure. ```shell #!/bin/bash # Description: Verify the wasm-sdk package exists at the expected location # Check if the wasm-sdk directory exists if [ -d "packages/wasm-sdk" ]; then echo "✓ wasm-sdk directory found at packages/wasm-sdk" # Check for wasm-pack build capability if [ -f "packages/wasm-sdk/Cargo.toml" ]; then echo "✓ Cargo.toml found in wasm-sdk" else echo "✗ Cargo.toml not found in wasm-sdk" fi else echo "✗ wasm-sdk directory not found at expected location" fi
packages/js-dash-sdk/src/SDK.ts (1)
85-104
: Good initialization pattern with proper error handling!The initialization method properly handles the async WASM loading, validates the context provider, and emits lifecycle events.
packages/wasm-drive-verify/src/native.rs (1)
1-54
: Clean and well-documented Rust implementation!The native API provides a clean interface for proof verification with proper error handling and clear documentation.
packages/wasm-sdk/examples/identity-creation-example.js (1)
47-50
: Incorrect key generation for ECDSA keys.Using
crypto.getRandomValues
doesn't generate valid ECDSA public keys. This is just random data, not a proper public key.- // In real usage, this would be from a wallet - const publicKeyData = new Uint8Array(33); // Compressed ECDSA public key - crypto.getRandomValues(publicKeyData); - publicKeyData[0] = 0x02; // Ensure valid compressed key prefix + // NOTE: This is a placeholder. In real usage, derive from a wallet or key generation library + // For example purposes only - DO NOT use in production + const publicKeyData = new Uint8Array([ + 0x02, // Compressed key prefix + ...Array(32).fill(0x01) // Placeholder bytes - replace with actual public key + ]);Add a comment explaining that proper key generation requires a cryptographic library:
// To generate valid keys, use a library like: // - @dashevo/dashcore-lib // - secp256k1 // - elliptic⛔ Skipped due to learnings
Learnt from: QuantumExplorer PR: dashpay/platform#2227 File: packages/rs-dpp/src/core_types/validator_set/v0/mod.rs:299-299 Timestamp: 2024-10-21T01:03:42.458Z Learning: In the `test_serialize_deserialize_validator_set_v0` test within `packages/rs-dpp/src/core_types/validator_set/v0/mod.rs`, deterministic BLS keys cannot be easily used; therefore, using `BlsPublicKey::generate()` is acceptable.
Learnt from: shumkov PR: dashpay/platform#2270 File: packages/dapi/lib/grpcServer/handlers/platform/broadcastStateTransitionHandlerFactory.js:19-19 Timestamp: 2024-10-24T04:58:02.843Z Learning: For operations involving Tenderdash where no client library exists yet, it's acceptable to use the Node.js built-in `crypto` module.
Learnt from: shumkov PR: dashpay/platform#2449 File: packages/rs-drive-abci/src/execution/platform_events/initialization/create_genesis_state/test/tokens.rs:107-150 Timestamp: 2025-03-13T07:24:37.295Z Learning: In the RS SDK test data generation code, logging private keys is intentional and only enabled when a developer explicitly chooses to enable it, which is acceptable in test code contexts.
Learnt from: QuantumExplorer PR: dashpay/platform#2257 File: packages/rs-drive-abci/tests/strategy_tests/masternodes.rs:212-220 Timestamp: 2024-11-20T20:43:41.185Z Learning: In `packages/rs-drive-abci/tests/strategy_tests/masternodes.rs`, the pattern of generating a `PrivateKey`, converting it to bytes, and reconstructing a `BlsPrivateKey` from those bytes is intentional. Avoid suggesting to simplify this code in future reviews.
Learnt from: QuantumExplorer PR: dashpay/platform#2235 File: packages/rs-dpp/src/identity/identity_public_key/v0/methods/mod.rs:8-9 Timestamp: 2024-10-10T05:10:50.059Z Learning: In the codebase, importing `Secp256k1` from `dashcore::key::Secp256k1` is acceptable.
Learnt from: QuantumExplorer PR: dashpay/platform#2257 File: packages/rs-drive-abci/src/platform_types/signature_verification_quorum_set/v0/for_saving.rs:148-151 Timestamp: 2024-11-20T16:05:40.200Z Learning: In `packages/rs-drive-abci/src/platform_types/signature_verification_quorum_set/v0/for_saving.rs`, when converting public keys from `QuorumForSavingV0` to `VerificationQuorum`, it's acceptable to use `.expect()` for public key conversion, as the conversion has been verified and panics are acceptable in this context.
Learnt from: QuantumExplorer PR: dashpay/platform#2673 File: packages/rs-drive-abci/src/execution/validation/state_transition/state_transitions/identity_update/mod.rs:1164-1197 Timestamp: 2025-06-18T03:44:14.385Z Learning: QuantumExplorer determined that a CodeRabbit suggestion about fixing signable_bytes calculation in identity update tests with contract-bound keys was incorrect - the code flow is working as intended without the suggested changes.
Learnt from: QuantumExplorer PR: dashpay/platform#2257 File: packages/rs-dpp/src/bls/native_bls.rs:45-49 Timestamp: 2024-11-20T09:55:15.990Z Learning: The `PublicKey<Bls12381G2Impl>` library is external and cannot be modified. Suggestions to modify it are not applicable.
Learnt from: shumkov PR: dashpay/platform#2345 File: packages/wallet-utils-contract/schema/v1/wallet-utils-contract-documents.json:27-48 Timestamp: 2024-11-25T07:48:48.027Z Learning: The encryption implementation for AES-CBC-256 specified in `packages/wallet-utils-contract/schema/v1/wallet-utils-contract-documents.json` will be provided by another code, not included in this PR.
Learnt from: lklimek PR: dashpay/platform#2405 File: packages/wasm-sdk/src/verify.rs:26-68 Timestamp: 2025-02-10T11:26:36.709Z Learning: In the wasm-sdk package, empty vectors and placeholder values are intentionally used in verification functions during the proof-of-concept stage to ensure proper compilation and type checking.
packages/js-dash-sdk/src/modules/identities/types.ts (1)
1-49
: Well-structured and comprehensive type definitions!The interfaces provide excellent type safety with proper use of union types, optional fields, and clear property names that align with the SDK's identity management functionality.
packages/js-dash-sdk/src/modules/identities/IdentityModule.ts (1)
235-255
: Fix: Use skipValidation from options parameterThe
skipValidation
parameter is hardcoded tofalse
instead of using the value fromoptions.skipValidation
.Apply this fix:
// Broadcast const result = await wasm.broadcastStateTransition( wasmSdk, transition, - false // skipValidation + options.skipValidation || false );⛔ Skipped due to learnings
Learnt from: shumkov PR: dashpay/platform#2270 File: packages/dapi/lib/grpcServer/handlers/platform/broadcastStateTransitionHandlerFactory.js:83-85 Timestamp: 2024-10-24T05:00:56.657Z Learning: An upcoming filter will be introduced to the `unconfirmed_txs` endpoint in `broadcastStateTransitionHandlerFactory.js`, as noted in the TODO comment. Therefore, optimizing transaction existence checks may not be necessary at this time.
Learnt from: shumkov PR: dashpay/platform#2270 File: packages/dapi/lib/grpcServer/handlers/platform/broadcastStateTransitionHandlerFactory.js:90-96 Timestamp: 2024-10-24T05:01:51.097Z Learning: In `broadcastStateTransitionHandlerFactory.js`, error handling when querying transaction status is handled in the API script.
Learnt from: shumkov PR: dashpay/platform#2274 File: packages/js-dapi-client/lib/transport/GrpcTransport/createGrpcTransportError.js:127-127 Timestamp: 2024-10-25T09:33:50.383Z Learning: In `createGrpcTransportError.js`, the size of consensus error data is already validated by gRPC transport, so adding an additional size check before base64 decoding in the `createGrpcTransportError` function is unnecessary.
Learnt from: lklimek PR: dashpay/platform#2381 File: packages/rs-sdk/scripts/connect_to_remote.sh:0-0 Timestamp: 2024-12-10T12:39:38.182Z Learning: When reviewing scripts in `packages/rs-sdk/scripts/`, avoid suggesting additional error handling and timeout management that complicate the script without adding significant value.
Learnt from: shumkov PR: dashpay/platform#2343 File: packages/rs-platform-version/src/version/drive_abci_versions/drive_abci_validation_versions/v1.rs:134-134 Timestamp: 2024-11-21T12:43:26.103Z Learning: In the codebase, the versioning of `has_nonce_validation` from version 0 to 1 and back to 0 is intentional. Do not flag this as an inconsistency in future reviews.
Learnt from: shumkov PR: dashpay/platform#2270 File: packages/dapi/lib/grpcServer/handlers/platform/broadcastStateTransitionHandlerFactory.js:81-85 Timestamp: 2024-10-24T04:59:50.270Z Learning: In `packages/dapi/lib/grpcServer/handlers/platform/broadcastStateTransitionHandlerFactory.js`, the code fetching unconfirmed transactions with a limit of 100 is temporary and will be replaced when a filter for transactions is available.
Learnt from: QuantumExplorer PR: dashpay/platform#2673 File: packages/rs-drive-abci/src/execution/validation/state_transition/state_transitions/identity_update/mod.rs:1164-1197 Timestamp: 2025-06-18T03:44:14.385Z Learning: QuantumExplorer determined that a CodeRabbit suggestion about fixing signable_bytes calculation in identity update tests with contract-bound keys was incorrect - the code flow is working as intended without the suggested changes.
Learnt from: shumkov PR: dashpay/platform#2186 File: packages/rs-drive-abci/src/execution/validation/state_transition/state_transitions/identity_credit_withdrawal/mod.rs:48-54 Timestamp: 2024-09-30T12:11:35.148Z Learning: In the identity credit withdrawal transition code, the field `platform_version.drive_abci.validation_and_processing.state_transitions.identity_credit_withdrawal_state_transition.transform_into_action` is not an `Option` type, so handling `None` cases is unnecessary.
Learnt from: shumkov PR: dashpay/platform#2186 File: packages/rs-drive-abci/src/execution/validation/state_transition/state_transitions/identity_credit_withdrawal/mod.rs:48-54 Timestamp: 2024-10-09T00:22:57.778Z Learning: In the identity credit withdrawal transition code, the field `platform_version.drive_abci.validation_and_processing.state_transitions.identity_credit_withdrawal_state_transition.transform_into_action` is not an `Option` type, so handling `None` cases is unnecessary.
Learnt from: shumkov PR: dashpay/platform#2305 File: packages/rs-drive-abci/src/abci/handler/finalize_block.rs:81-0 Timestamp: 2024-11-03T10:39:11.242Z Learning: In `packages/rs-drive-abci/src/abci/handler/finalize_block.rs`, the use of `.expect("commit transaction")` after `app.commit_transaction(platform_version)` is intentional due to the provided comment explaining its necessity. Do not flag this usage in future reviews.
Learnt from: shumkov PR: dashpay/platform#2270 File: packages/dapi/lib/grpcServer/handlers/platform/broadcastStateTransitionHandlerFactory.js:75-77 Timestamp: 2024-10-24T04:59:20.436Z Learning: Tenderdash's `tx` RPC method accepts transaction hashes in base64 encoding, or in hex encoding if prefixed with `0x`. Therefore, in `packages/dapi/lib/grpcServer/handlers/platform/broadcastStateTransitionHandlerFactory.js`, it's acceptable to use `stHash.toString('base64')` when calling `requestTenderRpc('tx', { hash: stHash.toString('base64') })`.
packages/js-dash-sdk/src/bluetooth/README.md (1)
138-138
: Verify the Bluetooth service UUID formatThe service UUID
00000000-dash-platform-bluetooth-service
appears to be a placeholder. This is not a valid UUID format.Please verify the actual Bluetooth service UUID used in the implementation:
#!/bin/bash # Search for the actual Bluetooth service UUID definition rg -A 2 "DASH_BLUETOOTH_SERVICE_UUID|BLUETOOTH_SERVICE_UUID" --type tspackages/js-dash-sdk/src/bluetooth/security/BluetoothSecurity.ts (1)
1-343
: Excellent security implementation!The cryptographic implementation follows best practices:
- Proper use of Web Crypto API with secure algorithms
- ECDH with P-256 for key exchange
- HKDF with SHA-256 for key derivation
- AES-GCM with proper nonce handling for encryption
- ECDSA for signatures
- Constant-time comparison for pairing codes
- Timestamp validation in challenge-response
packages/js-dash-sdk/src/core/types.ts (1)
23-26
: ```shell
#!/bin/bash
echo "----- wasm-sdk package.json -----"
sed -n '1,20p' packages/wasm-sdk/package.jsonecho
echo "----- DataContract and StateTransition in wasm-sdk.d.ts -----"
rg -n -C2 "DataContract" packages/wasm-sdk/wasm-sdk.d.ts
rg -n -C2 "StateTransition" packages/wasm-sdk/wasm-sdk.d.tsecho
echo "----- packages/js-dash-sdk/src/modules/contracts/types.ts -----"
sed -n '1,200p' packages/js-dash-sdk/src/modules/contracts/types.tsecho
echo "----- packages/js-dash-sdk/src/core/types.ts -----"
sed -n '1,200p' packages/js-dash-sdk/src/core/types.ts</details> <details> <summary>packages/wasm-sdk/Cargo.toml (1)</summary> `75-84`: **Well-structured feature flags** The feature flag organization provides excellent modularity, allowing users to minimize bundle size by selecting only needed features. The default "full" feature is a good developer experience choice. </details> <details> <summary>packages/js-dash-sdk/src/bluetooth/BluetoothWallet.ts (1)</summary> `89-90`: **Consistent Buffer usage in browser environments** The code uses Node.js `Buffer` for base64 conversions. In browser environments, `Buffer` might not be available unless polyfilled. Consider using a browser-compatible approach: ```diff - data: new Uint8Array(Buffer.from(key.data, 'base64')) + data: Uint8Array.from(atob(key.data), c => c.charCodeAt(0))
Or ensure Buffer polyfill is included in the SDK bundle configuration.
Also applies to: 126-127, 161-162, 164-165, 195-196, 267-267
packages/js-dash-sdk/src/providers/types.ts (1)
62-66
: Consider async consistency for provider methods.The
isAvailable()
method is async whilegetCapabilities()
andgetName()
are synchronous. If capabilities might need to be determined dynamically (e.g., after connecting to a service), consider makinggetCapabilities()
async as well.#!/bin/bash # Check how these methods are implemented in actual provider classes ast-grep --pattern 'class $_ implements ProviderWithCapabilities { $$$ }' # Also check for any class extending a provider that might implement these rg -A 10 "getCapabilities\(\)" --glob "**/*.ts" --glob "!**/types.ts"packages/js-dash-sdk/BLUETOOTH_IMPLEMENTATION_SUMMARY.md (1)
19-19
: Verify the Service UUID format.The UUID
00000000-dash-platform-bluetooth-service
doesn't follow the standard UUID format (8-4-4-4-12 hexadecimal digits). Please ensure this is the correct format or update to a valid UUID.packages/wasm-sdk/API_REFERENCE.md (1)
42-50
: Tighten the return type ofnetwork
getter.Since the constructor restricts
network
to"mainnet" | "testnet" | "devnet"
, returningstring
widens the type and loses safety.
[ suggest_optional_refactor ]- get network(): string + get network(): "mainnet" | "testnet" | "devnet"packages/wasm-sdk/docs/API_DOCUMENTATION.md (1)
424-434
:PerformanceMetrics
type not specified
getMetrics()
returnsPerformanceMetrics[]
, but the structure ofPerformanceMetrics
is never introduced.
Either include aninterface PerformanceMetrics
definition or link to its source to keep the docs self-contained.
// Native Rust API (for use by other Rust/WASM projects) | ||
pub mod native; | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🛠️ Refactor suggestion
Gate the native
module so it isn’t compiled into the WASM build
pub mod native;
is always compiled even for wasm32
targets, which will:
- Increase the final
.wasm
size (dead-code elimination is imperfect across the FFI boundary). - Potentially pull in
std
-only dependencies that breakno_std
/wasm32-unknown-unknown
builds.
Add a cfg
guard to compile the module only when beneficial:
-// Native Rust API (for use by other Rust/WASM projects)
-pub mod native;
+// Native Rust API (excluded from pure-WASM builds)
+#[cfg(not(target_arch = "wasm32"))]
+pub mod native;
🤖 Prompt for AI Agents
In packages/wasm-drive-verify/src/lib.rs around lines 41 to 43, the native
module is always compiled, which increases WASM size and may introduce std-only
dependencies. Add a cfg attribute to conditionally compile the native module
only for non-wasm32 targets or when std is available, preventing it from being
included in wasm32 builds.
#!/bin/bash | ||
|
||
# Build the WASM SDK and copy it to this package | ||
echo "Building WASM SDK..." | ||
|
||
# Navigate to wasm-sdk directory | ||
cd ../wasm-sdk | ||
|
||
# Build the WASM package | ||
wasm-pack build --target web --out-dir ../js-dash-sdk/wasm --no-typescript | ||
|
||
# Return to js-dash-sdk directory | ||
cd ../js-dash-sdk | ||
|
||
echo "WASM SDK build complete!" No newline at end of file |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🛠️ Refactor suggestion
Harden the build script (handle failures & safer defaults)
cd
commands will silently continue on failure and the script will proceed in an undefined directory. Also, exiting on first error is a common practice for CI scripts.
-#!/bin/bash
+#!/usr/bin/env bash
+
+# Fail fast on any error, unset var, or failed pipe
+set -euo pipefail
-cd ../wasm-sdk
+cd ../wasm-sdk || { echo "wasm-sdk directory not found"; exit 1; }
-cd ../js-dash-sdk
+cd ../js-dash-sdk || { echo "js-dash-sdk directory not found"; exit 1; }
These tiny guards prevent confusing downstream errors in CI.
🧰 Tools
🪛 Shellcheck (0.10.0)
[warning] 7-7: Use 'cd ... || exit' or 'cd ... || return' in case cd fails.
(SC2164)
[warning] 13-13: Use 'cd ... || exit' or 'cd ... || return' in case cd fails.
(SC2164)
🤖 Prompt for AI Agents
In packages/js-dash-sdk/scripts/build-wasm.sh lines 1 to 15, the script lacks
error handling for the cd commands and does not exit on failure, which can cause
the script to continue in the wrong directory and lead to confusing errors. Add
set -e at the start of the script to make it exit immediately on any error, and
after each cd command, add checks to ensure the directory change succeeded,
exiting with an error message if not. This will harden the script and prevent
downstream failures in CI.
"strict": true, | ||
"allowUmdGlobalAccess": true, | ||
"noImplicitAny": false, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🛠️ Refactor suggestion
Inconsistent strict mode configuration.
The configuration enables strict: true
but disables noImplicitAny: false
, which contradicts strict mode principles. This creates inconsistent type safety.
"strict": true,
- "allowUmdGlobalAccess": true,
- "noImplicitAny": false,
+ "noImplicitAny": true,
📝 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.
"strict": true, | |
"allowUmdGlobalAccess": true, | |
"noImplicitAny": false, | |
"strict": true, | |
"noImplicitAny": true, |
🤖 Prompt for AI Agents
In packages/js-dash-sdk-original/tsconfig.json around lines 7 to 9, the
TypeScript configuration sets "strict" to true but disables "noImplicitAny" by
setting it to false, causing inconsistency in strict mode settings. To fix this,
either remove the "noImplicitAny" setting to inherit the strict mode default
(which is true) or explicitly set "noImplicitAny" to true to align with strict
mode principles and ensure consistent type safety.
} | ||
|
||
// Example: Query documents | ||
const dpnsContractId = 'GWRSAVFMjXx8HpQFaNJMqBV7MBgMK4br5UESsB4S31iV'; // DPNS contract |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🛠️ Refactor suggestion
Contract ID appears to be reused from identity ID.
The DPNS contract ID appears to be the same as the example identity ID, which is likely incorrect. Consider using the actual DPNS contract ID for testnet.
- const dpnsContractId = 'GWRSAVFMjXx8HpQFaNJMqBV7MBgMK4br5UESsB4S31iV'; // DPNS contract
+ const dpnsContractId = 'GWRSAVFMjXx8HpQFaNJMqBV7MBgMK4br5UESsB4S31iV'; // TODO: Use actual DPNS contract ID
Committable suggestion skipped: line range outside the PR's diff.
🤖 Prompt for AI Agents
In packages/js-dash-sdk/examples/basic-usage.ts at line 51, the DPNS contract ID
is incorrectly set to the same value as the example identity ID. Replace this
value with the correct DPNS contract ID for the testnet environment to ensure
proper contract referencing.
```js | ||
const Dash = require("dash"); // or import Dash from "dash" | ||
|
||
const client = new Dash.Client({ | ||
wallet: { | ||
mnemonic: "arena light cheap control apple buffalo indicate rare motor valid accident isolate", | ||
}, | ||
apps: { | ||
tutorialContract: { | ||
// Learn more on how to register Data Contract | ||
// https://dashplatform.readme.io/docs/tutorial-register-a-data-contract#registering-the-data-contract | ||
contractId: "<tutorial-contract-id>" | ||
} | ||
} | ||
}); | ||
|
||
// Accessing an account allow you to transact with the Dash Network | ||
client.wallet.getAccount().then(async (account) => { | ||
console.log('Funding address', account.getUnusedAddress().address); | ||
|
||
const balance = account.getConfirmedBalance(); | ||
console.log('Confirmed Balance', balance); | ||
|
||
if (balance > 0) { | ||
// Obtain identity - the base of all platform interactions | ||
// Read more on how to create an identity here: https://dashplatform.readme.io/docs/tutorial-register-an-identity | ||
const identityIds = account.identities.getIdentityIds(); | ||
const identity = await client.platform.identities.get(identityIds[0]); | ||
|
||
// Prepare a new document containing a simple hello world sent to a hypothetical tutorial contract | ||
const document = await client.platform.documents.create( | ||
'tutorialContract.note', | ||
identity, | ||
{ message: 'Hello World' }, | ||
); | ||
|
||
// Broadcast the document into a new state transition | ||
await client.platform.documents.broadcast({ create: [document] }, identity); | ||
|
||
// Retrieve documents | ||
const documents = await client.platform.documents.get('tutorialContract.note', { | ||
limit: 2, | ||
}); | ||
|
||
console.log(documents); | ||
} | ||
}); | ||
``` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🛠️ Refactor suggestion
Verify the code example functionality.
The usage example demonstrates core SDK functionality, but there are potential issues:
- The mnemonic appears to be a test/example mnemonic - ensure this is documented as such
- The
contractId
placeholder should be more clearly marked as requiring replacement - The example assumes a funded wallet but doesn't explain how to fund it
Improve the example clarity:
const client = new Dash.Client({
wallet: {
- mnemonic: "arena light cheap control apple buffalo indicate rare motor valid accident isolate",
+ mnemonic: "arena light cheap control apple buffalo indicate rare motor valid accident isolate", // Example mnemonic - replace with your own
},
apps: {
tutorialContract: {
// Learn more on how to register Data Contract
// https://dashplatform.readme.io/docs/tutorial-register-a-data-contract#registering-the-data-contract
- contractId: "<tutorial-contract-id>"
+ contractId: "YOUR_CONTRACT_ID_HERE" // Replace with actual contract ID
}
}
});
📝 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.
```js | |
const Dash = require("dash"); // or import Dash from "dash" | |
const client = new Dash.Client({ | |
wallet: { | |
mnemonic: "arena light cheap control apple buffalo indicate rare motor valid accident isolate", | |
}, | |
apps: { | |
tutorialContract: { | |
// Learn more on how to register Data Contract | |
// https://dashplatform.readme.io/docs/tutorial-register-a-data-contract#registering-the-data-contract | |
contractId: "<tutorial-contract-id>" | |
} | |
} | |
}); | |
// Accessing an account allow you to transact with the Dash Network | |
client.wallet.getAccount().then(async (account) => { | |
console.log('Funding address', account.getUnusedAddress().address); | |
const balance = account.getConfirmedBalance(); | |
console.log('Confirmed Balance', balance); | |
if (balance > 0) { | |
// Obtain identity - the base of all platform interactions | |
// Read more on how to create an identity here: https://dashplatform.readme.io/docs/tutorial-register-an-identity | |
const identityIds = account.identities.getIdentityIds(); | |
const identity = await client.platform.identities.get(identityIds[0]); | |
// Prepare a new document containing a simple hello world sent to a hypothetical tutorial contract | |
const document = await client.platform.documents.create( | |
'tutorialContract.note', | |
identity, | |
{ message: 'Hello World' }, | |
); | |
// Broadcast the document into a new state transition | |
await client.platform.documents.broadcast({ create: [document] }, identity); | |
// Retrieve documents | |
const documents = await client.platform.documents.get('tutorialContract.note', { | |
limit: 2, | |
}); | |
console.log(documents); | |
} | |
}); | |
``` | |
const Dash = require("dash"); // or import Dash from "dash" | |
const client = new Dash.Client({ | |
wallet: { | |
mnemonic: "arena light cheap control apple buffalo indicate rare motor valid accident isolate", // Example mnemonic – replace with your own | |
}, | |
apps: { | |
tutorialContract: { | |
// Learn more on how to register a Data Contract: | |
// https://dashplatform.readme.io/docs/tutorial-register-a-data-contract#registering-the-data-contract | |
contractId: "YOUR_CONTRACT_ID_HERE", // Replace with actual contract ID | |
}, | |
}, | |
}); |
🤖 Prompt for AI Agents
In packages/js-dash-sdk-original/README.md between lines 48 and 95, clarify that
the mnemonic is a test/example value and should not be used in production by
adding a comment to that effect. Make the contractId placeholder more explicit
by marking it clearly as a required replacement value, for example by using a
more obvious placeholder format or a comment. Add a note explaining that the
example assumes the wallet is funded and provide guidance or a reference on how
to fund the wallet before running the example to avoid confusion.
const identityModule = await import('../identities/IdentityModule'); | ||
const identity = await new identityModule.IdentityModule(this.sdk).get(options.ownerId); | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🛠️ Refactor suggestion
Use SDK's identity module instead of creating new instance
Creating a new IdentityModule
instance via dynamic import may not share the same state as the SDK's identity module. Consider accessing the identity module through the SDK instance.
If the SDK provides access to its modules, use:
- const identityModule = await import('../identities/IdentityModule');
- const identity = await new identityModule.IdentityModule(this.sdk).get(options.ownerId);
+ // Assuming SDK provides getIdentityModule() or similar
+ const identity = await this.sdk.identities.get(options.ownerId);
Otherwise, consider passing the identity module as a dependency to avoid circular imports and ensure consistent state.
📝 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 identityModule = await import('../identities/IdentityModule'); | |
const identity = await new identityModule.IdentityModule(this.sdk).get(options.ownerId); | |
// Assuming SDK provides getIdentityModule() or similar | |
const identity = await this.sdk.identities.get(options.ownerId); |
🤖 Prompt for AI Agents
In packages/js-dash-sdk/src/modules/contracts/ContractModule.ts around lines 28
to 30, avoid dynamically importing and instantiating a new IdentityModule as it
may cause state inconsistencies. Instead, access the identity module directly
from the existing SDK instance, for example via this.sdk.identity or the
appropriate property. If direct access is not available, refactor to pass the
identity module as a dependency to maintain consistent state and prevent
circular imports.
console.log('Connecting to GATT server...'); | ||
this.server = await device.gatt!.connect(); | ||
|
||
// Get the Dash service | ||
console.log('Getting Dash service...'); | ||
this.service = await this.server.getPrimaryService(DASH_BLUETOOTH_SERVICE_UUID); | ||
|
||
// Get characteristics | ||
console.log('Getting characteristics...'); | ||
this.commandChar = await this.service.getCharacteristic(COMMAND_CHARACTERISTIC_UUID); | ||
this.responseChar = await this.service.getCharacteristic(RESPONSE_CHARACTERISTIC_UUID); | ||
this.statusChar = await this.service.getCharacteristic(STATUS_CHARACTERISTIC_UUID); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🛠️ Refactor suggestion
Remove console.log statements from production code
Debug console.log statements should be removed or replaced with a proper logging mechanism.
Replace with conditional debug logging:
- console.log('Connecting to GATT server...');
+ this.options.debug && console.log('Connecting to GATT server...');
this.server = await device.gatt!.connect();
// Get the Dash service
- console.log('Getting Dash service...');
+ this.options.debug && console.log('Getting Dash service...');
this.service = await this.server.getPrimaryService(DASH_BLUETOOTH_SERVICE_UUID);
// Get characteristics
- console.log('Getting characteristics...');
+ this.options.debug && console.log('Getting characteristics...');
Or better yet, use a proper logger that can be configured at the SDK level.
📝 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.
console.log('Connecting to GATT server...'); | |
this.server = await device.gatt!.connect(); | |
// Get the Dash service | |
console.log('Getting Dash service...'); | |
this.service = await this.server.getPrimaryService(DASH_BLUETOOTH_SERVICE_UUID); | |
// Get characteristics | |
console.log('Getting characteristics...'); | |
this.commandChar = await this.service.getCharacteristic(COMMAND_CHARACTERISTIC_UUID); | |
this.responseChar = await this.service.getCharacteristic(RESPONSE_CHARACTERISTIC_UUID); | |
this.statusChar = await this.service.getCharacteristic(STATUS_CHARACTERISTIC_UUID); | |
this.options.debug && console.log('Connecting to GATT server...'); | |
this.server = await device.gatt!.connect(); | |
// Get the Dash service | |
this.options.debug && console.log('Getting Dash service...'); | |
this.service = await this.server.getPrimaryService(DASH_BLUETOOTH_SERVICE_UUID); | |
// Get characteristics | |
this.options.debug && console.log('Getting characteristics...'); | |
this.commandChar = await this.service.getCharacteristic(COMMAND_CHARACTERISTIC_UUID); | |
this.responseChar = await this.service.getCharacteristic(RESPONSE_CHARACTERISTIC_UUID); | |
this.statusChar = await this.service.getCharacteristic(STATUS_CHARACTERISTIC_UUID); |
🤖 Prompt for AI Agents
In packages/js-dash-sdk/src/bluetooth/BluetoothConnection.ts around lines 100 to
111, remove all console.log statements used for debugging. Replace them with a
proper logging mechanism, such as a configurable logger instance at the SDK
level, or use conditional debug logging that can be enabled or disabled based on
environment or configuration. This ensures production code does not output debug
logs unnecessarily.
// Simulate network fetch | ||
// In real usage, this would call fetch_data_contract | ||
const contract = { | ||
id: contractId, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fix WasmSdk initialization with required network parameter
The WasmSdk
constructor requires a network
parameter. This will throw a runtime error.
- const sdk = new WasmSdk();
+ const sdk = new WasmSdk('testnet');
Committable suggestion skipped: line range outside the PR's diff.
🤖 Prompt for AI Agents
In packages/wasm-sdk/examples/contract-cache-example.js at line 324, the WasmSdk
constructor is called without the required network parameter, which causes a
runtime error. Update the WasmSdk initialization to include the appropriate
network argument as the first parameter to fix this issue.
|
||
// Single provider mode | ||
if (!options.usePriority && providers.length === 1) { | ||
return this.createSingleProvider(providers[0], network, options); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🛠️ Refactor suggestion
Replace 'this' with class name in static methods
Using this
in static methods can be confusing. Replace with the class name for clarity.
- return this.createSingleProvider(providers[0], network, options);
+ return ProviderFactory.createSingleProvider(providers[0], network, options);
- const provider = await this.createSingleProvider(providerType, network, options);
+ const provider = await ProviderFactory.createSingleProvider(providerType, network, options);
- name: this.getProviderName(providerType),
- capabilities: this.getProviderCapabilities(providerType),
+ name: ProviderFactory.getProviderName(providerType),
+ capabilities: ProviderFactory.getProviderCapabilities(providerType),
- return this.create({
+ return ProviderFactory.create({
- return this.create({
+ return ProviderFactory.create({
Also applies to: 83-83, 87-88, 118-118, 135-135
🧰 Tools
🪛 Biome (1.9.4)
[error] 74-74: Using this in a static context can be confusing.
this refers to the class.
Unsafe fix: Use the class name instead.
(lint/complexity/noThisInStatic)
🤖 Prompt for AI Agents
In packages/js-dash-sdk/src/providers/ProviderFactory.ts at lines 74, 83, 87-88,
118, and 135, replace all instances of 'this' used inside static methods with
the class name 'ProviderFactory' to improve clarity and avoid confusion. This
means changing calls like 'this.createSingleProvider' to
'ProviderFactory.createSingleProvider' and similarly for other static method
references within these lines.
async function sdkIntegrationExample() { | ||
console.log('\n=== SDK Integration Example ==='); | ||
|
||
const sdk = new WasmSdk(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fix WasmSdk initialization with required network parameter
The WasmSdk
constructor requires a network
parameter.
- const sdk = new WasmSdk();
+ const sdk = new WasmSdk('testnet');
📝 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 sdk = new WasmSdk(); | |
const sdk = new WasmSdk('testnet'); |
🤖 Prompt for AI Agents
In packages/wasm-sdk/examples/group-actions-example.js at line 324, the WasmSdk
is instantiated without the required network parameter. Fix this by passing the
appropriate network argument to the WasmSdk constructor during initialization.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Review continued from previous batch...
``` | ||
00000000-dash-platform-bluetooth-service | ||
``` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fix invalid Bluetooth service UUID format
The service and characteristic UUIDs are not in valid UUID format. UUIDs must be in the format XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX
where X is a hexadecimal digit (0-9, A-F).
Example valid UUIDs:
Service UUID: 6E400001-B5A3-F393-E0A9-E50E24DCCA9E
Command Characteristic: 6E400002-B5A3-F393-E0A9-E50E24DCCA9E
Response Characteristic: 6E400003-B5A3-F393-E0A9-E50E24DCCA9E
Status Characteristic: 6E400004-B5A3-F393-E0A9-E50E24DCCA9E
Consider using a UUID generator or following the Bluetooth SIG guidelines for custom service UUIDs.
Also applies to: 22-22, 27-27, 32-32
🤖 Prompt for AI Agents
In packages/js-dash-sdk/src/bluetooth/MOBILE_INTERFACE.md around lines 15 to 17,
the Bluetooth service UUID is not in a valid UUID format. Replace the invalid
UUID string with a properly formatted UUID following the pattern
XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX using hexadecimal digits. Apply the same
correction to lines 22, 27, and 32 to ensure all service and characteristic
UUIDs conform to the standard UUID format.
async getLatestPlatformBlockTime(): Promise<number> { | ||
const cached = this.getCached<number>('blockTime'); | ||
if (cached !== null) return cached; | ||
|
||
const status = await this.fetch<PlatformStatus>('/status'); | ||
this.setCache('blockTime', status.blockTime); | ||
return status.blockTime; | ||
} | ||
|
||
async getLatestPlatformCoreChainLockedHeight(): Promise<number> { | ||
const cached = this.getCached<number>('coreChainLockedHeight'); | ||
if (cached !== null) return cached; | ||
|
||
const status = await this.fetch<PlatformStatus>('/status'); | ||
this.setCache('coreChainLockedHeight', status.coreChainLockedHeight); | ||
return status.coreChainLockedHeight; | ||
} | ||
|
||
async getLatestPlatformVersion(): Promise<string> { | ||
const cached = this.getCached<string>('version'); | ||
if (cached !== null) return cached; | ||
|
||
const status = await this.fetch<PlatformStatus>('/status'); | ||
this.setCache('version', status.version); | ||
return status.version; | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🛠️ Refactor suggestion
Optimize caching strategy to prevent redundant API calls
The methods getLatestPlatformBlockTime
, getLatestPlatformCoreChainLockedHeight
, and getLatestPlatformVersion
only cache their specific field after fetching from /status
, while getLatestPlatformBlockHeight
caches all fields. This inconsistency could lead to redundant API calls.
Apply this pattern to all status-fetching methods:
async getLatestPlatformBlockTime(): Promise<number> {
const cached = this.getCached<number>('blockTime');
if (cached !== null) return cached;
const status = await this.fetch<PlatformStatus>('/status');
+ // Cache all fields to prevent redundant calls
+ this.setCache('blockHeight', status.blockHeight);
this.setCache('blockTime', status.blockTime);
+ this.setCache('coreChainLockedHeight', status.coreChainLockedHeight);
+ this.setCache('version', status.version);
+ this.setCache('timePerBlock', status.timePerBlock);
return status.blockTime;
}
📝 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.
async getLatestPlatformBlockTime(): Promise<number> { | |
const cached = this.getCached<number>('blockTime'); | |
if (cached !== null) return cached; | |
const status = await this.fetch<PlatformStatus>('/status'); | |
this.setCache('blockTime', status.blockTime); | |
return status.blockTime; | |
} | |
async getLatestPlatformCoreChainLockedHeight(): Promise<number> { | |
const cached = this.getCached<number>('coreChainLockedHeight'); | |
if (cached !== null) return cached; | |
const status = await this.fetch<PlatformStatus>('/status'); | |
this.setCache('coreChainLockedHeight', status.coreChainLockedHeight); | |
return status.coreChainLockedHeight; | |
} | |
async getLatestPlatformVersion(): Promise<string> { | |
const cached = this.getCached<string>('version'); | |
if (cached !== null) return cached; | |
const status = await this.fetch<PlatformStatus>('/status'); | |
this.setCache('version', status.version); | |
return status.version; | |
} | |
async getLatestPlatformBlockTime(): Promise<number> { | |
const cached = this.getCached<number>('blockTime'); | |
if (cached !== null) return cached; | |
const status = await this.fetch<PlatformStatus>('/status'); | |
// Cache all fields to prevent redundant calls | |
this.setCache('blockHeight', status.blockHeight); | |
this.setCache('blockTime', status.blockTime); | |
this.setCache('coreChainLockedHeight', status.coreChainLockedHeight); | |
this.setCache('version', status.version); | |
this.setCache('timePerBlock', status.timePerBlock); | |
return status.blockTime; | |
} |
🤖 Prompt for AI Agents
In packages/js-dash-sdk/src/core/CentralizedProvider.ts around lines 73 to 98,
the methods getLatestPlatformBlockTime, getLatestPlatformCoreChainLockedHeight,
and getLatestPlatformVersion each fetch the /status endpoint separately and
cache only their specific field, causing redundant API calls. Refactor these
methods to fetch /status once, then cache all relevant fields (blockTime,
coreChainLockedHeight, version) together, and return the requested field from
the cache to optimize and prevent multiple API calls.
} | ||
} catch { | ||
continue; | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Remove unnecessary continue statement
The continue
statement is unnecessary as it's the last statement in the loop iteration.
} catch {
- continue;
}
📝 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.
} | |
} catch { | |
continue; | |
} | |
} | |
} catch { | |
} |
🧰 Tools
🪛 Biome (1.9.4)
[error] 230-230: Unnecessary continue statement
Unsafe fix: Delete the unnecessary continue statement
(lint/correctness/noUnnecessaryContinue)
🤖 Prompt for AI Agents
In packages/js-dash-sdk/src/providers/PriorityContextProvider.ts around lines
228 to 231, remove the unnecessary continue statement inside the catch block
since it is the last statement in the loop iteration and does not affect the
flow. Simply delete the continue statement to clean up the code.
export interface QuorumServiceResponse { | ||
[quorumHash: string]: { | ||
publicKey: string; | ||
version: number; | ||
type: string; | ||
}; | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🛠️ Refactor suggestion
Use the QuorumPublicKey
interface for consistency.
The nested object has the same structure as QuorumPublicKey
but doesn't reuse the interface. This could lead to maintenance issues.
export interface QuorumServiceResponse {
- [quorumHash: string]: {
- publicKey: string;
- version: number;
- type: string;
- };
+ [quorumHash: string]: QuorumPublicKey;
}
📝 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.
export interface QuorumServiceResponse { | |
[quorumHash: string]: { | |
publicKey: string; | |
version: number; | |
type: string; | |
}; | |
} | |
export interface QuorumServiceResponse { | |
[quorumHash: string]: QuorumPublicKey; | |
} |
🤖 Prompt for AI Agents
In packages/js-dash-sdk/src/providers/types.ts between lines 20 and 26, the
nested object in QuorumServiceResponse duplicates the structure of the
QuorumPublicKey interface. To maintain consistency and reduce maintenance
issues, replace the inline object type with the QuorumPublicKey interface
reference instead.
async getLatestPlatformBlockHeight(): Promise<number> { | ||
const cached = this.getCached<number>('blockHeight'); | ||
if (cached !== null) return cached; | ||
|
||
const request = BluetoothProtocol.createRequest(MessageType.GET_BLOCK_HEIGHT); | ||
const response = await this.connection.sendRequest(request); | ||
|
||
if (!response.success) { | ||
throw new Error(`Failed to get block height: ${response.error?.message}`); | ||
} | ||
|
||
const height = response.data.height; | ||
this.setCache('blockHeight', height); | ||
return height; | ||
} | ||
|
||
async getLatestPlatformBlockTime(): Promise<number> { | ||
const cached = this.getCached<number>('blockTime'); | ||
if (cached !== null) return cached; | ||
|
||
const request = BluetoothProtocol.createRequest(MessageType.GET_BLOCK_TIME); | ||
const response = await this.connection.sendRequest(request); | ||
|
||
if (!response.success) { | ||
throw new Error(`Failed to get block time: ${response.error?.message}`); | ||
} | ||
|
||
const time = response.data.time; | ||
this.setCache('blockTime', time); | ||
return time; | ||
} | ||
|
||
async getLatestPlatformCoreChainLockedHeight(): Promise<number> { | ||
const cached = this.getCached<number>('coreChainLockedHeight'); | ||
if (cached !== null) return cached; | ||
|
||
const request = BluetoothProtocol.createRequest(MessageType.GET_CORE_CHAIN_LOCKED_HEIGHT); | ||
const response = await this.connection.sendRequest(request); | ||
|
||
if (!response.success) { | ||
throw new Error(`Failed to get core chain locked height: ${response.error?.message}`); | ||
} | ||
|
||
const height = response.data.height; | ||
this.setCache('coreChainLockedHeight', height); | ||
return height; | ||
} | ||
|
||
async getLatestPlatformVersion(): Promise<string> { | ||
const cached = this.getCached<string>('version'); | ||
if (cached !== null) return cached; | ||
|
||
const request = BluetoothProtocol.createRequest(MessageType.GET_PLATFORM_VERSION); | ||
const response = await this.connection.sendRequest(request); | ||
|
||
if (!response.success) { | ||
throw new Error(`Failed to get platform version: ${response.error?.message}`); | ||
} | ||
|
||
const version = response.data.version; | ||
this.setCache('version', version); | ||
return version; | ||
} | ||
|
||
async getProposerBlockCount(proposerProTxHash: string): Promise<number | null> { | ||
const cacheKey = `proposerBlockCount:${proposerProTxHash}`; | ||
const cached = this.getCached<number>(cacheKey); | ||
if (cached !== null) return cached; | ||
|
||
const request = BluetoothProtocol.createRequest( | ||
MessageType.GET_PROPOSER_BLOCK_COUNT, | ||
{ proposerProTxHash } | ||
); | ||
const response = await this.connection.sendRequest(request); | ||
|
||
if (!response.success) { | ||
return null; | ||
} | ||
|
||
const count = response.data.count; | ||
this.setCache(cacheKey, count); | ||
return count; | ||
} | ||
|
||
async getTimePerBlockMillis(): Promise<number> { | ||
const cached = this.getCached<number>('timePerBlock'); | ||
if (cached !== null) return cached; | ||
|
||
const request = BluetoothProtocol.createRequest(MessageType.GET_TIME_PER_BLOCK); | ||
const response = await this.connection.sendRequest(request); | ||
|
||
if (!response.success) { | ||
throw new Error(`Failed to get time per block: ${response.error?.message}`); | ||
} | ||
|
||
const time = response.data.timePerBlock; | ||
this.setCache('timePerBlock', time); | ||
return time; | ||
} | ||
|
||
async getBlockProposer(blockHeight: number): Promise<string | null> { | ||
const cacheKey = `blockProposer:${blockHeight}`; | ||
const cached = this.getCached<string>(cacheKey); | ||
if (cached !== null) return cached; | ||
|
||
const request = BluetoothProtocol.createRequest( | ||
MessageType.GET_BLOCK_PROPOSER, | ||
{ blockHeight } | ||
); | ||
const response = await this.connection.sendRequest(request); | ||
|
||
if (!response.success) { | ||
return null; | ||
} | ||
|
||
const proposer = response.data.proposer; | ||
this.setCache(cacheKey, proposer); | ||
return proposer; | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🛠️ Refactor suggestion
Inconsistent error handling across methods.
Some methods throw errors on failure while others return null. This inconsistency could confuse API consumers.
- Methods that throw:
getLatestPlatformBlockHeight
,getLatestPlatformBlockTime
, etc. - Methods that return null:
getProposerBlockCount
,getBlockProposer
Consider standardizing the error handling approach.
Additionally, add response validation before accessing properties to prevent runtime errors:
const response = await this.connection.sendRequest(request);
if (!response.success) {
throw new Error(`Failed to get block height: ${response.error?.message}`);
}
+
+if (!response.data || typeof response.data.height !== 'number') {
+ throw new Error('Invalid response format: missing or invalid height');
+}
const height = response.data.height;
🤖 Prompt for AI Agents
In packages/js-dash-sdk/src/bluetooth/BluetoothProvider.ts between lines 54 and
172, the error handling is inconsistent: some methods throw errors on failed
responses while others return null. Standardize this by choosing one
approach—preferably throwing errors for all methods to maintain consistency.
Also, add validation checks on the response object before accessing nested
properties like response.data.height or response.data.time to avoid runtime
errors if the response structure is unexpected or incomplete.
private scheduleReconnect(): void { | ||
if (this.reconnectTimer) { | ||
clearTimeout(this.reconnectTimer); | ||
} | ||
|
||
this.reconnectTimer = setTimeout(async () => { | ||
try { | ||
console.log('Attempting to reconnect...'); | ||
await this.connect(); | ||
} catch (error) { | ||
console.error('Reconnection failed:', error); | ||
// Schedule another attempt | ||
this.scheduleReconnect(); | ||
} | ||
}, this.options.reconnectDelay); | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🛠️ Refactor suggestion
Add retry limits to prevent infinite reconnection attempts.
The current implementation will retry indefinitely if connections keep failing, which could drain battery on mobile devices or cause other issues.
Consider adding a maximum retry count and exponential backoff:
+private reconnectAttempts = 0;
+private readonly maxReconnectAttempts = 10;
private scheduleReconnect(): void {
if (this.reconnectTimer) {
clearTimeout(this.reconnectTimer);
}
+
+ if (this.reconnectAttempts >= this.maxReconnectAttempts) {
+ console.error('Maximum reconnection attempts reached');
+ this.connection.emit('reconnectFailed');
+ return;
+ }
+ const delay = Math.min(
+ this.options.reconnectDelay! * Math.pow(2, this.reconnectAttempts),
+ 60000 // Max 1 minute
+ );
+ this.reconnectAttempts++;
this.reconnectTimer = setTimeout(async () => {
try {
console.log('Attempting to reconnect...');
await this.connect();
+ this.reconnectAttempts = 0; // Reset on success
} catch (error) {
console.error('Reconnection failed:', error);
// Schedule another attempt
this.scheduleReconnect();
}
- }, this.options.reconnectDelay);
+ }, delay);
}
📝 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.
private scheduleReconnect(): void { | |
if (this.reconnectTimer) { | |
clearTimeout(this.reconnectTimer); | |
} | |
this.reconnectTimer = setTimeout(async () => { | |
try { | |
console.log('Attempting to reconnect...'); | |
await this.connect(); | |
} catch (error) { | |
console.error('Reconnection failed:', error); | |
// Schedule another attempt | |
this.scheduleReconnect(); | |
} | |
}, this.options.reconnectDelay); | |
} | |
// Add these two new fields at the top of the class (alongside other properties) | |
private reconnectAttempts = 0; | |
private readonly maxReconnectAttempts = 10; | |
private scheduleReconnect(): void { | |
if (this.reconnectTimer) { | |
clearTimeout(this.reconnectTimer); | |
} | |
// Stop retrying once we've hit the max | |
if (this.reconnectAttempts >= this.maxReconnectAttempts) { | |
console.error('Maximum reconnection attempts reached'); | |
this.connection.emit('reconnectFailed'); | |
return; | |
} | |
// Exponential backoff, capped at 1 minute | |
const delay = Math.min( | |
this.options.reconnectDelay! * Math.pow(2, this.reconnectAttempts), | |
60000 | |
); | |
this.reconnectAttempts++; | |
this.reconnectTimer = setTimeout(async () => { | |
try { | |
console.log('Attempting to reconnect...'); | |
await this.connect(); | |
// Reset on success | |
this.reconnectAttempts = 0; | |
} catch (error) { | |
console.error('Reconnection failed:', error); | |
// Schedule another attempt | |
this.scheduleReconnect(); | |
} | |
}, delay); | |
} |
🤖 Prompt for AI Agents
In packages/js-dash-sdk/src/bluetooth/BluetoothProvider.ts around lines 241 to
256, the scheduleReconnect method retries indefinitely on failure, risking
resource exhaustion. Add a maximum retry count property to track attempts and
modify scheduleReconnect to stop retrying after reaching this limit. Implement
exponential backoff by increasing the reconnect delay after each failed attempt
before scheduling the next reconnect.
class DocumentQuery { | ||
constructor(contractId: string, documentType: string); | ||
where(field: string, operator: string, value: any): DocumentQuery; | ||
orderBy(field: string, direction: 'asc' | 'desc'): DocumentQuery; | ||
limit(count: number): DocumentQuery; | ||
startAt(documentId: string): DocumentQuery; | ||
startAfter(documentId: string): DocumentQuery; | ||
} | ||
``` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🛠️ Refactor suggestion
DocumentQuery chain is missing a terminal/execute()
method
All builder-style helpers (where
, orderBy
, limit
, …) are listed, but there is no way to actually run the query and fetch results.
Consider adding something like:
execute(): Promise<object[]>;
without it, users are left guessing how to obtain data.
🤖 Prompt for AI Agents
In packages/wasm-sdk/docs/API_DOCUMENTATION.md around lines 185 to 194, the
DocumentQuery class lacks a terminal method to execute the built query and fetch
results. Add an execute() method that returns a Promise resolving to an array of
objects, e.g., execute(): Promise<object[]>;, to provide a clear way for users
to run the query and obtain data.
// Update identity | ||
function createIdentityUpdateTransition( | ||
identityId: string, | ||
revision: number, | ||
addPublicKeys?: Array<PublicKey>, | ||
disablePublicKeys?: Array<number>, | ||
publicKeysDisabledAt?: number | ||
): Uint8Array | ||
``` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🛠️ Refactor suggestion
PublicKey
type is referenced but never defined
createIdentityUpdateTransition
returns a parameter typed as Array<PublicKey>
, yet no PublicKey
interface/alias is documented anywhere in this file.
Readers won’t know the required structure (fields, constraints, serialization rules) of that object.
- addPublicKeys?: Array<PublicKey>,
+ addPublicKeys?: Array<PublicKey>, // ⇦ make sure PublicKey is documented below
Please add a short interface PublicKey { … }
snippet (or link to an existing definition) in either the Core Classes section or right before this code block.
Committable suggestion skipped: line range outside the PR's diff.
🤖 Prompt for AI Agents
In packages/wasm-sdk/docs/API_DOCUMENTATION.md around lines 214 to 222, the
PublicKey type used in the createIdentityUpdateTransition function is not
defined or documented, leaving readers unclear about its structure. Add a
concise interface definition for PublicKey, including its key fields and any
relevant constraints or serialization notes, either in the Core Classes section
or immediately before the createIdentityUpdateTransition code block to clarify
its expected format.
@CodeRabbit rereview |
Tip For best results, initiate chat on the files or code changes. @QuantumExplorer, I notice you used Available review commands:
Given that this PR introduces a substantial new JavaScript SDK with many new files, you might want to use Would you like me to trigger one of these reviews for you? 🧠 Learnings used
|
@coderabbitai full review |
✅ Actions performedFull review triggered. |
Resolves merge conflicts by: - Accepting upstream Cargo.toml changes that properly fix LTO configuration at workspace level (PR #2683) - Accepting upstream .pnp.cjs and yarn.lock changes - Removing temporary local workarounds for WASM build issues 🤖 Generated with [Claude Code](https://claude.ai/code) Co-Authored-By: Claude <[email protected]>
We did things a different way |
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
New Features
Documentation
Bug Fixes
.gitignore
coverage for build artifacts, dependencies, and temporary files.Style
Tests
Chores