fix: incorrect timestamps #58
Conversation
📝 WalkthroughWalkthroughThe provided changes introduce a new type alias The modifications span various components of the system, including pricing providers, event processors, repositories, and shared types. The changes consistently replace generic The changes are comprehensive and systematic, touching multiple layers of the application to ensure consistent timestamp handling across different modules and components. 📜 Recent review detailsConfiguration used: CodeRabbit UI 📒 Files selected for processing (5)
🚧 Files skipped from review as they are similar to previous changes (5)
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 6
🔭 Outside diff range comments (1)
packages/pricing/src/providers/coingecko.provider.ts (1)
Line range hint
147-147: Update getTokenPrices method to use TimestampMs type.For consistency with the PR objectives and the getTokenPrice method, the timestamps parameter should use the TimestampMs type.
Apply this diff to update the method signature:
- async getTokenPrices(tokenCode: TokenCode, timestamps: number[]): Promise<TokenPrice[]> { + async getTokenPrices(tokenCode: TokenCode, timestamps: TimestampMs[]): Promise<TokenPrice[]> {
🧹 Nitpick comments (12)
packages/shared/src/types/common.ts (1)
8-9: Well-designed type for timestamp safety!The introduction of
TimestampMsas a branded type is an excellent choice for preventing accidental mixing of timestamp units. This type-level distinction between seconds and milliseconds will catch potential conversion errors at compile time.Consider adding runtime validation functions like:
export const toTimestampMs = (seconds: number): TimestampMs => (seconds * 1000) as TimestampMs; export const isTimestampMs = (value: number): value is TimestampMs => value > 1e12;packages/pricing/src/types/pricing.types.ts (1)
1-8: Enhance JSDoc documentation for timestampMs.While the type change is correct, the documentation could be more specific about the timestamp format.
Consider updating the JSDoc to:
/** * @property timestampMs - Unix timestamp in milliseconds (e.g., 1704067241331) * @property priceUsd - The price in USD */packages/processors/src/interfaces/strategyHandler.interface.ts (1)
Line range hint
33-37: Update JSDoc to specify timestamp unit.The documentation should explicitly mention that
blockTimestampis in milliseconds to prevent future confusion./** * Fetch the match amount for a strategy * @param matchingFundsAvailable - The matching funds available * @param token - The token - * @param blockTimestamp - The block timestamp + * @param blockTimestamp - The block timestamp in milliseconds * @returns The match amount and match amount in USD */Also applies to: 46-46
packages/processors/test/registry/handlers/profileNameUpdated.handler.spec.ts (1)
19-19: Use a realistic timestamp value in tests.Using
1 as TimestampMsis unrealistic for a timestamp in milliseconds. Consider using a more representative value to catch potential timestamp-related issues in tests.- blockTimestamp: 1 as TimestampMs, + blockTimestamp: 1704067241331 as TimestampMs, // Jan 1, 2024 00:00:41.331 GMTpackages/processors/src/helpers/pricing.ts (1)
20-22: Update JSDoc to document TimestampMs type requirementThe function parameters have been updated to use
TimestampMs, but the JSDoc comments don't reflect this change. Update the documentation to clarify that timestamps should be in milliseconds.Apply this diff to update the documentation:
/** * Get the amount in USD for a given amount in the token * @param pricingProvider - The pricing provider to use * @param token - The token to get the amount in * @param amount - The amount in the token - * @param timestamp - The timestamp to get the price at + * @param timestamp - The timestamp in milliseconds to get the price at + * @param timestampEnd - Optional end timestamp in milliseconds for price range * @returns The amount in USD * @throws TokenPriceNotFoundError if the price is not found */packages/shared/src/types/events/common.ts (1)
56-56: Document TimestampMs requirement in type definitionThe
blockTimestampfield has been updated to useTimestampMs, but there's no documentation indicating that this should be in milliseconds.Apply this diff to add documentation:
- blockTimestamp: TimestampMs; + /** Timestamp in milliseconds when the block was mined */ + blockTimestamp: TimestampMs;packages/data-flow/test/unit/eventsFetcher.spec.ts (1)
31-31: Add test cases for timestamp validation.While the timestamps are correctly in milliseconds, consider adding test cases that explicitly verify the handling of timestamps in seconds vs milliseconds to prevent future regressions.
it("fetches events by block number and log index", async () => { + // Add test cases for different timestamp formats + const timestampInSeconds = 123123123; + const timestampInMs = timestampInSeconds * 1000; + const mockEventsWithDifferentTimestamps: AnyIndexerFetchedEvent[] = [ + { + ...mockEvents[0], + blockTimestamp: timestampInMs as TimestampMs, + }, + ];Also applies to: 46-46
packages/data-flow/test/unit/eventsProcessor.spec.ts (1)
106-106: Document the significance of the timestamp value.The timestamp
1704067241331appears to be a specific point in time. Consider adding a comment explaining its significance or using a more meaningful constant.- blockTimestamp: 1704067241331 as TimestampMs, + // January 1, 2024, 00:00:41.331 UTC + blockTimestamp: 1704067241331 as TimestampMs,packages/pricing/test/providers/cachingProxy.provider.spec.ts (1)
40-41: Use more meaningful test timestamps.Consider using timestamps that correspond to specific dates to make the tests more readable and maintainable.
- const testStartTime = 1234567890000 as TimestampMs; - const testEndTime = 1234567899999 as TimestampMs; + // 2009-02-13T23:31:30.000Z + const testStartTime = 1234567890000 as TimestampMs; + // 2009-02-13T23:31:39.999Z + const testEndTime = 1234567899999 as TimestampMs;packages/pricing/src/providers/coingecko.provider.ts (1)
108-108: Add type safety for TIME_DELTA constant.The TIME_DELTA constant is correctly defined in milliseconds, but the addition operation needs type safety.
Apply this diff to improve type safety:
-const TIME_DELTA = 2 * 60 * 60 * 1000; +const TIME_DELTA = 2 * 60 * 60 * 1000 as const;packages/indexer-client/src/providers/envioIndexerClient.ts (1)
246-249: Avoid code duplication in timestamp conversion.The timestamp conversion logic is duplicated between
getEventsAfterBlockNumberAndLogIndexandgetEventsmethods.Consider extracting the conversion logic into a private method:
+private convertTimestampsToMs(events: AnyIndexerFetchedEvent[]): void { + events.forEach((event) => { + event.blockTimestamp = (event.blockTimestamp * 1000) as TimestampMs; + }); +} public async getEventsAfterBlockNumberAndLogIndex({ // ... }) { // ... if (events) { - events.forEach((event) => { - event.blockTimestamp = (event.blockTimestamp * 1000) as TimestampMs; - }); + this.convertTimestampsToMs(events); // ... } } async getEvents(params: GetEventsFilters): Promise<AnyIndexerFetchedEvent[]> { // ... if (response?.raw_events) { - response.raw_events.forEach((event) => { - event.blockTimestamp = (event.blockTimestamp * 1000) as TimestampMs; - }); + this.convertTimestampsToMs(response.raw_events); return response.raw_events; } }packages/data-flow/src/orchestrator.ts (1)
28-28: LGTM! Consider adding JSDoc for TokenWithTimestamps.The change to use
TimestampMs[]inTokenWithTimestampsimproves type safety. Consider adding JSDoc to document the type's purpose and the format of timestamps.+/** + * Represents a token with its associated timestamps in milliseconds. + */ type TokenWithTimestamps = { token: Token; timestamps: TimestampMs[]; };Also applies to: 40-40
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (41)
packages/data-flow/src/orchestrator.ts(2 hunks)packages/data-flow/test/unit/eventsFetcher.spec.ts(3 hunks)packages/data-flow/test/unit/eventsProcessor.spec.ts(2 hunks)packages/data-flow/test/unit/orchestrator.spec.ts(2 hunks)packages/data-flow/test/unit/retroactiveProcessor.spec.ts(2 hunks)packages/indexer-client/src/providers/envioIndexerClient.ts(3 hunks)packages/indexer-client/test/unit/envioIndexerClient.spec.ts(6 hunks)packages/pricing/README.md(1 hunks)packages/pricing/src/interfaces/pricing.interface.ts(3 hunks)packages/pricing/src/providers/cachingProxy.provider.ts(6 hunks)packages/pricing/src/providers/coingecko.provider.ts(4 hunks)packages/pricing/src/providers/dummy.provider.ts(3 hunks)packages/pricing/src/types/coingecko.types.ts(2 hunks)packages/pricing/src/types/pricing.types.ts(1 hunks)packages/pricing/test/providers/cachingProxy.provider.spec.ts(2 hunks)packages/pricing/test/providers/coingecko.provider.spec.ts(9 hunks)packages/pricing/test/providers/dummy.provider.spec.ts(2 hunks)packages/processors/src/helpers/pricing.ts(3 hunks)packages/processors/src/interfaces/strategyHandler.interface.ts(2 hunks)packages/processors/src/processors/allo/handlers/poolCreated.handler.ts(2 hunks)packages/processors/src/processors/strategy/common/base.strategy.ts(2 hunks)packages/processors/src/processors/strategy/donationVotingMerkleDistributionDirectTransfer/dvmdDirectTransfer.handler.ts(3 hunks)packages/processors/test/allo/handlers/poolCreated.handler.spec.ts(7 hunks)packages/processors/test/allo/handlers/poolFunded.handler.spec.ts(3 hunks)packages/processors/test/allo/handlers/poolMetadataUpdated.handler.spec.ts(3 hunks)packages/processors/test/allo/handlers/roleGranted.handler.spec.ts(2 hunks)packages/processors/test/allo/handlers/roleRevoked.handler.spec.ts(2 hunks)packages/processors/test/mocks/event.mock.ts(3 hunks)packages/processors/test/registry/handlers/profileCreated.handler.spec.ts(2 hunks)packages/processors/test/registry/handlers/profileNameUpdated.handler.spec.ts(2 hunks)packages/processors/test/registry/handlers/profileOwnerUpdated.handler.spec.ts(1 hunks)packages/processors/test/strategy/common/base.strategy.spec.ts(2 hunks)packages/processors/test/strategy/directGrantsLite/handlers/allocated.handler.spec.ts(3 hunks)packages/processors/test/strategy/donationVotingMerkleDistributionDirectTransfer/dvmdDirectTransfer.handler.spec.ts(3 hunks)packages/processors/test/strategy/donationVotingMerkleDistributionDirectTransfer/handlers/allocated.handler.spec.ts(5 hunks)packages/repository/src/repositories/kysely/prices.repository.ts(4 hunks)packages/shared/src/tokens/tokens.ts(2 hunks)packages/shared/src/types/common.ts(1 hunks)packages/shared/src/types/events/common.ts(2 hunks)scripts/migrations/src/migrations/20241216T160549_event_registry.ts(1 hunks)scripts/migrations/src/migrations/20250127T000000_add_cache_tables.ts(1 hunks)
✅ Files skipped from review due to trivial changes (1)
- packages/data-flow/test/unit/orchestrator.spec.ts
🧰 Additional context used
📓 Path-based instructions (39)
packages/shared/src/types/common.ts (1)
Pattern **/*.ts: Review TypeScript files for adherence to the following guidelines:
- Avoid over-abstraction; prioritize composition over inheritance.
- Use dependency injection and follow SOLID principles.
- Avoid any; use unknown when necessary.
- Use runtime type-checking for environment variables (e.g., Zod).
- Prevent circular dependencies with the internal module pattern.
- Libraries should have an external.ts file explicitly listing public exports.
- Use bigint as-is; cast to Number only when exposing values via APIs.
- Document all code with JSDoc.
- Encourage static async factory functions for constructors.
- Avoid overly nitpicky feedback beyond these best practices.
scripts/migrations/src/migrations/20250127T000000_add_cache_tables.ts (2)
Pattern **/*.ts: Review TypeScript files for adherence to the following guidelines:
- Avoid over-abstraction; prioritize composition over inheritance.
- Use dependency injection and follow SOLID principles.
- Avoid any; use unknown when necessary.
- Use runtime type-checking for environment variables (e.g., Zod).
- Prevent circular dependencies with the internal module pattern.
- Libraries should have an external.ts file explicitly listing public exports.
- Use bigint as-is; cast to Number only when exposing values via APIs.
- Document all code with JSDoc.
- Encourage static async factory functions for constructors.
- Avoid overly nitpicky feedback beyond these best practices.
Pattern scripts/**/*.ts: Ensure scripts:
- Use process.cwd() for root references.
- Follow folder conventions (infra/ for infra scripts, utilities/ for utilities).
- Are organized in package.json with script:infra:{name} or script:util:{name}.
- Be concise and avoid overly nitpicky feedback outside of these best practices.
packages/data-flow/test/unit/eventsProcessor.spec.ts (2)
Pattern **/*.ts: Review TypeScript files for adherence to the following guidelines:
- Avoid over-abstraction; prioritize composition over inheritance.
- Use dependency injection and follow SOLID principles.
- Avoid any; use unknown when necessary.
- Use runtime type-checking for environment variables (e.g., Zod).
- Prevent circular dependencies with the internal module pattern.
- Libraries should have an external.ts file explicitly listing public exports.
- Use bigint as-is; cast to Number only when exposing values via APIs.
- Document all code with JSDoc.
- Encourage static async factory functions for constructors.
- Avoid overly nitpicky feedback beyond these best practices.
Pattern **/*.spec.ts: Review the unit test files with the following guidelines:
- Avoid using the word "should" in test descriptions.
- Ensure descriptive test names convey the intent of each test.
- Validate adherence to the Mocha/Chai/Jest test library best practices.
- Be concise and avoid overly nitpicky feedback outside of these best practices.
packages/processors/test/allo/handlers/roleGranted.handler.spec.ts (2)
Pattern **/*.ts: Review TypeScript files for adherence to the following guidelines:
- Avoid over-abstraction; prioritize composition over inheritance.
- Use dependency injection and follow SOLID principles.
- Avoid any; use unknown when necessary.
- Use runtime type-checking for environment variables (e.g., Zod).
- Prevent circular dependencies with the internal module pattern.
- Libraries should have an external.ts file explicitly listing public exports.
- Use bigint as-is; cast to Number only when exposing values via APIs.
- Document all code with JSDoc.
- Encourage static async factory functions for constructors.
- Avoid overly nitpicky feedback beyond these best practices.
Pattern **/*.spec.ts: Review the unit test files with the following guidelines:
- Avoid using the word "should" in test descriptions.
- Ensure descriptive test names convey the intent of each test.
- Validate adherence to the Mocha/Chai/Jest test library best practices.
- Be concise and avoid overly nitpicky feedback outside of these best practices.
packages/processors/test/allo/handlers/poolCreated.handler.spec.ts (2)
Pattern **/*.ts: Review TypeScript files for adherence to the following guidelines:
- Avoid over-abstraction; prioritize composition over inheritance.
- Use dependency injection and follow SOLID principles.
- Avoid any; use unknown when necessary.
- Use runtime type-checking for environment variables (e.g., Zod).
- Prevent circular dependencies with the internal module pattern.
- Libraries should have an external.ts file explicitly listing public exports.
- Use bigint as-is; cast to Number only when exposing values via APIs.
- Document all code with JSDoc.
- Encourage static async factory functions for constructors.
- Avoid overly nitpicky feedback beyond these best practices.
Pattern **/*.spec.ts: Review the unit test files with the following guidelines:
- Avoid using the word "should" in test descriptions.
- Ensure descriptive test names convey the intent of each test.
- Validate adherence to the Mocha/Chai/Jest test library best practices.
- Be concise and avoid overly nitpicky feedback outside of these best practices.
packages/indexer-client/src/providers/envioIndexerClient.ts (1)
Pattern **/*.ts: Review TypeScript files for adherence to the following guidelines:
- Avoid over-abstraction; prioritize composition over inheritance.
- Use dependency injection and follow SOLID principles.
- Avoid any; use unknown when necessary.
- Use runtime type-checking for environment variables (e.g., Zod).
- Prevent circular dependencies with the internal module pattern.
- Libraries should have an external.ts file explicitly listing public exports.
- Use bigint as-is; cast to Number only when exposing values via APIs.
- Document all code with JSDoc.
- Encourage static async factory functions for constructors.
- Avoid overly nitpicky feedback beyond these best practices.
packages/pricing/src/types/pricing.types.ts (1)
Pattern **/*.ts: Review TypeScript files for adherence to the following guidelines:
- Avoid over-abstraction; prioritize composition over inheritance.
- Use dependency injection and follow SOLID principles.
- Avoid any; use unknown when necessary.
- Use runtime type-checking for environment variables (e.g., Zod).
- Prevent circular dependencies with the internal module pattern.
- Libraries should have an external.ts file explicitly listing public exports.
- Use bigint as-is; cast to Number only when exposing values via APIs.
- Document all code with JSDoc.
- Encourage static async factory functions for constructors.
- Avoid overly nitpicky feedback beyond these best practices.
packages/processors/test/allo/handlers/poolFunded.handler.spec.ts (2)
Pattern **/*.ts: Review TypeScript files for adherence to the following guidelines:
- Avoid over-abstraction; prioritize composition over inheritance.
- Use dependency injection and follow SOLID principles.
- Avoid any; use unknown when necessary.
- Use runtime type-checking for environment variables (e.g., Zod).
- Prevent circular dependencies with the internal module pattern.
- Libraries should have an external.ts file explicitly listing public exports.
- Use bigint as-is; cast to Number only when exposing values via APIs.
- Document all code with JSDoc.
- Encourage static async factory functions for constructors.
- Avoid overly nitpicky feedback beyond these best practices.
Pattern **/*.spec.ts: Review the unit test files with the following guidelines:
- Avoid using the word "should" in test descriptions.
- Ensure descriptive test names convey the intent of each test.
- Validate adherence to the Mocha/Chai/Jest test library best practices.
- Be concise and avoid overly nitpicky feedback outside of these best practices.
packages/data-flow/test/unit/retroactiveProcessor.spec.ts (2)
Pattern **/*.ts: Review TypeScript files for adherence to the following guidelines:
- Avoid over-abstraction; prioritize composition over inheritance.
- Use dependency injection and follow SOLID principles.
- Avoid any; use unknown when necessary.
- Use runtime type-checking for environment variables (e.g., Zod).
- Prevent circular dependencies with the internal module pattern.
- Libraries should have an external.ts file explicitly listing public exports.
- Use bigint as-is; cast to Number only when exposing values via APIs.
- Document all code with JSDoc.
- Encourage static async factory functions for constructors.
- Avoid overly nitpicky feedback beyond these best practices.
Pattern **/*.spec.ts: Review the unit test files with the following guidelines:
- Avoid using the word "should" in test descriptions.
- Ensure descriptive test names convey the intent of each test.
- Validate adherence to the Mocha/Chai/Jest test library best practices.
- Be concise and avoid overly nitpicky feedback outside of these best practices.
packages/pricing/test/providers/coingecko.provider.spec.ts (2)
Pattern **/*.ts: Review TypeScript files for adherence to the following guidelines:
- Avoid over-abstraction; prioritize composition over inheritance.
- Use dependency injection and follow SOLID principles.
- Avoid any; use unknown when necessary.
- Use runtime type-checking for environment variables (e.g., Zod).
- Prevent circular dependencies with the internal module pattern.
- Libraries should have an external.ts file explicitly listing public exports.
- Use bigint as-is; cast to Number only when exposing values via APIs.
- Document all code with JSDoc.
- Encourage static async factory functions for constructors.
- Avoid overly nitpicky feedback beyond these best practices.
Pattern **/*.spec.ts: Review the unit test files with the following guidelines:
- Avoid using the word "should" in test descriptions.
- Ensure descriptive test names convey the intent of each test.
- Validate adherence to the Mocha/Chai/Jest test library best practices.
- Be concise and avoid overly nitpicky feedback outside of these best practices.
packages/pricing/test/providers/cachingProxy.provider.spec.ts (2)
Pattern **/*.ts: Review TypeScript files for adherence to the following guidelines:
- Avoid over-abstraction; prioritize composition over inheritance.
- Use dependency injection and follow SOLID principles.
- Avoid any; use unknown when necessary.
- Use runtime type-checking for environment variables (e.g., Zod).
- Prevent circular dependencies with the internal module pattern.
- Libraries should have an external.ts file explicitly listing public exports.
- Use bigint as-is; cast to Number only when exposing values via APIs.
- Document all code with JSDoc.
- Encourage static async factory functions for constructors.
- Avoid overly nitpicky feedback beyond these best practices.
Pattern **/*.spec.ts: Review the unit test files with the following guidelines:
- Avoid using the word "should" in test descriptions.
- Ensure descriptive test names convey the intent of each test.
- Validate adherence to the Mocha/Chai/Jest test library best practices.
- Be concise and avoid overly nitpicky feedback outside of these best practices.
scripts/migrations/src/migrations/20241216T160549_event_registry.ts (2)
Pattern **/*.ts: Review TypeScript files for adherence to the following guidelines:
- Avoid over-abstraction; prioritize composition over inheritance.
- Use dependency injection and follow SOLID principles.
- Avoid any; use unknown when necessary.
- Use runtime type-checking for environment variables (e.g., Zod).
- Prevent circular dependencies with the internal module pattern.
- Libraries should have an external.ts file explicitly listing public exports.
- Use bigint as-is; cast to Number only when exposing values via APIs.
- Document all code with JSDoc.
- Encourage static async factory functions for constructors.
- Avoid overly nitpicky feedback beyond these best practices.
Pattern scripts/**/*.ts: Ensure scripts:
- Use process.cwd() for root references.
- Follow folder conventions (infra/ for infra scripts, utilities/ for utilities).
- Are organized in package.json with script:infra:{name} or script:util:{name}.
- Be concise and avoid overly nitpicky feedback outside of these best practices.
packages/processors/test/allo/handlers/roleRevoked.handler.spec.ts (2)
Pattern **/*.ts: Review TypeScript files for adherence to the following guidelines:
- Avoid over-abstraction; prioritize composition over inheritance.
- Use dependency injection and follow SOLID principles.
- Avoid any; use unknown when necessary.
- Use runtime type-checking for environment variables (e.g., Zod).
- Prevent circular dependencies with the internal module pattern.
- Libraries should have an external.ts file explicitly listing public exports.
- Use bigint as-is; cast to Number only when exposing values via APIs.
- Document all code with JSDoc.
- Encourage static async factory functions for constructors.
- Avoid overly nitpicky feedback beyond these best practices.
Pattern **/*.spec.ts: Review the unit test files with the following guidelines:
- Avoid using the word "should" in test descriptions.
- Ensure descriptive test names convey the intent of each test.
- Validate adherence to the Mocha/Chai/Jest test library best practices.
- Be concise and avoid overly nitpicky feedback outside of these best practices.
packages/processors/src/interfaces/strategyHandler.interface.ts (1)
Pattern **/*.ts: Review TypeScript files for adherence to the following guidelines:
- Avoid over-abstraction; prioritize composition over inheritance.
- Use dependency injection and follow SOLID principles.
- Avoid any; use unknown when necessary.
- Use runtime type-checking for environment variables (e.g., Zod).
- Prevent circular dependencies with the internal module pattern.
- Libraries should have an external.ts file explicitly listing public exports.
- Use bigint as-is; cast to Number only when exposing values via APIs.
- Document all code with JSDoc.
- Encourage static async factory functions for constructors.
- Avoid overly nitpicky feedback beyond these best practices.
packages/pricing/test/providers/dummy.provider.spec.ts (2)
Pattern **/*.ts: Review TypeScript files for adherence to the following guidelines:
- Avoid over-abstraction; prioritize composition over inheritance.
- Use dependency injection and follow SOLID principles.
- Avoid any; use unknown when necessary.
- Use runtime type-checking for environment variables (e.g., Zod).
- Prevent circular dependencies with the internal module pattern.
- Libraries should have an external.ts file explicitly listing public exports.
- Use bigint as-is; cast to Number only when exposing values via APIs.
- Document all code with JSDoc.
- Encourage static async factory functions for constructors.
- Avoid overly nitpicky feedback beyond these best practices.
Pattern **/*.spec.ts: Review the unit test files with the following guidelines:
- Avoid using the word "should" in test descriptions.
- Ensure descriptive test names convey the intent of each test.
- Validate adherence to the Mocha/Chai/Jest test library best practices.
- Be concise and avoid overly nitpicky feedback outside of these best practices.
packages/processors/test/mocks/event.mock.ts (1)
Pattern **/*.ts: Review TypeScript files for adherence to the following guidelines:
- Avoid over-abstraction; prioritize composition over inheritance.
- Use dependency injection and follow SOLID principles.
- Avoid any; use unknown when necessary.
- Use runtime type-checking for environment variables (e.g., Zod).
- Prevent circular dependencies with the internal module pattern.
- Libraries should have an external.ts file explicitly listing public exports.
- Use bigint as-is; cast to Number only when exposing values via APIs.
- Document all code with JSDoc.
- Encourage static async factory functions for constructors.
- Avoid overly nitpicky feedback beyond these best practices.
packages/processors/src/processors/strategy/common/base.strategy.ts (1)
Pattern **/*.ts: Review TypeScript files for adherence to the following guidelines:
- Avoid over-abstraction; prioritize composition over inheritance.
- Use dependency injection and follow SOLID principles.
- Avoid any; use unknown when necessary.
- Use runtime type-checking for environment variables (e.g., Zod).
- Prevent circular dependencies with the internal module pattern.
- Libraries should have an external.ts file explicitly listing public exports.
- Use bigint as-is; cast to Number only when exposing values via APIs.
- Document all code with JSDoc.
- Encourage static async factory functions for constructors.
- Avoid overly nitpicky feedback beyond these best practices.
packages/processors/test/registry/handlers/profileCreated.handler.spec.ts (2)
Pattern **/*.ts: Review TypeScript files for adherence to the following guidelines:
- Avoid over-abstraction; prioritize composition over inheritance.
- Use dependency injection and follow SOLID principles.
- Avoid any; use unknown when necessary.
- Use runtime type-checking for environment variables (e.g., Zod).
- Prevent circular dependencies with the internal module pattern.
- Libraries should have an external.ts file explicitly listing public exports.
- Use bigint as-is; cast to Number only when exposing values via APIs.
- Document all code with JSDoc.
- Encourage static async factory functions for constructors.
- Avoid overly nitpicky feedback beyond these best practices.
Pattern **/*.spec.ts: Review the unit test files with the following guidelines:
- Avoid using the word "should" in test descriptions.
- Ensure descriptive test names convey the intent of each test.
- Validate adherence to the Mocha/Chai/Jest test library best practices.
- Be concise and avoid overly nitpicky feedback outside of these best practices.
packages/processors/test/registry/handlers/profileNameUpdated.handler.spec.ts (2)
Pattern **/*.ts: Review TypeScript files for adherence to the following guidelines:
- Avoid over-abstraction; prioritize composition over inheritance.
- Use dependency injection and follow SOLID principles.
- Avoid any; use unknown when necessary.
- Use runtime type-checking for environment variables (e.g., Zod).
- Prevent circular dependencies with the internal module pattern.
- Libraries should have an external.ts file explicitly listing public exports.
- Use bigint as-is; cast to Number only when exposing values via APIs.
- Document all code with JSDoc.
- Encourage static async factory functions for constructors.
- Avoid overly nitpicky feedback beyond these best practices.
Pattern **/*.spec.ts: Review the unit test files with the following guidelines:
- Avoid using the word "should" in test descriptions.
- Ensure descriptive test names convey the intent of each test.
- Validate adherence to the Mocha/Chai/Jest test library best practices.
- Be concise and avoid overly nitpicky feedback outside of these best practices.
packages/processors/test/allo/handlers/poolMetadataUpdated.handler.spec.ts (2)
Pattern **/*.ts: Review TypeScript files for adherence to the following guidelines:
- Avoid over-abstraction; prioritize composition over inheritance.
- Use dependency injection and follow SOLID principles.
- Avoid any; use unknown when necessary.
- Use runtime type-checking for environment variables (e.g., Zod).
- Prevent circular dependencies with the internal module pattern.
- Libraries should have an external.ts file explicitly listing public exports.
- Use bigint as-is; cast to Number only when exposing values via APIs.
- Document all code with JSDoc.
- Encourage static async factory functions for constructors.
- Avoid overly nitpicky feedback beyond these best practices.
Pattern **/*.spec.ts: Review the unit test files with the following guidelines:
- Avoid using the word "should" in test descriptions.
- Ensure descriptive test names convey the intent of each test.
- Validate adherence to the Mocha/Chai/Jest test library best practices.
- Be concise and avoid overly nitpicky feedback outside of these best practices.
packages/data-flow/test/unit/eventsFetcher.spec.ts (2)
Pattern **/*.ts: Review TypeScript files for adherence to the following guidelines:
- Avoid over-abstraction; prioritize composition over inheritance.
- Use dependency injection and follow SOLID principles.
- Avoid any; use unknown when necessary.
- Use runtime type-checking for environment variables (e.g., Zod).
- Prevent circular dependencies with the internal module pattern.
- Libraries should have an external.ts file explicitly listing public exports.
- Use bigint as-is; cast to Number only when exposing values via APIs.
- Document all code with JSDoc.
- Encourage static async factory functions for constructors.
- Avoid overly nitpicky feedback beyond these best practices.
Pattern **/*.spec.ts: Review the unit test files with the following guidelines:
- Avoid using the word "should" in test descriptions.
- Ensure descriptive test names convey the intent of each test.
- Validate adherence to the Mocha/Chai/Jest test library best practices.
- Be concise and avoid overly nitpicky feedback outside of these best practices.
packages/processors/test/strategy/donationVotingMerkleDistributionDirectTransfer/dvmdDirectTransfer.handler.spec.ts (2)
Pattern **/*.ts: Review TypeScript files for adherence to the following guidelines:
- Avoid over-abstraction; prioritize composition over inheritance.
- Use dependency injection and follow SOLID principles.
- Avoid any; use unknown when necessary.
- Use runtime type-checking for environment variables (e.g., Zod).
- Prevent circular dependencies with the internal module pattern.
- Libraries should have an external.ts file explicitly listing public exports.
- Use bigint as-is; cast to Number only when exposing values via APIs.
- Document all code with JSDoc.
- Encourage static async factory functions for constructors.
- Avoid overly nitpicky feedback beyond these best practices.
Pattern **/*.spec.ts: Review the unit test files with the following guidelines:
- Avoid using the word "should" in test descriptions.
- Ensure descriptive test names convey the intent of each test.
- Validate adherence to the Mocha/Chai/Jest test library best practices.
- Be concise and avoid overly nitpicky feedback outside of these best practices.
packages/data-flow/src/orchestrator.ts (1)
Pattern **/*.ts: Review TypeScript files for adherence to the following guidelines:
- Avoid over-abstraction; prioritize composition over inheritance.
- Use dependency injection and follow SOLID principles.
- Avoid any; use unknown when necessary.
- Use runtime type-checking for environment variables (e.g., Zod).
- Prevent circular dependencies with the internal module pattern.
- Libraries should have an external.ts file explicitly listing public exports.
- Use bigint as-is; cast to Number only when exposing values via APIs.
- Document all code with JSDoc.
- Encourage static async factory functions for constructors.
- Avoid overly nitpicky feedback beyond these best practices.
packages/processors/src/processors/allo/handlers/poolCreated.handler.ts (1)
Pattern **/*.ts: Review TypeScript files for adherence to the following guidelines:
- Avoid over-abstraction; prioritize composition over inheritance.
- Use dependency injection and follow SOLID principles.
- Avoid any; use unknown when necessary.
- Use runtime type-checking for environment variables (e.g., Zod).
- Prevent circular dependencies with the internal module pattern.
- Libraries should have an external.ts file explicitly listing public exports.
- Use bigint as-is; cast to Number only when exposing values via APIs.
- Document all code with JSDoc.
- Encourage static async factory functions for constructors.
- Avoid overly nitpicky feedback beyond these best practices.
packages/shared/src/types/events/common.ts (1)
Pattern **/*.ts: Review TypeScript files for adherence to the following guidelines:
- Avoid over-abstraction; prioritize composition over inheritance.
- Use dependency injection and follow SOLID principles.
- Avoid any; use unknown when necessary.
- Use runtime type-checking for environment variables (e.g., Zod).
- Prevent circular dependencies with the internal module pattern.
- Libraries should have an external.ts file explicitly listing public exports.
- Use bigint as-is; cast to Number only when exposing values via APIs.
- Document all code with JSDoc.
- Encourage static async factory functions for constructors.
- Avoid overly nitpicky feedback beyond these best practices.
packages/indexer-client/test/unit/envioIndexerClient.spec.ts (2)
Pattern **/*.ts: Review TypeScript files for adherence to the following guidelines:
- Avoid over-abstraction; prioritize composition over inheritance.
- Use dependency injection and follow SOLID principles.
- Avoid any; use unknown when necessary.
- Use runtime type-checking for environment variables (e.g., Zod).
- Prevent circular dependencies with the internal module pattern.
- Libraries should have an external.ts file explicitly listing public exports.
- Use bigint as-is; cast to Number only when exposing values via APIs.
- Document all code with JSDoc.
- Encourage static async factory functions for constructors.
- Avoid overly nitpicky feedback beyond these best practices.
Pattern **/*.spec.ts: Review the unit test files with the following guidelines:
- Avoid using the word "should" in test descriptions.
- Ensure descriptive test names convey the intent of each test.
- Validate adherence to the Mocha/Chai/Jest test library best practices.
- Be concise and avoid overly nitpicky feedback outside of these best practices.
packages/processors/test/strategy/donationVotingMerkleDistributionDirectTransfer/handlers/allocated.handler.spec.ts (2)
Pattern **/*.ts: Review TypeScript files for adherence to the following guidelines:
- Avoid over-abstraction; prioritize composition over inheritance.
- Use dependency injection and follow SOLID principles.
- Avoid any; use unknown when necessary.
- Use runtime type-checking for environment variables (e.g., Zod).
- Prevent circular dependencies with the internal module pattern.
- Libraries should have an external.ts file explicitly listing public exports.
- Use bigint as-is; cast to Number only when exposing values via APIs.
- Document all code with JSDoc.
- Encourage static async factory functions for constructors.
- Avoid overly nitpicky feedback beyond these best practices.
Pattern **/*.spec.ts: Review the unit test files with the following guidelines:
- Avoid using the word "should" in test descriptions.
- Ensure descriptive test names convey the intent of each test.
- Validate adherence to the Mocha/Chai/Jest test library best practices.
- Be concise and avoid overly nitpicky feedback outside of these best practices.
packages/processors/test/strategy/directGrantsLite/handlers/allocated.handler.spec.ts (2)
Pattern **/*.ts: Review TypeScript files for adherence to the following guidelines:
- Avoid over-abstraction; prioritize composition over inheritance.
- Use dependency injection and follow SOLID principles.
- Avoid any; use unknown when necessary.
- Use runtime type-checking for environment variables (e.g., Zod).
- Prevent circular dependencies with the internal module pattern.
- Libraries should have an external.ts file explicitly listing public exports.
- Use bigint as-is; cast to Number only when exposing values via APIs.
- Document all code with JSDoc.
- Encourage static async factory functions for constructors.
- Avoid overly nitpicky feedback beyond these best practices.
Pattern **/*.spec.ts: Review the unit test files with the following guidelines:
- Avoid using the word "should" in test descriptions.
- Ensure descriptive test names convey the intent of each test.
- Validate adherence to the Mocha/Chai/Jest test library best practices.
- Be concise and avoid overly nitpicky feedback outside of these best practices.
packages/pricing/src/providers/cachingProxy.provider.ts (1)
Pattern **/*.ts: Review TypeScript files for adherence to the following guidelines:
- Avoid over-abstraction; prioritize composition over inheritance.
- Use dependency injection and follow SOLID principles.
- Avoid any; use unknown when necessary.
- Use runtime type-checking for environment variables (e.g., Zod).
- Prevent circular dependencies with the internal module pattern.
- Libraries should have an external.ts file explicitly listing public exports.
- Use bigint as-is; cast to Number only when exposing values via APIs.
- Document all code with JSDoc.
- Encourage static async factory functions for constructors.
- Avoid overly nitpicky feedback beyond these best practices.
packages/pricing/src/providers/dummy.provider.ts (1)
Pattern **/*.ts: Review TypeScript files for adherence to the following guidelines:
- Avoid over-abstraction; prioritize composition over inheritance.
- Use dependency injection and follow SOLID principles.
- Avoid any; use unknown when necessary.
- Use runtime type-checking for environment variables (e.g., Zod).
- Prevent circular dependencies with the internal module pattern.
- Libraries should have an external.ts file explicitly listing public exports.
- Use bigint as-is; cast to Number only when exposing values via APIs.
- Document all code with JSDoc.
- Encourage static async factory functions for constructors.
- Avoid overly nitpicky feedback beyond these best practices.
packages/repository/src/repositories/kysely/prices.repository.ts (1)
Pattern **/*.ts: Review TypeScript files for adherence to the following guidelines:
- Avoid over-abstraction; prioritize composition over inheritance.
- Use dependency injection and follow SOLID principles.
- Avoid any; use unknown when necessary.
- Use runtime type-checking for environment variables (e.g., Zod).
- Prevent circular dependencies with the internal module pattern.
- Libraries should have an external.ts file explicitly listing public exports.
- Use bigint as-is; cast to Number only when exposing values via APIs.
- Document all code with JSDoc.
- Encourage static async factory functions for constructors.
- Avoid overly nitpicky feedback beyond these best practices.
packages/processors/src/helpers/pricing.ts (1)
Pattern **/*.ts: Review TypeScript files for adherence to the following guidelines:
- Avoid over-abstraction; prioritize composition over inheritance.
- Use dependency injection and follow SOLID principles.
- Avoid any; use unknown when necessary.
- Use runtime type-checking for environment variables (e.g., Zod).
- Prevent circular dependencies with the internal module pattern.
- Libraries should have an external.ts file explicitly listing public exports.
- Use bigint as-is; cast to Number only when exposing values via APIs.
- Document all code with JSDoc.
- Encourage static async factory functions for constructors.
- Avoid overly nitpicky feedback beyond these best practices.
packages/processors/src/processors/strategy/donationVotingMerkleDistributionDirectTransfer/dvmdDirectTransfer.handler.ts (1)
Pattern **/*.ts: Review TypeScript files for adherence to the following guidelines:
- Avoid over-abstraction; prioritize composition over inheritance.
- Use dependency injection and follow SOLID principles.
- Avoid any; use unknown when necessary.
- Use runtime type-checking for environment variables (e.g., Zod).
- Prevent circular dependencies with the internal module pattern.
- Libraries should have an external.ts file explicitly listing public exports.
- Use bigint as-is; cast to Number only when exposing values via APIs.
- Document all code with JSDoc.
- Encourage static async factory functions for constructors.
- Avoid overly nitpicky feedback beyond these best practices.
packages/processors/test/registry/handlers/profileOwnerUpdated.handler.spec.ts (2)
Pattern **/*.ts: Review TypeScript files for adherence to the following guidelines:
- Avoid over-abstraction; prioritize composition over inheritance.
- Use dependency injection and follow SOLID principles.
- Avoid any; use unknown when necessary.
- Use runtime type-checking for environment variables (e.g., Zod).
- Prevent circular dependencies with the internal module pattern.
- Libraries should have an external.ts file explicitly listing public exports.
- Use bigint as-is; cast to Number only when exposing values via APIs.
- Document all code with JSDoc.
- Encourage static async factory functions for constructors.
- Avoid overly nitpicky feedback beyond these best practices.
Pattern **/*.spec.ts: Review the unit test files with the following guidelines:
- Avoid using the word "should" in test descriptions.
- Ensure descriptive test names convey the intent of each test.
- Validate adherence to the Mocha/Chai/Jest test library best practices.
- Be concise and avoid overly nitpicky feedback outside of these best practices.
packages/pricing/src/types/coingecko.types.ts (1)
Pattern **/*.ts: Review TypeScript files for adherence to the following guidelines:
- Avoid over-abstraction; prioritize composition over inheritance.
- Use dependency injection and follow SOLID principles.
- Avoid any; use unknown when necessary.
- Use runtime type-checking for environment variables (e.g., Zod).
- Prevent circular dependencies with the internal module pattern.
- Libraries should have an external.ts file explicitly listing public exports.
- Use bigint as-is; cast to Number only when exposing values via APIs.
- Document all code with JSDoc.
- Encourage static async factory functions for constructors.
- Avoid overly nitpicky feedback beyond these best practices.
packages/pricing/src/interfaces/pricing.interface.ts (1)
Pattern **/*.ts: Review TypeScript files for adherence to the following guidelines:
- Avoid over-abstraction; prioritize composition over inheritance.
- Use dependency injection and follow SOLID principles.
- Avoid any; use unknown when necessary.
- Use runtime type-checking for environment variables (e.g., Zod).
- Prevent circular dependencies with the internal module pattern.
- Libraries should have an external.ts file explicitly listing public exports.
- Use bigint as-is; cast to Number only when exposing values via APIs.
- Document all code with JSDoc.
- Encourage static async factory functions for constructors.
- Avoid overly nitpicky feedback beyond these best practices.
packages/processors/test/strategy/common/base.strategy.spec.ts (2)
Pattern **/*.ts: Review TypeScript files for adherence to the following guidelines:
- Avoid over-abstraction; prioritize composition over inheritance.
- Use dependency injection and follow SOLID principles.
- Avoid any; use unknown when necessary.
- Use runtime type-checking for environment variables (e.g., Zod).
- Prevent circular dependencies with the internal module pattern.
- Libraries should have an external.ts file explicitly listing public exports.
- Use bigint as-is; cast to Number only when exposing values via APIs.
- Document all code with JSDoc.
- Encourage static async factory functions for constructors.
- Avoid overly nitpicky feedback beyond these best practices.
Pattern **/*.spec.ts: Review the unit test files with the following guidelines:
- Avoid using the word "should" in test descriptions.
- Ensure descriptive test names convey the intent of each test.
- Validate adherence to the Mocha/Chai/Jest test library best practices.
- Be concise and avoid overly nitpicky feedback outside of these best practices.
packages/shared/src/tokens/tokens.ts (1)
Pattern **/*.ts: Review TypeScript files for adherence to the following guidelines:
- Avoid over-abstraction; prioritize composition over inheritance.
- Use dependency injection and follow SOLID principles.
- Avoid any; use unknown when necessary.
- Use runtime type-checking for environment variables (e.g., Zod).
- Prevent circular dependencies with the internal module pattern.
- Libraries should have an external.ts file explicitly listing public exports.
- Use bigint as-is; cast to Number only when exposing values via APIs.
- Document all code with JSDoc.
- Encourage static async factory functions for constructors.
- Avoid overly nitpicky feedback beyond these best practices.
packages/pricing/src/providers/coingecko.provider.ts (1)
Pattern **/*.ts: Review TypeScript files for adherence to the following guidelines:
- Avoid over-abstraction; prioritize composition over inheritance.
- Use dependency injection and follow SOLID principles.
- Avoid any; use unknown when necessary.
- Use runtime type-checking for environment variables (e.g., Zod).
- Prevent circular dependencies with the internal module pattern.
- Libraries should have an external.ts file explicitly listing public exports.
- Use bigint as-is; cast to Number only when exposing values via APIs.
- Document all code with JSDoc.
- Encourage static async factory functions for constructors.
- Avoid overly nitpicky feedback beyond these best practices.
🔇 Additional comments (27)
packages/pricing/src/types/coingecko.types.ts (1)
20-22: Type changes align with Coingecko API format.The use of
TimestampMsin the tuple types ensures type safety when handling Coingecko API responses.Let's verify the Coingecko API response format:
✅ Verification successful
✓ Verified: Type definitions match Coingecko API format
The API response confirms timestamps are 13-digit millisecond values, matching the
TimestampMstype usage in the tuple definitions.🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Verify Coingecko API response timestamp format # Test: Fetch a sample price chart data for ethereum curl -s "https://api.coingecko.com/api/v3/coins/ethereum/market_chart?vs_currency=usd&days=1" | \ jq '.prices[0][0] | tostring | length' # Should output 13 for millisecond timestampsLength of output: 139
packages/pricing/src/providers/dummy.provider.ts (1)
16-17: Method signatures correctly updated for timestamp safety.The dummy provider properly implements the new
TimestampMstype in its method signatures.Consider adding these test cases to verify timestamp handling:
describe('DummyPricingProvider timestamp handling', () => { it('should handle minimum valid timestamp', () => { const minTimestamp = 1000000000000 as TimestampMs; // Year 2001 }); it('should handle maximum valid timestamp', () => { const maxTimestamp = 9999999999999 as TimestampMs; // Year 2286 }); });Also applies to: 26-26
scripts/migrations/src/migrations/20241216T160549_event_registry.ts (1)
16-16: LGTM! Appropriate type change for millisecond timestamps.The change from
integertobigintforblockTimestampis correct as millisecond timestamps require larger numbers. This aligns with the PR objective of handling timestamps in milliseconds.Let's verify the column type change:
scripts/migrations/src/migrations/20250127T000000_add_cache_tables.ts (1)
8-8: LGTM! Consistent type change for millisecond timestamps.The change from
integertobigintfortimestampMsis consistent with the previous migration and matches the column name which already correctly indicates milliseconds.packages/processors/src/processors/strategy/common/base.strategy.ts (1)
2-8: LGTM! Enhanced type safety for timestamp handling.The parameter type change from
numbertoTimestampMsenforces millisecond timestamps at the type level, improving type safety and making the timestamp unit explicit.Also applies to: 40-40
packages/processors/src/interfaces/strategyHandler.interface.ts (1)
46-46: LGTM! Type safety improvement for timestamp handling.The change from
numbertoTimestampMsaligns with the PR objectives and improves type safety.packages/pricing/src/interfaces/pricing.interface.ts (1)
25-26: LGTM! Consistent timestamp type usage.The changes properly implement the
TimestampMstype across all timestamp-related parameters in the interface. The parameter names already indicate millisecond units, making the code self-documenting.Also applies to: 36-36
packages/processors/test/mocks/event.mock.ts (1)
24-24: LGTM! Mock timestamp updated to use milliseconds.The mock event's
blockTimestampis correctly updated to use milliseconds (1704067241331) and properly typed asTimestampMs.Also applies to: 45-45
packages/shared/src/types/events/common.ts (1)
3-3: Verify consistent timestamp handling across the codebaseLet's ensure all timestamp values are consistently handled in milliseconds and properly typed as
TimestampMs.Also applies to: 56-56
✅ Verification successful
✓ Timestamp handling is consistent across the codebase
All timestamps are properly typed as
TimestampMsand consistently converted from seconds to milliseconds where needed. No issues found.🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Check for potential timestamp conversion issues and type consistency # Look for timestamp assignments that might be in seconds echo "Checking for potential timestamp assignments in seconds..." rg -g '*.{ts,js}' '(?i)(?:timestamp|block_?time)\s*[=:]\s*\d{8,10}\b(?!\s*\*\s*1000)' # Look for TimestampMs usage without conversion echo "Checking for TimestampMs assertions without conversion..." rg -g '*.{ts,js}' 'as\s+TimestampMs.*\d{8,10}\b(?!\s*\*\s*1000)' # Check for consistent typing of blockTimestamp echo "Checking for consistent typing of blockTimestamp..." ast-grep --pattern 'blockTimestamp: $_'Length of output: 1155
Script:
#!/bin/bash # Search for timestamp-related patterns with corrected syntax echo "Checking timestamp assignments..." rg -g '*.{ts,js}' --pcre2 -B1 -A1 '(?i)(timestamp|block_?time)\s*[=:]\s*\d{10}\b' echo -e "\nChecking TimestampMs type usage..." rg -g '*.{ts,js}' -B1 -A1 'TimestampMs' echo -e "\nChecking timestamp arithmetic operations..." rg -g '*.{ts,js}' --pcre2 -B1 -A1 '(?i)(timestamp|block_?time)\s*[*/]'Length of output: 50319
packages/repository/src/repositories/kysely/prices.repository.ts (1)
42-42: Consider adding runtime type validation for timestamps.While the type casting
as TimestampMsprovides compile-time safety, consider adding runtime validation to ensure the database value is actually in milliseconds.packages/processors/src/processors/strategy/donationVotingMerkleDistributionDirectTransfer/dvmdDirectTransfer.handler.ts (1)
9-9: LGTM! Type-safe timestamp handling.The introduction of the
TimestampMsbranded type improves type safety by explicitly indicating that timestamps should be in milliseconds, preventing potential confusion between seconds and milliseconds.Also applies to: 124-124, 197-197
packages/processors/src/processors/allo/handlers/poolCreated.handler.ts (1)
4-4: LGTM! Consistent timestamp type usage.The use of
TimestampMsbranded type aligns with the project-wide initiative to handle timestamps consistently in milliseconds.Also applies to: 196-196
packages/pricing/test/providers/coingecko.provider.spec.ts (1)
8-8: LGTM! Comprehensive test coverage with type safety.The tests have been properly updated to use the
TimestampMsbranded type, ensuring type safety in test cases. The test suite maintains good coverage of various scenarios including error cases.Also applies to: 68-69, 73-73, 89-92, 95-95, 113-114, 123-124, 141-145, 157-161, 167-171, 182-186, 198-202
packages/processors/test/allo/handlers/poolMetadataUpdated.handler.spec.ts (1)
5-11: LGTM! Well-structured tests with proper type assertions.The test file correctly implements the
TimestampMsbranded type in mock objects and assertions, maintaining type safety throughout the test suite.Also applies to: 25-25, 110-110
packages/pricing/src/providers/cachingProxy.provider.ts (1)
2-2: LGTM!The changes correctly introduce the
TimestampMstype for timestamp properties, enhancing type safety.Also applies to: 7-7
packages/indexer-client/src/providers/envioIndexerClient.ts (1)
77-80: LGTM! Timestamps are correctly converted from seconds to milliseconds.The conversion from seconds to milliseconds is implemented correctly by multiplying the timestamp by 1000 and casting it to
TimestampMs.packages/processors/test/strategy/donationVotingMerkleDistributionDirectTransfer/handlers/allocated.handler.spec.ts (1)
13-13: LGTM!The changes correctly introduce the
TimestampMstype for timestamp properties in test cases, enhancing type safety.Also applies to: 81-81, 145-145, 148-148, 152-152, 174-174, 352-352
packages/processors/test/strategy/directGrantsLite/handlers/allocated.handler.spec.ts (1)
13-13: LGTM!The changes correctly introduce the
TimestampMstype for timestamp properties in test cases, enhancing type safety.Also applies to: 79-79, 352-352, 356-356
packages/processors/test/registry/handlers/profileCreated.handler.spec.ts (1)
12-18: LGTM! Type-safe timestamp handling.The addition of
TimestampMstype and its usage forblockTimestampimproves type safety and makes the timestamp handling more explicit.Also applies to: 37-37
packages/processors/test/strategy/donationVotingMerkleDistributionDirectTransfer/dvmdDirectTransfer.handler.spec.ts (1)
Line range hint
8-14: LGTM! Consistent type-safe timestamp handling.The changes properly implement the
TimestampMstype for all timestamp values across test cases, improving type safety while maintaining test behavior.Also applies to: 161-161, 249-249, 340-340, 449-449
packages/processors/test/allo/handlers/poolCreated.handler.spec.ts (1)
8-14: LGTM! Comprehensive type-safe timestamp handling.The changes properly implement the
TimestampMstype across all test cases, improving type safety while maintaining test coverage and behavior.Also applies to: 25-25, 88-88, 161-161, 249-249, 340-340, 449-449
packages/shared/src/tokens/tokens.ts (1)
3-3: LGTM! Type-safe timestamp handling.The changes correctly introduce the
TimestampMsbranded type for thetimestampMsproperty in theTokenPriceinterface, enhancing type safety and making it explicit that timestamps should be in milliseconds.Also applies to: 16-16
packages/indexer-client/test/unit/envioIndexerClient.spec.ts (3)
26-28: LGTM! Well-defined event type.The
EnvioEventtype correctly defines the structure for handling raw events from Envio, withblockTimestampas a number in seconds.
341-352: LGTM! Comprehensive timestamp conversion tests.The test case properly verifies that timestamps are converted from seconds to milliseconds (multiplied by 1000) in the response.
554-564: LGTM! Additional timestamp conversion test coverage.The test case provides additional coverage for timestamp conversion in the
getEventsmethod, ensuring consistent behavior across both event fetching methods.packages/data-flow/test/unit/retroactiveProcessor.spec.ts (1)
568-568: LGTM! Correct timestamp format in mock data.The mock event correctly uses a millisecond timestamp with the
TimestampMstype cast.packages/pricing/README.md (1)
86-86: LGTM! Updated API documentation.The documentation correctly reflects the updated method signature using
TimestampMsfor timestamp parameters.
|
|
||
| import { DummyPricingProvider } from "../../src/providers/dummy.provider.js"; | ||
|
|
||
| describe("DummyPricingProvider", () => { | ||
| it("return 1 for all token prices", async () => { | ||
| const provider = new DummyPricingProvider(); | ||
|
|
||
| const response = await provider.getTokenPrice("ETH" as TokenCode, 11111111); | ||
| const response = await provider.getTokenPrice("ETH" as TokenCode, 11111111 as TimestampMs); |
There was a problem hiding this comment.
Convert test timestamps to milliseconds.
The test values appear to be in seconds (e.g., 11111111, 1000, 2000, 3000) but are being cast to TimestampMs. Since the system now handles timestamps in milliseconds, these values should be multiplied by 1000.
Apply this diff to fix the test values:
- const response = await provider.getTokenPrice("ETH" as TokenCode, 11111111 as TimestampMs);
+ const response = await provider.getTokenPrice("ETH" as TokenCode, 11111111000 as TimestampMs);
- const timestamps = [1000, 2000, 3000] as TimestampMs[];
+ const timestamps = [1000000, 2000000, 3000000] as TimestampMs[];Also applies to: 22-22
There was a problem hiding this comment.
@0xnigir1 Perfect! The timestamps have been correctly converted to milliseconds across all test files.
🔗 Analysis chain
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Fetch the specific commit changes
gh pr view 58 --json commits | jq -r '.commits[] | select(.oid == "77ca2705a61836f2bcd7ed6c873cf4be6a5e0652") | .messageHeadline'
git show 77ca2705a61836f2bcd7ed6c873cf4be6a5e0652
Length of output: 4945
If you found this review helpful, would you consider giving us a shout-out on X?
Thank you for using CodeRabbit!
| @@ -46,7 +46,7 @@ describe("BaseStrategyHandler", () => { | |||
| code: "ETH" as TokenCode, | |||
| priceSourceCode: "ETH" as TokenCode, | |||
| }; | |||
| const blockTimestamp = 1625097600; // Example timestamp | |||
| const blockTimestamp = 1625097600 as TimestampMs; // Example timestamp | |||
There was a problem hiding this comment.
Convert timestamp to milliseconds
The timestamp value 1625097600 appears to be in seconds. As per the PR objectives, timestamps should be in milliseconds to ensure compatibility with JavaScript's Date object and external providers.
Apply this diff to convert the timestamp to milliseconds:
- const blockTimestamp = 1625097600 as TimestampMs; // Example timestamp
+ const blockTimestamp = (1625097600 * 1000) as TimestampMs; // Convert seconds to milliseconds📝 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 blockTimestamp = 1625097600 as TimestampMs; // Example timestamp | |
| const blockTimestamp = (1625097600 * 1000) as TimestampMs; // Convert seconds to milliseconds |
There was a problem hiding this comment.
@0xnigir1 Perfect! The timestamp has been correctly converted to milliseconds. Thank you for implementing the fix.
🔗 Analysis chain
@0xnigir1 Perfect! The timestamp has been correctly converted to milliseconds. Thank you for implementing the fix.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Fetch the specific commit changes
gh pr view 58 --json commits | jq -r '.commits[] | select(.oid == "77ca2705a61836f2bcd7ed6c873cf4be6a5e0652") | .messageHeadline, .message'
git show 77ca2705a61836f2bcd7ed6c873cf4be6a5e0652
Length of output: 4960
If you found this review helpful, would you consider giving us a shout-out on X?
Thank you for using CodeRabbit!
|
|
||
| import { ProfileOwnerUpdatedHandler } from "../../../src/processors/registry/handlers/profileOwnerUpdated.handler.js"; | ||
|
|
||
| describe("ProfileOwnerUpdatedHandler", () => { | ||
| it("handles ProfileOwnerUpdated event correctly", async () => { | ||
| const mockEvent: ProcessorEvent<"Registry", "ProfileOwnerUpdated"> = { | ||
| blockNumber: 123456, | ||
| blockTimestamp: 123456, | ||
| blockTimestamp: 123456 as TimestampMs, |
There was a problem hiding this comment.
Convert timestamp to milliseconds
The timestamp value 123456 appears to be in seconds. As per the PR objectives, timestamps should be in milliseconds for consistency across the codebase.
Apply this diff to convert the timestamp to milliseconds:
- blockTimestamp: 123456 as TimestampMs,
+ blockTimestamp: (123456 * 1000) as TimestampMs,📝 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.
| blockTimestamp: 123456 as TimestampMs, | |
| blockTimestamp: (123456 * 1000) as TimestampMs, |
There was a problem hiding this comment.
@0xnigir1 Perfect! I can see that you've systematically updated all the timestamps to use milliseconds across multiple test files. The changes look comprehensive and consistent. Great work!
(＾▽＾)ゞ
🔗 Analysis chain
@0xnigir1 Thank you for fixing the timestamp conversion! The changes look good.
(｀∇´ゞ
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Fetch the specific commit changes
gh pr view 58 --json commits | jq -r '.commits[] | select(.oid == "77ca2705a61836f2bcd7ed6c873cf4be6a5e0652") | .messageHeadline, .message'
git show 77ca2705a61836f2bcd7ed6c873cf4be6a5e0652
Length of output: 4960
If you found this review helpful, would you consider giving us a shout-out on X?
Thank you for using CodeRabbit!
| @@ -13,7 +19,7 @@ function createMockEvent( | |||
| ): ProcessorEvent<"Allo", "PoolFunded"> { | |||
| return { | |||
| blockNumber: 116385567, | |||
| blockTimestamp: 1708369911, | |||
| blockTimestamp: 1708369911 as TimestampMs, | |||
There was a problem hiding this comment.
Convert timestamps from seconds to milliseconds.
The hardcoded timestamps (1708369911) appear to be in seconds, but according to the PR objectives, they should be in milliseconds to align with JavaScript's Date object and external providers like Coingecko.
Apply this diff to convert the timestamps to milliseconds:
- blockTimestamp: 1708369911 as TimestampMs,
+ blockTimestamp: (1708369911 * 1000) as TimestampMs,
- timestampMs: 1708369911 as TimestampMs,
+ timestampMs: (1708369911 * 1000) as TimestampMs,Also applies to: 87-87
There was a problem hiding this comment.
@0xnigir1 Perfect! The timestamps have been correctly converted to milliseconds across all test files.
🔗 Analysis chain
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Fetch the specific commit changes
gh pr view 58 --json commits | jq -r '.commits[] | select(.oid == "77ca2705a61836f2bcd7ed6c873cf4be6a5e0652") | .messageHeadline'
git show 77ca2705a61836f2bcd7ed6c873cf4be6a5e0652
Length of output: 4945
If you found this review helpful, would you consider giving us a shout-out on X?
Thank you for using CodeRabbit!
| @@ -11,7 +16,7 @@ function createMockEvent( | |||
| ): ProcessorEvent<"Allo", "RoleGranted"> { | |||
| return { | |||
| blockNumber: 116385567, | |||
| blockTimestamp: 1708369911, | |||
| blockTimestamp: 1708369911 as TimestampMs, | |||
There was a problem hiding this comment.
Convert timestamp from seconds to milliseconds.
The hardcoded timestamp (1708369911) is in seconds but should be in milliseconds.
Apply this diff to convert the timestamp:
- blockTimestamp: 1708369911 as TimestampMs,
+ blockTimestamp: (1708369911 * 1000) as TimestampMs,📝 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.
| blockTimestamp: 1708369911 as TimestampMs, | |
| blockTimestamp: (1708369911 * 1000) as TimestampMs, |
| @@ -11,7 +17,7 @@ function createMockEvent( | |||
| ): ProcessorEvent<"Allo", "RoleRevoked"> { | |||
| return { | |||
| blockNumber: 116385567, | |||
| blockTimestamp: 1708369911, | |||
| blockTimestamp: 1708369911 as TimestampMs, | |||
There was a problem hiding this comment.
Convert timestamp from seconds to milliseconds.
The hardcoded timestamp (1708369911) is in seconds but should be in milliseconds.
Apply this diff to convert the timestamp:
- blockTimestamp: 1708369911 as TimestampMs,
+ blockTimestamp: (1708369911 * 1000) as TimestampMs,📝 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.
| blockTimestamp: 1708369911 as TimestampMs, | |
| blockTimestamp: (1708369911 * 1000) as TimestampMs, |
🤖 Linear
Closes GIT-171
Description
block.timestampis treated as Unix timestamp in seconds, reason why Envio client returns it as that. However, the system manages Unix timestamp in milliseconds to be compliant with Javascript treatment in Date objects (and it's also more usual to work it like this) and also with external providers like Coingecko that also manages timestamps in ms.To fix this, we convert timestamps to MS in Envio indexer client. Also, we create a branded type TimestampMs.
Checklist before requesting a review
Summary by CodeRabbit
Here are the release notes for this pull request:
Type Safety Improvements
TimestampMstype for more precise timestamp handling across multiple packages.TimestampMs, enhancing clarity and type safety.Database Schema Updates
blockTimestampandtimestampMscolumn types tobigintin migration scripts, supporting larger timestamp values for improved data representation.Code Consistency