Javajam test vectors runner#476
Merged
Merged
Conversation
Contributor
|
Important Review skippedAuto incremental reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the You can disable this status message by setting the 📝 WalkthroughSummary by CodeRabbit
WalkthroughThis update introduces a new "javajam" test runner and associated state transition testing infrastructure, including utilities for loading and representing blockchain state and transitions. Several core data structures are updated, notably the handling of recent blocks, accumulation outputs, and privileged services, now supporting per-core mappings. Numerous codecs and type definitions are revised for consistency and extensibility. Changes
Sequence Diagram(s)sequenceDiagram
participant CLI
participant JavaJamRunner
participant StateLoader
participant StateTransition
participant Blockchain
CLI->>JavaJamRunner: Start test run with arguments
JavaJamRunner->>StateLoader: Load pre-state and post-state from JSON
JavaJamRunner->>StateTransition: Parse block and state transitions
StateTransition->>Blockchain: Initialize test context (pre-state, prior blocks)
StateTransition->>Blockchain: Execute state transition
Blockchain-->>StateTransition: Return new state
StateTransition->>JavaJamRunner: Compare new state to expected post-state
JavaJamRunner-->>CLI: Report test results
Poem
🪧 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
Documentation and Community
|
…into maso-javajam-tests
DrEverr
marked this pull request as ready for review
July 14, 2025 19:31
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
Contributor
There was a problem hiding this comment.
Actionable comments posted: 2
🧹 Nitpick comments (2)
packages/jam/state/accumulation-output.ts (1)
3-4: Placeholder class - consider adding documentation for intended usage.This appears to be a placeholder class for future accumulation output functionality. Consider adding more detailed documentation about the intended purpose and structure of this class to guide future development.
packages/jam/state/block-state.ts (1)
25-30: Address the TODO: Define proper hash type for accumulation result.The TODO comment indicates that the correct hash type needs to be defined for
accumulationResult. This should be resolved to ensure type safety and clarity.Would you like me to help define the appropriate opaque hash type for the accumulation result, similar to how
StateRootHashandHeaderHashare defined?
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
Plan: Lite
⛔ Files ignored due to path filters (1)
package-lock.jsonis excluded by!**/package-lock.json
📒 Files selected for processing (22)
bin/test-runner/common.ts(4 hunks)bin/test-runner/index.ts(1 hunks)bin/test-runner/javajam.ts(1 hunks)bin/test-runner/package.json(2 hunks)bin/test-runner/state-transition/state-loader.ts(1 hunks)bin/test-runner/state-transition/state-transition.ts(1 hunks)bin/test-runner/w3f/accumulate.ts(4 hunks)packages/core/utils/compatibility.ts(1 hunks)packages/jam/block-json/common.ts(1 hunks)packages/jam/config/node/jip-chain-spec.ts(2 hunks)packages/jam/database/truncated-hash-dictionary.ts(2 hunks)packages/jam/jam-host-calls/externalities/state-update.ts(2 hunks)packages/jam/state-merkleization/serialize.ts(2 hunks)packages/jam/state/accumulation-output.ts(1 hunks)packages/jam/state/block-state.ts(1 hunks)packages/jam/state/privileged-services.ts(3 hunks)packages/jam/state/recent-blocks.ts(1 hunks)packages/jam/state/service.ts(4 hunks)packages/jam/state/state.ts(2 hunks)packages/jam/transition/accumulate/accumulate.ts(1 hunks)packages/jam/transition/recent-history.ts(3 hunks)packages/jam/transition/reports/verify-contextual.ts(5 hunks)
🧰 Additional context used
📓 Path-based instructions (2)
**/*.ts
Instructions used from:
Sources:
⚙️ CodeRabbit Configuration File
packages/core/**/*.ts
Instructions used from:
Sources:
⚙️ CodeRabbit Configuration File
🧠 Learnings (21)
📓 Common learnings
Learnt from: tomusdrw
PR: FluffyLabs/typeberry#351
File: packages/core/state-machine/channel.ts:131-137
Timestamp: 2025-04-24T19:44:58.110Z
Learning: The `doUntil` method in `MessageChannelStateMachine` was changed from using `Promise.all` to execute work and state transition concurrently, to using sequential awaits which ensures work completes before waiting for the state transition.
bin/test-runner/index.ts (1)
Learnt from: tomusdrw
PR: FluffyLabs/typeberry#399
File: .github/workflows/vectors-jamduna.yml:78-78
Timestamp: 2025-05-26T21:31:58.688Z
Learning: In the typeberry project, the npm start script in the test-runner workspace is designed to accept test suite names as arguments (e.g., "jamduna", "w3f"). The command `npm start -w @typeberry/test-runner jamduna` is the correct way to run the jamduna test suite, not `npm run jamduna`. This is an architectural design choice where the start script acts as a unified entry point for different test suites.
bin/test-runner/package.json (3)
Learnt from: tomusdrw
PR: FluffyLabs/typeberry#399
File: .github/workflows/vectors-jamduna.yml:78-78
Timestamp: 2025-05-26T21:31:58.688Z
Learning: In the typeberry project, the npm start script in the test-runner workspace is designed to accept test suite names as arguments (e.g., "jamduna", "w3f"). The command `npm start -w @typeberry/test-runner jamduna` is the correct way to run the jamduna test suite, not `npm run jamduna`. This is an architectural design choice where the start script acts as a unified entry point for different test suites.
Learnt from: tomusdrw
PR: FluffyLabs/typeberry#442
File: packages/core/pvm-debugger-adapter/index.ts:22-40
Timestamp: 2025-06-18T20:35:13.536Z
Learning: The `@typeberry/utils` package has browser compatibility issues due to Node.js-specific code like `measure` function using `process.hrtime()` and `testUtils` importing `node:assert`, causing white screens in browser environments.
Learnt from: tomusdrw
PR: FluffyLabs/typeberry#442
File: packages/core/pvm-debugger-adapter/index.ts:22-40
Timestamp: 2025-06-18T20:35:13.536Z
Learning: The `measure` function in `@typeberry/utils/debug.ts` attempts environment detection by checking `process === undefined` but still causes bundling issues because bundlers see the `process.hrtime` reference in the Node.js branch.
packages/jam/jam-host-calls/externalities/state-update.ts (2)
Learnt from: tomusdrw
PR: FluffyLabs/typeberry#419
File: packages/jam/state-merkleization/serialize-update.ts:115-126
Timestamp: 2025-06-10T12:10:10.532Z
Learning: In packages/jam/state-merkleization/serialize-update.ts, service removal is handled separately from service updates. The UpdateServiceKind enum does not include a Remove variant. Service removals are handled via the servicesRemoved parameter in serializeUpdate() which is processed by serializeRemovedServices(), while service updates/creations are handled via servicesUpdates parameter processed by serializeServiceUpdates().
Learnt from: tomusdrw
PR: FluffyLabs/typeberry#419
File: packages/jam/state/state-inmemory.ts:141-149
Timestamp: 2025-06-10T12:20:17.513Z
Learning: In the `InMemoryService.copyFrom` function in `packages/jam/state/state-inmemory.ts`, duplicate checking for `(hash, length)` pairs in the lookup history is not necessary because the function operates under the assumption that the input `ServiceEntries` comes from an existing well-formed state, which already maintains the invariant of unique lookup history entries per hash and length combination.
packages/jam/config/node/jip-chain-spec.ts (6)
Learnt from: tomusdrw
PR: FluffyLabs/typeberry#419
File: packages/jam/transition/accumulate/accumulate.ts:193-193
Timestamp: 2025-06-10T12:04:56.072Z
Learning: In the typeberry codebase, the Service.getPreimage() method was updated to return BytesBlob | null directly instead of PreimageItem | null, so the returned value is already a BytesBlob and doesn't need .blob property access.
Learnt from: tomusdrw
PR: FluffyLabs/typeberry#419
File: packages/jam/state/state-inmemory.ts:141-149
Timestamp: 2025-06-10T12:20:17.513Z
Learning: In the `InMemoryService.copyFrom` function in `packages/jam/state/state-inmemory.ts`, duplicate checking for `(hash, length)` pairs in the lookup history is not necessary because the function operates under the assumption that the input `ServiceEntries` comes from an existing well-formed state, which already maintains the invariant of unique lookup history entries per hash and length combination.
Learnt from: tomusdrw
PR: FluffyLabs/typeberry#351
File: packages/jam/state-merkleization/index.ts:19-37
Timestamp: 2025-04-24T19:48:31.051Z
Learning: In the typeberry codebase, `Bytes` inherits from `BytesBlob`, so a `Bytes` instance can be directly used where a `BytesBlob` is expected without needing conversion.
Learnt from: tomusdrw
PR: FluffyLabs/typeberry#419
File: packages/jam/state-merkleization/serialize-update.ts:115-126
Timestamp: 2025-06-10T12:10:10.532Z
Learning: In packages/jam/state-merkleization/serialize-update.ts, service removal is handled separately from service updates. The UpdateServiceKind enum does not include a Remove variant. Service removals are handled via the servicesRemoved parameter in serializeUpdate() which is processed by serializeRemovedServices(), while service updates/creations are handled via servicesUpdates parameter processed by serializeServiceUpdates().
Learnt from: tomusdrw
PR: FluffyLabs/typeberry#351
File: bin/jam/genesis.ts:7-11
Timestamp: 2025-04-24T19:42:18.083Z
Learning: Error handling for file operations and JSON parsing in the typeberry project is done at a higher level in the call stack rather than within individual utility functions.
Learnt from: tomusdrw
PR: FluffyLabs/typeberry#442
File: packages/core/pvm-debugger-adapter/index.ts:22-40
Timestamp: 2025-06-18T20:35:13.536Z
Learning: The `@typeberry/utils` package has browser compatibility issues due to Node.js-specific code like `measure` function using `process.hrtime()` and `testUtils` importing `node:assert`, causing white screens in browser environments.
packages/jam/transition/accumulate/accumulate.ts (3)
Learnt from: tomusdrw
PR: FluffyLabs/typeberry#419
File: packages/jam/state-merkleization/serialize-update.ts:115-126
Timestamp: 2025-06-10T12:10:10.532Z
Learning: In packages/jam/state-merkleization/serialize-update.ts, service removal is handled separately from service updates. The UpdateServiceKind enum does not include a Remove variant. Service removals are handled via the servicesRemoved parameter in serializeUpdate() which is processed by serializeRemovedServices(), while service updates/creations are handled via servicesUpdates parameter processed by serializeServiceUpdates().
Learnt from: tomusdrw
PR: FluffyLabs/typeberry#419
File: packages/jam/state/state-inmemory.ts:141-149
Timestamp: 2025-06-10T12:20:17.513Z
Learning: In the `InMemoryService.copyFrom` function in `packages/jam/state/state-inmemory.ts`, duplicate checking for `(hash, length)` pairs in the lookup history is not necessary because the function operates under the assumption that the input `ServiceEntries` comes from an existing well-formed state, which already maintains the invariant of unique lookup history entries per hash and length combination.
Learnt from: tomusdrw
PR: FluffyLabs/typeberry#351
File: packages/core/state-machine/channel.ts:131-137
Timestamp: 2025-04-24T19:44:58.110Z
Learning: The `doUntil` method in `MessageChannelStateMachine` was changed from using `Promise.all` to execute work and state transition concurrently, to using sequential awaits which ensures work completes before waiting for the state transition.
packages/jam/state/state.ts (3)
Learnt from: tomusdrw
PR: FluffyLabs/typeberry#419
File: packages/jam/state/state-inmemory.ts:141-149
Timestamp: 2025-06-10T12:20:17.513Z
Learning: In the `InMemoryService.copyFrom` function in `packages/jam/state/state-inmemory.ts`, duplicate checking for `(hash, length)` pairs in the lookup history is not necessary because the function operates under the assumption that the input `ServiceEntries` comes from an existing well-formed state, which already maintains the invariant of unique lookup history entries per hash and length combination.
Learnt from: tomusdrw
PR: FluffyLabs/typeberry#419
File: packages/jam/database-lmdb/states.test.ts:158-160
Timestamp: 2025-06-10T12:06:32.535Z
Learning: In test code, tomusdrw prefers pragmatic solutions over strict type safety when listing all entries would be cumbersome. Using `Object.assign({}, state)` for state updates in tests is acceptable even if it compromises type safety, prioritizing test maintainability and readability.
Learnt from: tomusdrw
PR: FluffyLabs/typeberry#419
File: packages/jam/state-merkleization/serialize-update.ts:115-126
Timestamp: 2025-06-10T12:10:10.532Z
Learning: In packages/jam/state-merkleization/serialize-update.ts, service removal is handled separately from service updates. The UpdateServiceKind enum does not include a Remove variant. Service removals are handled via the servicesRemoved parameter in serializeUpdate() which is processed by serializeRemovedServices(), while service updates/creations are handled via servicesUpdates parameter processed by serializeServiceUpdates().
packages/jam/state/privileged-services.ts (2)
Learnt from: tomusdrw
PR: FluffyLabs/typeberry#419
File: packages/jam/state-merkleization/serialize-update.ts:115-126
Timestamp: 2025-06-10T12:10:10.532Z
Learning: In packages/jam/state-merkleization/serialize-update.ts, service removal is handled separately from service updates. The UpdateServiceKind enum does not include a Remove variant. Service removals are handled via the servicesRemoved parameter in serializeUpdate() which is processed by serializeRemovedServices(), while service updates/creations are handled via servicesUpdates parameter processed by serializeServiceUpdates().
Learnt from: tomusdrw
PR: FluffyLabs/typeberry#419
File: packages/jam/state/state-inmemory.ts:141-149
Timestamp: 2025-06-10T12:20:17.513Z
Learning: In the `InMemoryService.copyFrom` function in `packages/jam/state/state-inmemory.ts`, duplicate checking for `(hash, length)` pairs in the lookup history is not necessary because the function operates under the assumption that the input `ServiceEntries` comes from an existing well-formed state, which already maintains the invariant of unique lookup history entries per hash and length combination.
packages/jam/transition/recent-history.ts (3)
Learnt from: tomusdrw
PR: FluffyLabs/typeberry#419
File: packages/jam/state/state-inmemory.ts:141-149
Timestamp: 2025-06-10T12:20:17.513Z
Learning: In the `InMemoryService.copyFrom` function in `packages/jam/state/state-inmemory.ts`, duplicate checking for `(hash, length)` pairs in the lookup history is not necessary because the function operates under the assumption that the input `ServiceEntries` comes from an existing well-formed state, which already maintains the invariant of unique lookup history entries per hash and length combination.
Learnt from: tomusdrw
PR: FluffyLabs/typeberry#419
File: packages/jam/state-merkleization/serialize-update.ts:115-126
Timestamp: 2025-06-10T12:10:10.532Z
Learning: In packages/jam/state-merkleization/serialize-update.ts, service removal is handled separately from service updates. The UpdateServiceKind enum does not include a Remove variant. Service removals are handled via the servicesRemoved parameter in serializeUpdate() which is processed by serializeRemovedServices(), while service updates/creations are handled via servicesUpdates parameter processed by serializeServiceUpdates().
Learnt from: tomusdrw
PR: FluffyLabs/typeberry#419
File: packages/jam/database-lmdb/states.test.ts:158-160
Timestamp: 2025-06-10T12:06:32.535Z
Learning: In test code, tomusdrw prefers pragmatic solutions over strict type safety when listing all entries would be cumbersome. Using `Object.assign({}, state)` for state updates in tests is acceptable even if it compromises type safety, prioritizing test maintainability and readability.
packages/jam/block-json/common.ts (2)
Learnt from: tomusdrw
PR: FluffyLabs/typeberry#419
File: packages/jam/transition/accumulate/accumulate.ts:193-193
Timestamp: 2025-06-10T12:04:56.072Z
Learning: In the typeberry codebase, the Service.getPreimage() method was updated to return BytesBlob | null directly instead of PreimageItem | null, so the returned value is already a BytesBlob and doesn't need .blob property access.
Learnt from: tomusdrw
PR: FluffyLabs/typeberry#351
File: packages/jam/state-merkleization/index.ts:19-37
Timestamp: 2025-04-24T19:48:31.051Z
Learning: In the typeberry codebase, `Bytes` inherits from `BytesBlob`, so a `Bytes` instance can be directly used where a `BytesBlob` is expected without needing conversion.
packages/jam/database/truncated-hash-dictionary.ts (1)
Learnt from: tomusdrw
PR: FluffyLabs/typeberry#419
File: packages/jam/state/state-inmemory.ts:141-149
Timestamp: 2025-06-10T12:20:17.513Z
Learning: In the `InMemoryService.copyFrom` function in `packages/jam/state/state-inmemory.ts`, duplicate checking for `(hash, length)` pairs in the lookup history is not necessary because the function operates under the assumption that the input `ServiceEntries` comes from an existing well-formed state, which already maintains the invariant of unique lookup history entries per hash and length combination.
bin/test-runner/w3f/accumulate.ts (4)
Learnt from: tomusdrw
PR: FluffyLabs/typeberry#419
File: packages/jam/database-lmdb/states.test.ts:158-160
Timestamp: 2025-06-10T12:06:32.535Z
Learning: In test code, tomusdrw prefers pragmatic solutions over strict type safety when listing all entries would be cumbersome. Using `Object.assign({}, state)` for state updates in tests is acceptable even if it compromises type safety, prioritizing test maintainability and readability.
Learnt from: tomusdrw
PR: FluffyLabs/typeberry#419
File: packages/jam/state-merkleization/serialize-update.ts:115-126
Timestamp: 2025-06-10T12:10:10.532Z
Learning: In packages/jam/state-merkleization/serialize-update.ts, service removal is handled separately from service updates. The UpdateServiceKind enum does not include a Remove variant. Service removals are handled via the servicesRemoved parameter in serializeUpdate() which is processed by serializeRemovedServices(), while service updates/creations are handled via servicesUpdates parameter processed by serializeServiceUpdates().
Learnt from: tomusdrw
PR: FluffyLabs/typeberry#419
File: packages/jam/state/state-inmemory.ts:141-149
Timestamp: 2025-06-10T12:20:17.513Z
Learning: In the `InMemoryService.copyFrom` function in `packages/jam/state/state-inmemory.ts`, duplicate checking for `(hash, length)` pairs in the lookup history is not necessary because the function operates under the assumption that the input `ServiceEntries` comes from an existing well-formed state, which already maintains the invariant of unique lookup history entries per hash and length combination.
Learnt from: tomusdrw
PR: FluffyLabs/typeberry#351
File: bin/jam/genesis.ts:7-11
Timestamp: 2025-04-24T19:42:18.083Z
Learning: Error handling for file operations and JSON parsing in the typeberry project is done at a higher level in the call stack rather than within individual utility functions.
bin/test-runner/state-transition/state-loader.ts (2)
Learnt from: tomusdrw
PR: FluffyLabs/typeberry#419
File: packages/jam/database-lmdb/states.test.ts:158-160
Timestamp: 2025-06-10T12:06:32.535Z
Learning: In test code, tomusdrw prefers pragmatic solutions over strict type safety when listing all entries would be cumbersome. Using `Object.assign({}, state)` for state updates in tests is acceptable even if it compromises type safety, prioritizing test maintainability and readability.
Learnt from: tomusdrw
PR: FluffyLabs/typeberry#419
File: packages/jam/state/state-inmemory.ts:141-149
Timestamp: 2025-06-10T12:20:17.513Z
Learning: In the `InMemoryService.copyFrom` function in `packages/jam/state/state-inmemory.ts`, duplicate checking for `(hash, length)` pairs in the lookup history is not necessary because the function operates under the assumption that the input `ServiceEntries` comes from an existing well-formed state, which already maintains the invariant of unique lookup history entries per hash and length combination.
packages/jam/transition/reports/verify-contextual.ts (2)
Learnt from: tomusdrw
PR: FluffyLabs/typeberry#419
File: packages/jam/state/state-inmemory.ts:141-149
Timestamp: 2025-06-10T12:20:17.513Z
Learning: In the `InMemoryService.copyFrom` function in `packages/jam/state/state-inmemory.ts`, duplicate checking for `(hash, length)` pairs in the lookup history is not necessary because the function operates under the assumption that the input `ServiceEntries` comes from an existing well-formed state, which already maintains the invariant of unique lookup history entries per hash and length combination.
Learnt from: tomusdrw
PR: FluffyLabs/typeberry#419
File: packages/jam/state-merkleization/serialize-update.ts:115-126
Timestamp: 2025-06-10T12:10:10.532Z
Learning: In packages/jam/state-merkleization/serialize-update.ts, service removal is handled separately from service updates. The UpdateServiceKind enum does not include a Remove variant. Service removals are handled via the servicesRemoved parameter in serializeUpdate() which is processed by serializeRemovedServices(), while service updates/creations are handled via servicesUpdates parameter processed by serializeServiceUpdates().
packages/jam/state/recent-blocks.ts (1)
Learnt from: tomusdrw
PR: FluffyLabs/typeberry#419
File: packages/jam/state/state-inmemory.ts:141-149
Timestamp: 2025-06-10T12:20:17.513Z
Learning: In the `InMemoryService.copyFrom` function in `packages/jam/state/state-inmemory.ts`, duplicate checking for `(hash, length)` pairs in the lookup history is not necessary because the function operates under the assumption that the input `ServiceEntries` comes from an existing well-formed state, which already maintains the invariant of unique lookup history entries per hash and length combination.
bin/test-runner/common.ts (2)
Learnt from: tomusdrw
PR: FluffyLabs/typeberry#399
File: .github/workflows/vectors-jamduna.yml:78-78
Timestamp: 2025-05-26T21:31:58.688Z
Learning: In the typeberry project, the npm start script in the test-runner workspace is designed to accept test suite names as arguments (e.g., "jamduna", "w3f"). The command `npm start -w @typeberry/test-runner jamduna` is the correct way to run the jamduna test suite, not `npm run jamduna`. This is an architectural design choice where the start script acts as a unified entry point for different test suites.
Learnt from: tomusdrw
PR: FluffyLabs/typeberry#419
File: packages/jam/database-lmdb/states.test.ts:158-160
Timestamp: 2025-06-10T12:06:32.535Z
Learning: In test code, tomusdrw prefers pragmatic solutions over strict type safety when listing all entries would be cumbersome. Using `Object.assign({}, state)` for state updates in tests is acceptable even if it compromises type safety, prioritizing test maintainability and readability.
packages/jam/state/service.ts (5)
Learnt from: tomusdrw
PR: FluffyLabs/typeberry#419
File: packages/jam/state-merkleization/serialize-update.ts:115-126
Timestamp: 2025-06-10T12:10:10.532Z
Learning: In packages/jam/state-merkleization/serialize-update.ts, service removal is handled separately from service updates. The UpdateServiceKind enum does not include a Remove variant. Service removals are handled via the servicesRemoved parameter in serializeUpdate() which is processed by serializeRemovedServices(), while service updates/creations are handled via servicesUpdates parameter processed by serializeServiceUpdates().
Learnt from: tomusdrw
PR: FluffyLabs/typeberry#419
File: packages/jam/state/state-inmemory.ts:141-149
Timestamp: 2025-06-10T12:20:17.513Z
Learning: In the `InMemoryService.copyFrom` function in `packages/jam/state/state-inmemory.ts`, duplicate checking for `(hash, length)` pairs in the lookup history is not necessary because the function operates under the assumption that the input `ServiceEntries` comes from an existing well-formed state, which already maintains the invariant of unique lookup history entries per hash and length combination.
Learnt from: tomusdrw
PR: FluffyLabs/typeberry#419
File: packages/jam/transition/accumulate/accumulate.ts:193-193
Timestamp: 2025-06-10T12:04:56.072Z
Learning: In the typeberry codebase, the Service.getPreimage() method was updated to return BytesBlob | null directly instead of PreimageItem | null, so the returned value is already a BytesBlob and doesn't need .blob property access.
Learnt from: tomusdrw
PR: FluffyLabs/typeberry#442
File: packages/core/pvm-debugger-adapter/index.ts:22-40
Timestamp: 2025-06-18T20:35:13.536Z
Learning: The `@typeberry/utils` package has browser compatibility issues due to Node.js-specific code like `measure` function using `process.hrtime()` and `testUtils` importing `node:assert`, causing white screens in browser environments.
Learnt from: tomusdrw
PR: FluffyLabs/typeberry#351
File: packages/jam/state-merkleization/index.ts:19-37
Timestamp: 2025-04-24T19:48:31.051Z
Learning: In the typeberry codebase, `Bytes` inherits from `BytesBlob`, so a `Bytes` instance can be directly used where a `BytesBlob` is expected without needing conversion.
bin/test-runner/state-transition/state-transition.ts (2)
Learnt from: tomusdrw
PR: FluffyLabs/typeberry#419
File: packages/jam/database-lmdb/states.test.ts:158-160
Timestamp: 2025-06-10T12:06:32.535Z
Learning: In test code, tomusdrw prefers pragmatic solutions over strict type safety when listing all entries would be cumbersome. Using `Object.assign({}, state)` for state updates in tests is acceptable even if it compromises type safety, prioritizing test maintainability and readability.
Learnt from: tomusdrw
PR: FluffyLabs/typeberry#419
File: packages/jam/state/state-inmemory.ts:141-149
Timestamp: 2025-06-10T12:20:17.513Z
Learning: In the `InMemoryService.copyFrom` function in `packages/jam/state/state-inmemory.ts`, duplicate checking for `(hash, length)` pairs in the lookup history is not necessary because the function operates under the assumption that the input `ServiceEntries` comes from an existing well-formed state, which already maintains the invariant of unique lookup history entries per hash and length combination.
packages/jam/state-merkleization/serialize.ts (2)
Learnt from: tomusdrw
PR: FluffyLabs/typeberry#419
File: packages/jam/state-merkleization/serialize-update.ts:115-126
Timestamp: 2025-06-10T12:10:10.532Z
Learning: In packages/jam/state-merkleization/serialize-update.ts, service removal is handled separately from service updates. The UpdateServiceKind enum does not include a Remove variant. Service removals are handled via the servicesRemoved parameter in serializeUpdate() which is processed by serializeRemovedServices(), while service updates/creations are handled via servicesUpdates parameter processed by serializeServiceUpdates().
Learnt from: tomusdrw
PR: FluffyLabs/typeberry#419
File: packages/jam/state/state-inmemory.ts:141-149
Timestamp: 2025-06-10T12:20:17.513Z
Learning: In the `InMemoryService.copyFrom` function in `packages/jam/state/state-inmemory.ts`, duplicate checking for `(hash, length)` pairs in the lookup history is not necessary because the function operates under the assumption that the input `ServiceEntries` comes from an existing well-formed state, which already maintains the invariant of unique lookup history entries per hash and length combination.
bin/test-runner/javajam.ts (2)
Learnt from: tomusdrw
PR: FluffyLabs/typeberry#399
File: .github/workflows/vectors-jamduna.yml:78-78
Timestamp: 2025-05-26T21:31:58.688Z
Learning: In the typeberry project, the npm start script in the test-runner workspace is designed to accept test suite names as arguments (e.g., "jamduna", "w3f"). The command `npm start -w @typeberry/test-runner jamduna` is the correct way to run the jamduna test suite, not `npm run jamduna`. This is an architectural design choice where the start script acts as a unified entry point for different test suites.
Learnt from: tomusdrw
PR: FluffyLabs/typeberry#419
File: packages/jam/database-lmdb/states.test.ts:158-160
Timestamp: 2025-06-10T12:06:32.535Z
Learning: In test code, tomusdrw prefers pragmatic solutions over strict type safety when listing all entries would be cumbersome. Using `Object.assign({}, state)` for state updates in tests is acceptable even if it compromises type safety, prioritizing test maintainability and readability.
packages/jam/state/block-state.ts (2)
Learnt from: tomusdrw
PR: FluffyLabs/typeberry#419
File: packages/jam/state-merkleization/serialize-update.ts:115-126
Timestamp: 2025-06-10T12:10:10.532Z
Learning: In packages/jam/state-merkleization/serialize-update.ts, service removal is handled separately from service updates. The UpdateServiceKind enum does not include a Remove variant. Service removals are handled via the servicesRemoved parameter in serializeUpdate() which is processed by serializeRemovedServices(), while service updates/creations are handled via servicesUpdates parameter processed by serializeServiceUpdates().
Learnt from: tomusdrw
PR: FluffyLabs/typeberry#419
File: packages/jam/state/state-inmemory.ts:141-149
Timestamp: 2025-06-10T12:20:17.513Z
Learning: In the `InMemoryService.copyFrom` function in `packages/jam/state/state-inmemory.ts`, duplicate checking for `(hash, length)` pairs in the lookup history is not necessary because the function operates under the assumption that the input `ServiceEntries` comes from an existing well-formed state, which already maintains the invariant of unique lookup history entries per hash and length combination.
🧬 Code Graph Analysis (13)
packages/jam/jam-host-calls/externalities/state-update.ts (2)
packages/jam/state/common.ts (1)
PerCore(8-8)bin/rpc/src/types.ts (2)
ServiceId(93-93)ServiceId(100-100)
packages/jam/state/state.ts (1)
packages/jam/state/recent-blocks.ts (1)
RecentBlocks(11-35)
packages/jam/state/privileged-services.ts (2)
packages/jam/state/common.ts (2)
codecPerCore(17-20)PerCore(8-8)packages/jam/block/common.ts (1)
ServiceId(26-26)
packages/jam/transition/recent-history.ts (2)
packages/jam/state-merkleization/serialize.ts (1)
recentBlocks(65-69)packages/core/collections/sized-array.ts (1)
asKnownSize(13-15)
packages/jam/block-json/common.ts (1)
packages/core/bytes/bytes.ts (2)
Bytes(152-218)BytesBlob(10-147)
packages/jam/database/truncated-hash-dictionary.ts (1)
packages/core/bytes/bytes.ts (1)
Bytes(152-218)
bin/test-runner/w3f/accumulate.ts (2)
packages/jam/state/common.ts (1)
tryAsPerCore(10-16)packages/jam/block/common.ts (1)
tryAsServiceId(28-28)
bin/test-runner/state-transition/state-loader.ts (5)
packages/core/bytes/bytes.ts (2)
Bytes(152-218)BytesBlob(10-147)packages/jam/block/common.ts (1)
StateRootHash(43-43)packages/jam/database/truncated-hash-dictionary.ts (1)
TruncatedHashDictionary(15-76)packages/jam/state-merkleization/state-entries.ts (1)
StateEntries(31-107)packages/jam/state-merkleization/serialized-state.ts (1)
SerializedState(38-172)
packages/jam/transition/reports/verify-contextual.ts (5)
packages/core/mmr/index.ts (1)
MmrHasher(17-22)packages/core/hash/hash.ts (1)
KeccakHash(20-20)packages/jam/state-merkleization/serialize.ts (1)
recentBlocks(65-69)packages/core/collections/hash-dictionary.ts (1)
HashDictionary(24-98)packages/jam/state/block-state.ts (1)
BlockState(10-38)
packages/jam/state/recent-blocks.ts (7)
packages/jam/block/codec.ts (1)
codecKnownSizeArray(47-57)packages/jam/state/block-state.ts (1)
BlockState(10-38)packages/jam/state/state.ts (2)
MAX_RECENT_HISTORY(40-40)MAX_RECENT_HISTORY(41-41)packages/core/codec/descriptors.ts (2)
readonlyArray(121-131)CodecRecord(139-141)packages/core/collections/sized-array.ts (1)
KnownSizeArray(10-10)packages/core/mmr/index.ts (1)
MmrPeaks(7-14)packages/core/hash/hash.ts (1)
KeccakHash(20-20)
packages/jam/state/service.ts (3)
packages/jam/block/common.ts (4)
tryAsTimeSlot(18-18)tryAsServiceId(28-28)TimeSlot(16-16)ServiceId(26-26)packages/core/numbers/index.ts (2)
U64(27-27)U32(24-24)bin/rpc/src/types.ts (2)
ServiceId(93-93)ServiceId(100-100)
packages/jam/state-merkleization/serialize.ts (1)
packages/jam/state/recent-blocks.ts (1)
RecentBlocks(11-35)
packages/jam/state/block-state.ts (5)
packages/jam/block/common.ts (1)
StateRootHash(43-43)packages/jam/block/codec.ts (1)
codecHashDictionary(87-134)packages/jam/block/work-report.ts (1)
WorkPackageInfo(59-77)packages/core/codec/descriptors.ts (1)
CodecRecord(139-141)packages/core/hash/hash.ts (1)
OpaqueHash(14-14)
🔇 Additional comments (34)
packages/core/utils/compatibility.ts (1)
8-8: Version update looks good.The update from V0_6_4 to V0_6_7 aligns with the broader changes in this PR. The logic and validation remain unchanged.
packages/jam/block-json/common.ts (2)
7-11: Well-structured generic byte parsers.The new
bytesNandbytesNNoPrefixfunctions provide flexible byte parsing for arbitrary lengths while maintaining type safety. The generic type parameters with appropriate defaults are well-designed.
18-20: Consistent prefix handling improvements.The change to use
BytesBlob.parseBlobforbytesBloband the addition ofbytesBlobNoPrefixprovide clearer separation between prefix and no-prefix parsing variants.bin/test-runner/index.ts (1)
16-16: Test suite addition looks good.The new "javajam" suite entry follows the established pattern and integrates well with the existing test infrastructure.
bin/test-runner/package.json (2)
20-20: New dependency addition is appropriate.The
@typeberry/database-lmdbdependency supports the new state loading and storage utilities for the javajam test runner. The version is consistent with other typeberry packages.
37-37: Script addition follows established pattern.The new "javajam" script follows the same pattern as the existing test runners and integrates well with the test infrastructure.
packages/jam/jam-host-calls/externalities/state-update.ts (2)
9-9: Import addition for per-core type is correct.The
PerCoreimport is necessary to support the new per-core authorization model.
125-125: Type change aligns with per-core authorization model.The change from
ServiceIdtoPerCore<ServiceId>for the authorizer property correctly reflects the architectural shift to per-core authorization managers, as mentioned in the AI summary.packages/jam/transition/accumulate/accumulate.ts (1)
425-425: Correct adaptation to multi-core authorization managers.The change from checking a single
authManagerto using.some()with an array correctly adapts to the newPerCore<ServiceId>structure for authorization managers. The logic maintains the same semantic meaning while supporting multiple authorization managers per core.packages/jam/state/state.ts (2)
13-13: Updated import to support new RecentBlocks structure.The import change from
BlockStatetoRecentBlocksaligns with the structural refactoring of recent blocks representation.
140-140: Improved state structure with RecentBlocks encapsulation.The change from
KnownSizeArray<BlockState, ...>toRecentBlocksrepresents a well-designed structural improvement. The newRecentBlocksclass encapsulates both the blocks array and MMR structure, providing a richer data model while maintaining access to the blocks through theblocksproperty.packages/jam/config/node/jip-chain-spec.ts (2)
2-2: Appropriate use of type-only import.The change to a type-only import for
Bytesis correct since it's only used for type annotations in this file.
69-69: Simplified JSON deserialization with specialized utility functions.The change from custom parsing logic to using
fromJson.bytesNNoPrefix(31)andfromJson.bytesBlobNoPrefiximproves code clarity and maintainability. The specialized utility functions provide more declarative and consistent parsing behavior.packages/jam/state-merkleization/serialize.ts (2)
30-30: Updated import to align with RecentBlocks refactoring.The import change from
BlockStateandMAX_RECENT_HISTORYtoRecentBlocksis consistent with the broader refactoring of recent blocks representation.
67-67: Cleaner serialization using RecentBlocks.Codec.The change from manually constructing a known-size array codec to using
RecentBlocks.Codecis a cleaner approach. TheRecentBlocks.Codechandles the serialization of both the blocks array and MMR structure internally, providing better encapsulation and maintainability.packages/jam/transition/reports/verify-contextual.ts (3)
88-88: LGTM! Consistent with theRecentBlocksstructural refactoring.The updates to access
state.recentBlocks.blocksalign with the broader refactoring whererecentBlocksis now aRecentBlocksobject containing ablocksarray.Also applies to: 142-143, 281-282
137-137: Good practice: Unused parameter marked with underscore prefix.The
_hashernaming convention clearly indicates the parameter is currently unused.
169-176: Verify: Is the MMR validation removal temporary?The BEEFY super peak hash verification has been disabled. This removes an important validation step that ensures the integrity of the MMR structure.
Is this a temporary change as part of the ongoing refactoring, or is the MMR validation being permanently removed? If permanent, please ensure that validation is handled elsewhere or document why it's no longer needed.
packages/jam/state/privileged-services.ts (1)
3-3: Well-implemented per-core structure forauthManager.The change from a single
ServiceIdtoPerCore<ServiceId>is consistently implemented across imports, codec, and property declaration. This aligns with the broader architectural shift to support per-core authorization management.Also applies to: 30-30, 47-47
bin/test-runner/javajam.ts (1)
1-14: LGTM! Clean implementation of the JavaJam test runner.The new test runner follows the established pattern and is properly configured to handle state transition tests. The error handling and logging are appropriate.
packages/jam/database/truncated-hash-dictionary.ts (1)
38-41: Excellent additions to complete the dictionary interface.The new
size,has, andvaluesmethods provide essential dictionary functionality:
sizegetter properly delegates to the underlying dictionaryhasmethod correctly applies the same truncation logic as other methodsvaluesiterator enables standard iteration patternsThese additions make
TruncatedHashDictionarya more complete and usable collection.Also applies to: 49-54, 68-71
packages/jam/transition/recent-history.ts (2)
43-43: Properly adapted to the newRecentBlocksstructure.The changes correctly handle the new state structure where:
recentBlocksis now an object withblocksarray andmmrfieldaccumulationResultreplaces themmrproperty inBlockState- The return value preserves the existing MMR data unchanged
Also applies to: 61-61, 72-75
50-56: Consistent with MMR handling changes across the codebase.The MMR construction and update logic has been disabled, matching the pattern seen in
verify-contextual.ts. The code now simply stores theaccumulateRootasaccumulationResultwithout active MMR manipulation.Please confirm that this simplified approach to MMR handling is intentional and that MMR data integrity is maintained through other means in the system.
bin/test-runner/w3f/accumulate.ts (3)
9-9: Import addition looks good.The
tryAsPerCoreimport is correctly added to support the new per-core authorization management functionality.
41-41: Consistent type change from single to array.The change from
assign: numbertoassign: number[]is correctly implemented in both the JSON parsing schema and type definition, supporting the shift to per-core authorization management.Also applies to: 59-59
85-88: Well-implemented per-core authorization management.The change correctly maps the array of assign privileges to per-core ServiceIds using
tryAsPerCorewith proper validation against the chain specification.packages/jam/state/recent-blocks.ts (1)
10-35: Well-implemented class following coding guidelines.The
RecentBlocksclass correctly follows the TypeScript coding guidelines with:
- Static
Codecfield for serialization/deserialization- Private constructor ensuring controlled instantiation
- Static
createmethod for object creation- Proper type definitions and constraints on array sizes
- Appropriate use of
WithDebugextensionThe implementation properly encapsulates recent blocks history with MMR data structure.
bin/test-runner/state-transition/state-loader.ts (2)
9-16: Clean data class implementation.The
KeyValclass is properly implemented with appropriate JSON parsing schema for 31-byte keys and variable-length blob values.
18-35: Proper state loading utility implementation.The
TestStateclass andloadStatefunction are correctly implemented:
- Clear JSON parsing schema for state representation
- Efficient conversion from key-value pairs to truncated hash dictionary
- Proper use of
StateEntries.fromTruncatedDictionaryUnsafefor state creation- Clean separation of concerns between parsing and state construction
packages/jam/state/service.ts (3)
48-48: Proper codec field additions.The new codec fields are correctly implemented:
storageOffsetuses appropriateu64typecreationandlastAccumulationproperly convertu32toTimeSlotparentServiceproperly convertsu32toServiceIdAll type conversions follow established patterns in the codebase.
Also applies to: 51-53
62-62: Consistent create method updates.The static
createmethod correctly includes all new fields and passes them to the constructor in the proper order, maintaining consistency with the codec definition.Also applies to: 65-67
96-107: Well-documented constructor parameters.The new constructor parameters are properly implemented with:
- Appropriate types (
U64,TimeSlot,ServiceId)- Clear JSDoc documentation explaining each field's purpose
- Consistent formatting with existing parameters
bin/test-runner/common.ts (1)
44-44: Good variable naming and clarity improvements.The variable renaming and comment updates improve code readability:
files→testFilesfor better clarity- More descriptive variable names in test aggregation (
testGroupName,testRunners,batchSize)- Clearer comments without changing functionality
These changes enhance maintainability while preserving all existing behavior.
Also applies to: 47-47, 50-51, 80-98
bin/test-runner/state-transition/state-transition.ts (1)
50-50: Sorting by timeSlotIndex is safe as implemented.The
TimeSlottype is an opaque alias overU32(anumber), so at runtime it’s just anumber. Subtraction in the sort comparator will work correctly; no special bigint handling is needed.No changes required for the sort on line 50.
DrEverr
force-pushed
the
maso-javajam-tests
branch
from
July 14, 2025 21:08
61d29ab to
3b90b96
Compare
tomusdrw
reviewed
Jul 14, 2025
tomusdrw
left a comment
tomusdrw
left a comment
Member
There was a problem hiding this comment.
Would be good to add GHA workflow to run the tests (even though they are skipped). That way we will be able to merge that PR into main and proceed with tests one-by-one.
Co-authored-by: Tomek Drwięga <tomusdrw@users.noreply.github.com>
…into maso-javajam-tests
tomusdrw
approved these changes
Jul 14, 2025
tomusdrw
enabled auto-merge (squash)
July 16, 2025 22:55
View all
Benchmarks summary: 63/63 OK ✅ |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
No description provided.