feat: builder integration #78
Conversation
|
@CodeRabbit full review |
📝 WalkthroughWalkthroughThe change set integrates a new migration processor for transitioning Allo profiles from version 1 to version 2. It introduces a dedicated contract and event handler, along with the corresponding processor implementation and type definitions to process migration events. Legacy project support is incorporated across the codebase by adding new repository classes and interfaces, integrating them into shared dependencies, and updating dependency injection. Numerous modules now include additional timestamp properties to track event timing and new foreign key constraints in the database schema. The update spans indexer configuration changes, modifications in event processing methods and tests to accommodate the migration and legacy project functionality, and enhancements to external API interactions and utilities. ✨ Finishing Touches
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 5
🧹 Nitpick comments (18)
apps/indexer/src/handlers/AlloV1ToV2ProfileMigration.ts (1)
1-6: Missing proper JSDoc documentationAccording to the coding guidelines, all TypeScript code should be documented with JSDoc. This handler lacks proper documentation explaining its purpose, parameters, and functionality.
- // /* - // * Please refer to https://docs.envio.dev for a thorough guide on all Envio indexer features - // */ + /** + * Handler for the ProfileMigrated event from AlloV1ToV2ProfileMigration contract + * + * This handles the migration of profiles from Allo V1 to V2 format + * @see https://docs.envio.dev for a thorough guide on all Envio indexer features + */ import { AlloV1ToV2ProfileMigration } from "../../generated"; AlloV1ToV2ProfileMigration.ProfileMigrated.handler(async ({ event, context }) => { // TODO: Implement migration logic });🧰 Tools
🪛 Biome (1.9.4)
[error] 6-6: Unexpected empty object pattern.
(lint/correctness/noEmptyPattern)
packages/repository/src/types/round.types.ts (1)
46-46: Add JSDoc for timestamp propertyThe newly added
timestampproperty is missing documentation explaining its purpose, format, and usage context.projectId: string; tags: string[]; - timestamp: Date; + /** + * Timestamp when the round was created or processed + */ + timestamp: Date; };packages/repository/src/types/application.types.ts (1)
28-28: Add JSDoc for timestamp propertyThe newly added
timestampproperty lacks documentation explaining its purpose and usage context. This would enhance code maintainability.uniqueDonorsCount: number; - timestamp: Date; + /** + * Timestamp when the application was created or processed + */ + timestamp: Date; tags: string[];packages/repository/src/types/project.types.ts (1)
20-20: Add JSDoc documentation for the new timestamp property.The
timestampproperty has been added to theProjecttype, but lacks JSDoc documentation explaining its purpose and expected format.export type Project = { // ...existing properties + /** + * The timestamp when the project was created or indexed + */ timestamp: Date; };packages/processors/src/external.ts (1)
3-7: Export of the new processor is correctly implemented.The
AlloV1ToV2ProfileMigrationProcessoris now properly exposed through the external API of the processors package, allowing it to be used by dependent modules.Consider adding JSDoc comments describing the purpose of this new processor and when it should be used, as this is part of the public API of the package.
// Add your external exports here export { StrategyProcessor, AlloProcessor, RegistryProcessor, + /** Processor for handling migration of profiles from Allo V1 to V2 */ AlloV1ToV2ProfileMigrationProcessor, } from "./internal.js";packages/repository/src/kysely/repositories/project.repository.ts (1)
110-114: Improved type safety and data handling for project tags.The conditional transformation of the
tagsproperty ensures proper handling of array values by converting them to JSONB format when needed, while preserving the original object structure whentagsisn't an array.Consider adding a type guard function to make the array check more explicit:
function isTagsArray(tags: unknown): tags is string[] { return Array.isArray(tags); }Then use it in your conditional:
- project.tags && Array.isArray(project.tags) + project.tags && isTagsArray(project.tags)This would further improve type safety and code readability.
packages/processors/src/processors/alloV1ToV2ProfileMigration/alloV1ToV2ProfileMigration.processor.ts (1)
23-36: Add JSDoc for the process methodWhile you've provided JSDoc for the class, the
processmethod is missing documentation. Consider adding JSDoc to describe the method's behavior, parameters, and return value.+/** + * Processes an AlloV1ToV2ProfileMigration event by delegating to the appropriate handler based on event name + * @param event - The event to process + * @returns A Promise resolving to an array of Changesets + */ async process( event: ProcessorEvent<"AlloV1ToV2ProfileMigration", AlloV1ToV2ProfileMigrationEvent>, ): Promise<Changeset[]> {scripts/hasura-config/src/utils.ts (1)
19-26: Consider enhancing the singularize function for edge casesThe current implementation only handles the most basic case of pluralization (removing a trailing 's'). It won't work correctly for words with irregular plurals (e.g., "children" → "child") or words ending with 'es', 'ies', etc.
If this function will be used broadly, consider a more robust implementation or a dependency on a library like
pluralize.packages/data-flow/src/data-loader/handlers/legacyProject.handlers.ts (2)
5-8: Update JSDoc comments to reference legacy projects rather than applications.The JSDoc comments currently reference "application-related operations" and "Application changeset type" but should reference legacy projects instead, as this file handles legacy project operations.
-/** - * Collection of handlers for application-related operations. - * Each handler corresponds to a specific Application changeset type. - */ +/** + * Collection of handlers for legacy project-related operations. + * Each handler corresponds to a specific LegacyProject changeset type. + */
13-18: Update JSDoc comments for createLegacyProjectHandlers.The function comment also needs updating to reference legacy projects instead of applications.
-/** - * Creates handlers for managing application-related operations. - * - * @param repository - The application repository instance used for database operations - * @returns An object containing all application-related handlers - */ +/** + * Creates handlers for managing legacy project-related operations. + * + * @param repository - The legacy project repository instance used for database operations + * @returns An object containing all legacy project-related handlers + */packages/data-flow/src/eventsProcessor.ts (1)
43-48: Update JSDoc to include the new event type.The method JSDoc should be updated to include the new
AlloV1ToV2ProfileMigrationEventin the list of valid event types./** * Process an Allo V2 event and return the changesets * @param event - The event to process * @returns The changesets - * @throws InvalidEvent if the event is not a valid Allo V2 event (Allo, Registry or Strategy) + * @throws InvalidEvent if the event is not a valid Allo V2 event (Allo, Registry, Strategy, or AlloV1ToV2ProfileMigration) */packages/processors/src/processors/alloV1ToV2ProfileMigration/handlers/ProfileMigrated.ts (1)
34-34: Add type safety for chain ID conversion.Converting the string to a number and asserting it as a
ChainIdwithout validation could lead to runtime errors if the value isn't a valid chain ID.Consider adding validation or using a safer conversion method:
- v1ChainId: Number(alloV1ChainId) as ChainId, + v1ChainId: validateChainId(Number(alloV1ChainId)),Then add a helper function to validate the chain ID either in this file or in a utilities module.
scripts/migrations/src/migrations/processing/20241029T120000_initial.ts (4)
40-40: Consider indexing the new timestamp column.
Adding an index ontimestampcan improve query performance if you plan to filter or sort on this column frequently.
119-119: Evaluate naming consistency for timestamp columns.
Check that naming (e.g.,timestampvs.createdAtorupdatedAt) remains consistent with your overall schema.
272-284: Verify cascade deletion strategies.
The newly added foreign keys in thedonationstable haveonDeletecascade. Verify this aligns with desired data retention policies, especially if you need donation records retained after a round or application is removed.
308-308: Ensure consistent naming for chain ID columns.
v1ChainIdmight differ from existing naming standards. If you have a pattern (e.g.,chainIdV1), consider aligning it for clarity.scripts/hasura-config/src/services/hasura.api.ts (2)
314-373: Large run_sql payload accepted.
This approach is flexible but might be brittle if the SQL changes. Keep an eye on any potential version mismatch or changes in Postgres internals.
375-403: Ensure robust JSON parsing.
The parsing logic relies on acoalescekey for identifying relationships. Consider handling any unexpected formats or empty results to avoid runtime errors.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (64)
apps/indexer/config.yaml(4 hunks)apps/indexer/src/handlers/AlloV1ToV2ProfileMigration.ts(1 hunks)apps/processing/src/services/sharedDependencies.service.ts(3 hunks)apps/processing/test/unit/sharedDependencies.service.spec.ts(1 hunks)packages/data-flow/src/data-loader/dataLoader.ts(4 hunks)packages/data-flow/src/data-loader/handlers/index.ts(1 hunks)packages/data-flow/src/data-loader/handlers/legacyProject.handlers.ts(1 hunks)packages/data-flow/src/eventsProcessor.ts(4 hunks)packages/data-flow/src/orchestrator.ts(1 hunks)packages/data-flow/src/retroactiveProcessor.ts(1 hunks)packages/data-flow/src/types/index.ts(2 hunks)packages/data-flow/test/data-loader/dataLoader.spec.ts(3 hunks)packages/data-flow/test/data-loader/handlers/project.handlers.spec.ts(1 hunks)packages/data-flow/test/integration/allo.integration.spec.ts(1 hunks)packages/data-flow/test/integration/helpers/dependencies.ts(2 hunks)packages/data-flow/test/integration/registry.integration.spec.ts(1 hunks)packages/data-flow/test/integration/strategy.integration.spec.ts(1 hunks)packages/data-flow/test/unit/eventsProcessor.spec.ts(3 hunks)packages/data-flow/test/unit/orchestrator.spec.ts(2 hunks)packages/data-flow/test/unit/retroactiveProcessor.spec.ts(2 hunks)packages/processors/src/external.ts(1 hunks)packages/processors/src/internal.ts(1 hunks)packages/processors/src/processors/allo/handlers/poolCreated.handler.ts(1 hunks)packages/processors/src/processors/alloV1ToV2ProfileMigration/alloV1ToV2ProfileMigration.processor.ts(1 hunks)packages/processors/src/processors/alloV1ToV2ProfileMigration/handlers/ProfileMigrated.ts(1 hunks)packages/processors/src/processors/alloV1ToV2ProfileMigration/handlers/index.ts(1 hunks)packages/processors/src/processors/alloV1ToV2ProfileMigration/index.ts(1 hunks)packages/processors/src/processors/registry/handlers/profileCreated.handler.ts(1 hunks)packages/processors/src/processors/strategy/directAllocation/handlers/directAllocated.handler.ts(2 hunks)packages/processors/src/processors/strategy/directGrantsLite/handlers/registered.handler.ts(1 hunks)packages/processors/src/processors/strategy/directGrantsSimple/handlers/registered.handler.ts(1 hunks)packages/processors/src/processors/strategy/donationVotingMerkleDistributionDirectTransfer/handlers/registered.handler.ts(1 hunks)packages/processors/test/alloV1ToV2Migration/allo/alloV1ToV2Migration.processor.spec.ts(1 hunks)packages/processors/test/alloV1ToV2Migration/allo/handlers/profileMigrated.handler.spec.ts(1 hunks)packages/processors/test/registry/handlers/profileCreated.handler.spec.ts(4 hunks)packages/processors/test/strategy/directAllocation/handlers/directAllocated.handler.spec.ts(2 hunks)packages/processors/test/strategy/directGrantsLite/handlers/registered.handler.spec.ts(1 hunks)packages/processors/test/strategy/directGrantsSimple/handlers/registered.handler.spec.ts(1 hunks)packages/processors/test/strategy/donationVotingMerkleDistributionDirectTransfer/handlers/registered.handler.spec.ts(1 hunks)packages/repository/src/db/connection.ts(2 hunks)packages/repository/src/external.ts(4 hunks)packages/repository/src/interfaces/index.ts(1 hunks)packages/repository/src/interfaces/legacyProjectRepository.interface.ts(1 hunks)packages/repository/src/kysely/repositories/application.repository.ts(1 hunks)packages/repository/src/kysely/repositories/index.ts(1 hunks)packages/repository/src/kysely/repositories/legacyProject.repository.ts(1 hunks)packages/repository/src/kysely/repositories/project.repository.ts(1 hunks)packages/repository/src/kysely/repositories/round.repository.ts(1 hunks)packages/repository/src/types/application.types.ts(1 hunks)packages/repository/src/types/changeset.types.ts(2 hunks)packages/repository/src/types/donation.types.ts(1 hunks)packages/repository/src/types/index.ts(1 hunks)packages/repository/src/types/legacyProject.types.ts(1 hunks)packages/repository/src/types/project.types.ts(1 hunks)packages/repository/src/types/round.types.ts(1 hunks)packages/shared/src/external.ts(1 hunks)packages/shared/src/types/events/alloV1ToV2ProfileMigration.ts(1 hunks)packages/shared/src/types/events/common.ts(3 hunks)packages/shared/src/types/events/index.ts(1 hunks)scripts/hasura-config/src/index.ts(1 hunks)scripts/hasura-config/src/services/hasura.api.ts(4 hunks)scripts/hasura-config/src/utils.ts(1 hunks)scripts/migrations/src/migrations/external_services_cache/20250127T000000_add_cache_tables.ts(1 hunks)scripts/migrations/src/migrations/processing/20241029T120000_initial.ts(5 hunks)
🧰 Additional context used
📓 Path-based instructions (4)
`**/*.ts`: Review TypeScript files for adherence to the fo...
**/*.ts: Review TypeScript files for adherence to the following guidelines:
- Avoid over-abstraction; prioritize composition over inheritance.
- Use dependency injection and follow SOLID principles.
- Avoidany; useunknownwhen necessary.
- Use runtime type-checking for environment variables (e.g., Zod).
- Prevent circular dependencies with the internal module pattern.
- Libraries should have anexternal.tsfile explicitly listing public exports.
- Usebigintas-is; cast toNumberonly 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/kysely/repositories/index.tsapps/indexer/src/handlers/AlloV1ToV2ProfileMigration.tsscripts/migrations/src/migrations/external_services_cache/20250127T000000_add_cache_tables.tspackages/repository/src/types/project.types.tspackages/processors/src/processors/strategy/donationVotingMerkleDistributionDirectTransfer/handlers/registered.handler.tspackages/processors/src/internal.tspackages/processors/test/strategy/directGrantsSimple/handlers/registered.handler.spec.tspackages/processors/src/processors/alloV1ToV2ProfileMigration/index.tspackages/processors/src/processors/alloV1ToV2ProfileMigration/handlers/index.tspackages/processors/src/processors/registry/handlers/profileCreated.handler.tsscripts/hasura-config/src/index.tspackages/processors/src/processors/strategy/directAllocation/handlers/directAllocated.handler.tsapps/processing/test/unit/sharedDependencies.service.spec.tspackages/repository/src/types/legacyProject.types.tspackages/data-flow/test/data-loader/handlers/project.handlers.spec.tspackages/repository/src/types/round.types.tspackages/repository/src/kysely/repositories/application.repository.tspackages/data-flow/test/data-loader/dataLoader.spec.tspackages/shared/src/external.tspackages/data-flow/src/orchestrator.tspackages/data-flow/test/unit/orchestrator.spec.tspackages/repository/src/interfaces/legacyProjectRepository.interface.tspackages/data-flow/test/integration/helpers/dependencies.tspackages/data-flow/test/integration/registry.integration.spec.tspackages/repository/src/db/connection.tspackages/processors/test/alloV1ToV2Migration/allo/handlers/profileMigrated.handler.spec.tspackages/processors/test/strategy/directAllocation/handlers/directAllocated.handler.spec.tspackages/data-flow/test/integration/allo.integration.spec.tspackages/processors/src/processors/strategy/directGrantsSimple/handlers/registered.handler.tspackages/data-flow/src/data-loader/handlers/index.tspackages/processors/src/processors/alloV1ToV2ProfileMigration/alloV1ToV2ProfileMigration.processor.tspackages/processors/src/processors/allo/handlers/poolCreated.handler.tspackages/repository/src/types/changeset.types.tspackages/repository/src/interfaces/index.tspackages/repository/src/kysely/repositories/legacyProject.repository.tsapps/processing/src/services/sharedDependencies.service.tspackages/data-flow/src/retroactiveProcessor.tspackages/processors/test/strategy/donationVotingMerkleDistributionDirectTransfer/handlers/registered.handler.spec.tspackages/processors/src/external.tspackages/repository/src/types/donation.types.tspackages/processors/src/processors/alloV1ToV2ProfileMigration/handlers/ProfileMigrated.tspackages/processors/test/registry/handlers/profileCreated.handler.spec.tspackages/shared/src/types/events/index.tspackages/data-flow/test/unit/eventsProcessor.spec.tspackages/data-flow/src/data-loader/dataLoader.tsscripts/hasura-config/src/utils.tspackages/repository/src/kysely/repositories/project.repository.tspackages/shared/src/types/events/common.tspackages/processors/test/alloV1ToV2Migration/allo/alloV1ToV2Migration.processor.spec.tspackages/data-flow/src/types/index.tspackages/repository/src/types/index.tspackages/data-flow/src/eventsProcessor.tsscripts/hasura-config/src/services/hasura.api.tspackages/repository/src/types/application.types.tspackages/data-flow/test/integration/strategy.integration.spec.tspackages/data-flow/src/data-loader/handlers/legacyProject.handlers.tspackages/data-flow/test/unit/retroactiveProcessor.spec.tspackages/processors/test/strategy/directGrantsLite/handlers/registered.handler.spec.tspackages/repository/src/external.tspackages/processors/src/processors/strategy/directGrantsLite/handlers/registered.handler.tsscripts/migrations/src/migrations/processing/20241029T120000_initial.tspackages/repository/src/kysely/repositories/round.repository.tspackages/shared/src/types/events/alloV1ToV2ProfileMigration.ts
`scripts/**/*.ts`: Ensure scripts: - Use `process.cw...
scripts/**/*.ts: Ensure scripts:
- Useprocess.cwd()for root references.
- Follow folder conventions (infra/for infra scripts,utilities/for utilities).
- Are organized inpackage.jsonwithscript:infra:{name}orscript:util:{name}.
- Be concise and avoid overly nitpicky feedback outside of these best practices.
scripts/migrations/src/migrations/external_services_cache/20250127T000000_add_cache_tables.tsscripts/hasura-config/src/index.tsscripts/hasura-config/src/utils.tsscripts/hasura-config/src/services/hasura.api.tsscripts/migrations/src/migrations/processing/20241029T120000_initial.ts
`**/*.spec.ts`: Review the unit test files with the followin...
**/*.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/directGrantsSimple/handlers/registered.handler.spec.tsapps/processing/test/unit/sharedDependencies.service.spec.tspackages/data-flow/test/data-loader/handlers/project.handlers.spec.tspackages/data-flow/test/data-loader/dataLoader.spec.tspackages/data-flow/test/unit/orchestrator.spec.tspackages/data-flow/test/integration/registry.integration.spec.tspackages/processors/test/alloV1ToV2Migration/allo/handlers/profileMigrated.handler.spec.tspackages/processors/test/strategy/directAllocation/handlers/directAllocated.handler.spec.tspackages/data-flow/test/integration/allo.integration.spec.tspackages/processors/test/strategy/donationVotingMerkleDistributionDirectTransfer/handlers/registered.handler.spec.tspackages/processors/test/registry/handlers/profileCreated.handler.spec.tspackages/data-flow/test/unit/eventsProcessor.spec.tspackages/processors/test/alloV1ToV2Migration/allo/alloV1ToV2Migration.processor.spec.tspackages/data-flow/test/integration/strategy.integration.spec.tspackages/data-flow/test/unit/retroactiveProcessor.spec.tspackages/processors/test/strategy/directGrantsLite/handlers/registered.handler.spec.ts
`**/services/**/*.ts`: Review service files with the followi...
**/services/**/*.ts: Review service files with the following considerations:
- A Service encapsulates a broader business workflow and might orchestrate various components or interact with multiple data sources or APIs.
- Ensure proper composability: Services should use Providers for data/resource access and apply business/orchestration logic.
- Validate naming conventions for aggregating services (e.g.,AggregatorServiceor domain-specific names likeMetricsService).
apps/processing/src/services/sharedDependencies.service.tsscripts/hasura-config/src/services/hasura.api.ts
🪛 Biome (1.9.4)
apps/indexer/src/handlers/AlloV1ToV2ProfileMigration.ts
[error] 6-6: Unexpected empty object pattern.
(lint/correctness/noEmptyPattern)
🔇 Additional comments (84)
packages/repository/src/kysely/repositories/index.ts (1)
12-12: LGTM: New export for LegacyProject repositoryThis export statement correctly makes the legacy project repository implementation available to other modules that import from this index file. This is in line with the modular architecture of the codebase.
packages/repository/src/interfaces/index.ts (1)
13-13: LGTM: New export for LegacyProject repository interfaceThis export statement correctly makes the
ILegacyProjectRepositoryinterface available to other modules. This follows the existing pattern for interface exports and maintains a clean separation between interfaces and implementations.packages/data-flow/src/data-loader/handlers/index.ts (1)
7-7: LGTM: New export for LegacyProject handlersThis export statement appropriately includes the legacy project handlers, allowing them to be imported through the index file. This maintains consistency with how other handlers are exported.
packages/processors/src/processors/alloV1ToV2ProfileMigration/handlers/index.ts (1)
1-1: LGTM: New export for ProfileMigrated handlerThis export statement correctly makes the ProfileMigrated handler available for the Allo V1 to V2 profile migration processor. Creating this index file follows the pattern used in other parts of the codebase.
scripts/hasura-config/src/index.ts (1)
29-29: LGTM!Adding the "events_registry" table to the tracked tables list is appropriate. This will ensure Hasura correctly configures permissions and relationships for this table.
packages/processors/test/strategy/directGrantsLite/handlers/registered.handler.spec.ts (1)
99-99: LGTM!The addition of the timestamp property correctly uses the event's block timestamp, maintaining consistency with the updated application schema.
packages/data-flow/src/orchestrator.ts (1)
126-126: LGTM!Properly integrating the legacy project repository into the DataLoader's dependencies follows good dependency injection practices.
packages/shared/src/types/events/index.ts (1)
2-2: The new export looks good.The added export statement correctly exposes the AlloV1ToV2ProfileMigration events types for use throughout the application.
apps/processing/test/unit/sharedDependencies.service.spec.ts (1)
50-50: Good addition of the new repository mock.The mock for
KyselyLegacyProjectRepositoryis correctly added to align with the updated implementation in theSharedDependenciesService. Consider also adding a verification check in the test to ensure this new repository is properly included in the returned dependencies.packages/processors/src/processors/strategy/directAllocation/handlers/directAllocated.handler.ts (1)
71-71: This change improves how we represent the absence of an application.The change from using
zeroAddresstonullforapplicationIdis a more semantically accurate representation of donations that aren't associated with an application. This change properly aligns with the updatedDonationtype that now allows for null values.packages/processors/src/processors/alloV1ToV2ProfileMigration/index.ts (1)
1-2: LGTM! Clean barrel file structure for the migrator.This follows the internal module pattern nicely by creating a clean public API for the Allo V1 to V2 profile migration processor.
packages/processors/src/processors/strategy/directGrantsSimple/handlers/registered.handler.ts (1)
85-85: Timestamp addition enhances application auditing capabilities.Adding the timestamp to track when applications are created provides valuable metadata for analytics and auditing purposes. This aligns with the PR objective of adding timestamps to applications tables.
packages/processors/test/strategy/directGrantsSimple/handlers/registered.handler.spec.ts (1)
95-95: Test properly updated to match implementation changes.The test expectation now includes the timestamp field that was added to the application entity, maintaining test coverage for the new field.
packages/processors/src/processors/strategy/donationVotingMerkleDistributionDirectTransfer/handlers/registered.handler.ts (1)
79-79: Timestamp addition enhances data tracking.Adding the timestamp property to the application object improves temporal data tracking, which is valuable for analytics and debugging. The implementation correctly derives the timestamp from the blockchain event data.
packages/data-flow/test/integration/registry.integration.spec.ts (1)
120-120: Timestamp addition in test maintains consistency with implementation.Adding the timestamp to the test expectations ensures proper alignment with the implementation changes. This maintains test validity while supporting the timestamp integration across the codebase.
packages/repository/src/types/donation.types.ts (1)
7-7:❓ Verification inconclusive
Type change enables donations without applications.
Modifying
applicationIdto accept null values is a significant change that allows donations to exist without being linked to a specific application. This enhances flexibility in your data model.
🏁 Script executed:
#!/bin/bash # Check if the applicationId is being set to null in any handlers rg -n "applicationId: null" --type=typescriptLength of output: 82
Action Required: Verify Donation
applicationIdUsageThe change to allow
applicationIdto benullenhances flexibility by enabling donations without linked applications. However, the initial verification command failed because the “typescript” file type isn’t recognized byrg. Please re-run the verification using a command with a proper file glob. For example:#!/bin/bash # Verify that handlers correctly accommodate a nullable applicationId value. rg -n "applicationId\s*=\s*null" -g "*.ts"Manually confirm that no handlers improperly assume a non-null
applicationId, ensuring that donations without an associated application are handled correctly.packages/data-flow/test/data-loader/handlers/project.handlers.spec.ts (1)
45-45: Timestamp addition to test object maintains test coverage.Adding the timestamp property to the test object ensures that tests reflect the current data model. Using
new Date()is appropriate for this context.packages/data-flow/test/integration/allo.integration.spec.ts (1)
156-156: Adding timestamp tracking to roundsThe addition of the timestamp property ensures proper tracking of when rounds are created, allowing for better data consistency and chronological ordering of events. This matches the PR objective of adding timestamps to tables including rounds.
packages/repository/src/db/connection.ts (2)
18-18: Added import for LegacyProject tableThis import is correctly added to support the legacy project functionality being implemented.
81-81: Added legacyProjects property to Database interfaceThe addition of this property to the Database interface properly extends the schema to include legacy projects, following the same naming convention as other table properties.
packages/data-flow/test/unit/orchestrator.spec.ts (2)
14-14: Added import for ILegacyProjectRepositoryThe import is correctly added to support the integration of legacy project functionality.
123-123: Added legacyProjectRepository to dependenciesThis addition ensures that the Orchestrator test setup includes the legacyProjectRepository dependency, maintaining consistency with the actual implementation and supporting the PR's objective of integrating legacy project support.
packages/processors/src/processors/registry/handlers/profileCreated.handler.ts (1)
71-71: Added timestamp property to projectThe timestamp property provides chronological tracking for project creation, properly utilizing the event's blockTimestamp. This addition aligns with the PR objective of adding timestamps to tables including projects.
packages/processors/test/strategy/donationVotingMerkleDistributionDirectTransfer/handlers/registered.handler.spec.ts (1)
119-119: LGTM: Added timestamp property to application objectThis change correctly adds a timestamp property to the application object in the test expectations, ensuring test coverage for the corresponding implementation change. The timestamp is properly initialized from the block timestamp.
packages/processors/src/processors/allo/handlers/poolCreated.handler.ts (1)
130-130: LGTM: Added timestamp property to NewRound objectThe timestamp property is consistently added to the NewRound object to track when the pool was created. This matches similar timestamp additions across the codebase, improving data observability.
packages/repository/src/types/legacyProject.types.ts (1)
1-14: LGTM: Well-structured type definitions for legacy project integrationThe type definitions are clear, properly leverage Kysely's type system, and follow TypeScript best practices. The file establishes the foundation for the builder integration by defining the relationship between v1 and v2 projects.
packages/processors/src/internal.ts (1)
19-21: LGTM: Clean export of the Allo V1 to V2 migration moduleThe export follows the established pattern in this file, with proper commenting and organization. This change makes the migration functionality accessible to the rest of the application.
packages/shared/src/external.ts (1)
28-33: Looks good! Appropriate grouping of migration event check functionThe new
isAlloV1ToV2ProfileMigrationEventexport is properly grouped with other similar event checking functions, following the established naming convention for type-checking functions.packages/data-flow/src/types/index.ts (2)
8-8: LGTM! Import is properly orderedThe
ILegacyProjectRepositoryimport is correctly added in alphabetical order among the other repository interfaces.
34-34: LGTM! Property follows consistent naming patternThe
legacyProjectRepositoryproperty follows the same naming convention as other repository properties within theCoreDependenciestype.packages/processors/src/processors/strategy/directGrantsLite/handlers/registered.handler.ts (1)
84-84: Good addition of timestamp trackingAdding the timestamp property to the application object ensures proper temporal tracking of when applications are created. The implementation correctly reuses the existing
blockTimestampvalue, following the pattern used in thestatusSnapshotsarray.packages/data-flow/test/data-loader/dataLoader.spec.ts (3)
9-9: LGTM! Import additionProperly imported the
ILegacyProjectRepositoryinterface.
50-52: Good mock implementationThe mock legacy project repository follows the same implementation pattern as other repositories in the test file with appropriate Jest mock functions.
75-75: LGTM! Proper test setupThe mock legacy project repository is correctly integrated into the DataLoader constructor within the beforeEach setup, ensuring tests work with the updated dependencies.
packages/data-flow/test/unit/retroactiveProcessor.spec.ts (2)
9-9: Properly importing the new interface.Adding the
ILegacyProjectRepositoryimport is consistent with the other repository interfaces.
146-146:✅ Verification successful
Added legacy project repository to test dependencies.
Correctly integrates the legacy project repository dependency into the test setup.
Since this is using an empty object with type assertion, verify that the test doesn't call any methods on this repository:
🏁 Script executed:
#!/bin/bash # Check where the legacy project repository is used in the test file rg -A 3 -B 3 "legacyProjectRepository" packages/data-flow/test/unit/retroactiveProcessor.spec.tsLength of output: 496
Legacy project repository dependency correctly integrated.
The test declareslegacyProjectRepositoryas an empty object with a type assertion, and our verification confirms that no methods are invoked on this dependency. No further changes are needed.packages/data-flow/src/retroactiveProcessor.ts (1)
110-110: Added legacy project repository to DataLoader dependencies.The change properly injects the legacy project repository into the DataLoader, following the dependency injection pattern.
packages/repository/src/interfaces/legacyProjectRepository.interface.ts (1)
1-14: Well-defined interface for legacy project repository.The interface follows TypeScript best practices with proper generic typing and comprehensive JSDoc documentation.
The interface is concise and follows the repository pattern consistently with other repositories in the system. The generic transaction parameter allows for flexible transaction handling.
packages/processors/src/processors/alloV1ToV2ProfileMigration/alloV1ToV2ProfileMigration.processor.ts (1)
12-37: LGTM - Good implementation of IProcessor with dependency injectionThe processor implementation follows good TypeScript practices with proper typing, dependency injection, and error handling. The class properly implements the IProcessor interface and handles events with a clean switch statement pattern.
packages/data-flow/test/integration/helpers/dependencies.ts (1)
24-43: LGTM - Clean implementation of mock legacyProjectRepositoryThe addition of
legacyProjectRepositoryto the mock repositories is done cleanly, maintaining consistency with the existing code structure.packages/repository/src/kysely/repositories/application.repository.ts (1)
139-143: Improved handling of application tags during updateThe conditional logic for handling tags during updates improves the robustness of the code by ensuring tags are only transformed when they exist and are in the correct format.
scripts/hasura-config/src/utils.ts (1)
1-18: LGTM - Well-documented string case conversion utilitiesThe string case conversion functions are well-documented with JSDoc and implement the conversions correctly using regex patterns.
packages/processors/test/registry/handlers/profileCreated.handler.spec.ts (1)
115-115: Well-implemented timestamp addition.The timestamp property has been consistently added to all test expectations, correctly derived from the event's blockTimestamp. This matches the implementation changes and ensures proper test coverage for the new field.
Also applies to: 196-196, 290-290, 336-336
packages/repository/src/external.ts (1)
11-11: Clean integration of legacy project exports.The added exports for legacy project interfaces, types, and implementations follow the established pattern in this module. This is a good example of maintaining a clear, well-defined public API.
Also applies to: 40-40, 54-54, 66-66
packages/repository/src/kysely/repositories/round.repository.ts (1)
153-157: Improved tags handling in updateRound method.Good defensive programming approach by checking if tags exist and are an array before applying the stringArrayToJsonb transformation. This change aligns with the insertRound method and ensures consistent handling of array data in PostgreSQL.
packages/data-flow/src/data-loader/handlers/legacyProject.handlers.ts (1)
19-25: Well-structured handler implementation with proper type safety.The implementation follows the established pattern for handlers in the codebase and uses the
satisfiesoperator to ensure type compliance. Good job!packages/data-flow/src/eventsProcessor.ts (4)
4-4: LGTM! Imports are properly organized and follow the same convention as other imports in this file.The imports for the new
AlloV1ToV2ProfileMigrationProcessorand the type guard functionisAlloV1ToV2ProfileMigrationEventare correctly organized within their respective import groups.Also applies to: 14-14
31-31: LGTM! Property declaration follows class structure conventions.The declaration of
alloV1ToV2MigrationProcessorproperty follows the same pattern as other processor properties in this class.
37-40: LGTM! Constructor initialization follows existing pattern.The initialization of the new processor in the constructor follows the same pattern as other processors, properly passing the chainId and dependencies parameters.
59-61: LGTM! Event handling follows established pattern.The conditional branch for handling
AlloV1ToV2ProfileMigrationEventfollows the same pattern as other event types, maintaining consistency in the codebase.packages/processors/test/strategy/directAllocation/handlers/directAllocated.handler.spec.ts (1)
1-1: Correctly updated applicationId to use null instead of zeroAddress.The change from using
zeroAddresstonullfor theapplicationIdfield is a good improvement, as it more accurately represents the absence of an application. This also aligns with updates to theDonationtype in the repository.Also applies to: 98-98
packages/repository/src/kysely/repositories/legacyProject.repository.ts (2)
1-15: LGTM! Repository implementation follows best practices.The
KyselyLegacyProjectRepositoryclass is well-structured with proper dependency injection in the constructor, adhering to the SOLID principles. The repository implements theILegacyProjectRepositoryinterface, promoting good design practices.
17-41: LGTM! Method implementation with proper error handling.The
insertLegacyProjectmethod is well-implemented with:
- Clear parameter typing
- Support for transaction handling
- Proper error handling using
handlePostgresError- Consistent with other repository implementations in the codebase
The method follows the repository pattern correctly by handling the database operation and providing meaningful error information.
packages/processors/test/alloV1ToV2Migration/allo/handlers/profileMigrated.handler.spec.ts (3)
1-37: LGTM! Well-structured test setup with clean mock creation.The test setup is well-organized with:
- Proper imports
- A useful helper function
createMockEventto generate standardized test data- Clear type definitions
- Default values that can be overridden for test flexibility
39-56: LGTM! Test setup follows best practices.The test setup follows best practices with:
- Clear mock initialization in
beforeEach- Proper cleanup in
afterEachusingvi.clearAllMocks()- Clean dependency organization through the
mockDependenciesfunction
57-76: LGTM! Test case has clear assertions and follows naming conventions.The test case:
- Has a descriptive name that clearly states what is being tested
- Does not use "should" in the description (following guidelines)
- Has clear expectations that validate the complete output of the handler
- Tests the core functionality of mapping migration event data to legacy project data
apps/processing/src/services/sharedDependencies.service.ts (3)
16-16: Import added for KyselyLegacyProjectRepositoryThe import has been correctly added to the list of repository imports.
76-79: LGTM: Repository initialization follows existing patternThe initialization of the legacyProjectRepository follows the established pattern of other repositories with consistent parameter passing.
161-161: LGTM: Core dependency additionThe legacyProjectRepository has been correctly added to the core dependencies object.
packages/repository/src/types/changeset.types.ts (3)
3-20: Import organization refined with additional importsThe imports have been reorganized to include
NewLegacyProjectand improve overall structure.
179-184: LGTM: Legacy project changeset type follows established patternThe new
LegacyProjectChangesettype follows the same structure as other changeset types, maintaining consistency in the codebase.
186-193: LGTM: Changeset union type updated properlyThe
Changesetunion type has been correctly updated to include the newLegacyProjectChangeset.packages/data-flow/src/data-loader/dataLoader.ts (4)
7-7: Interface dependency correctly importedThe
ILegacyProjectRepositoryinterface has been properly added to the imports.
19-23: Handler imports updated for new functionalityThe imports have been updated to include
createLegacyProjectHandlersandcreateProcessedEventHandlers.
50-50: LGTM: Repository parameter added to constructorThe
legacyProjectparameter has been correctly added to the repositories object in the constructor.
62-62: LGTM: Handler initialization integrated properlyThe legacy project handlers have been correctly added to the handlers map, following the pattern used for other entity types.
packages/processors/test/alloV1ToV2Migration/allo/alloV1ToV2Migration.processor.spec.ts (3)
1-28: Test setup and mocking approach is well-structuredThe imports and mock setup follow best practices for unit testing, properly isolating the test subject from its dependencies.
29-61: Test initialization follows best practicesThe test setup creates fresh instances of mocks and the processor for each test, maintaining test isolation.
80-86: LGTM: Error handling test is comprehensiveThe test properly verifies that an UnsupportedEventException is thrown when an unknown event name is provided.
apps/indexer/config.yaml (3)
33-36: Contract configuration looks good.The new
AlloV1ToV2ProfileMigrationcontract is properly defined with the appropriate handler and event structure. This will enable the processing of profile migration events between Allo V1 and V2.
164-176: Network configuration for arbitrum is properly implemented.The
AlloV1ToV2ProfileMigrationcontract has been correctly integrated into the arbitrum network configuration with the appropriate address.
290-302: Network configuration for sepolia is properly implemented.The
AlloV1ToV2ProfileMigrationcontract has been correctly integrated into the sepolia network configuration with the appropriate address.packages/shared/src/types/events/alloV1ToV2ProfileMigration.ts (1)
1-42: Type definitions are well structured.The type definitions for the AlloV1ToV2ProfileMigration events are well-organized, properly documented with JSDoc, and follow TypeScript best practices. The type guard implementation is correctly implemented to verify events.
packages/data-flow/test/unit/eventsProcessor.spec.ts (2)
5-5: Test setup for the new processor follows established patterns.The integration of the AlloV1ToV2ProfileMigrationProcessor in the test setup follows the existing patterns used for other processors, making the code consistent and maintainable.
Also applies to: 26-26, 34-34, 42-50
109-133: Test case is well implemented.The test case for processing AlloV1ToV2ProfileMigration events is thorough and follows the same structure as the existing tests. It properly verifies that the processor is called with the correct event and that the result matches the expected changeset.
packages/data-flow/test/integration/strategy.integration.spec.ts (1)
589-589: Check the blockTimestamp unit carefully.
IfregisteredEvent.blockTimestampis in seconds rather than milliseconds, usingnew Date(registeredEvent.blockTimestamp)might produce an incorrect time.Would you like a quick script to scan for any usage of
new Date(...)with potential second-based timestamps so we can confirm correctness?scripts/migrations/src/migrations/processing/20241029T120000_initial.ts (1)
208-208: Confirm default or nullability.
Consider specifying a default value or explicitly marking the column as nullable if timestamps can be missing.packages/shared/src/types/events/common.ts (2)
3-7: Additions to support AlloV1ToV2ProfileMigration event look good.
This import and extension of types is consistent with your naming patterns.Also applies to: 14-15
32-34: Appropriate extension of type mappings for AlloV1ToV2ProfileMigration.
The conditional branches forContractToEventNameandEventParamsare consistently updated.Also applies to: 51-55
scripts/hasura-config/src/services/hasura.api.ts (5)
1-1: No immediate impact from the commented-out import.
This line appears unused. Leaving it commented has no effect.
6-6: Utility imports look fine.
Using helpers likesingularizeorsnakeToCamelCaseis a neat approach for naming relationships.
8-22: New type definitions for foreign key relationships.
Structuring foreign key info intoFetchFkRelationshipResultandFkRelationshipis clear and maintainable.
103-104: Verify table filtering in getFkRelationships.
Currently, it fetches from all public tables. Confirm if you need to refine or limit scope to only those specified in thetablesargument.Also applies to: 107-113
128-178: Check relationship naming collisions.
When generating relationship names, ensure no collisions occur ifsingularizeorsnakeToCamelCaseproduce identical names across different tables.
| // */ | ||
| import { AlloV1ToV2ProfileMigration } from "../../generated"; | ||
|
|
||
| AlloV1ToV2ProfileMigration.ProfileMigrated.handler(async ({}) => {}); |
There was a problem hiding this comment.
Empty handler implementation needs proper parameter destructuring
The handler function has an empty parameter destructuring pattern and an empty function body. According to the static analysis tool, this is a correctness issue. You should explicitly define the expected parameters and implement the handler logic.
- AlloV1ToV2ProfileMigration.ProfileMigrated.handler(async ({}) => {});
+ AlloV1ToV2ProfileMigration.ProfileMigrated.handler(async ({ event, context }) => {
+ // TODO: Implement migration logic
+ });📝 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.
| AlloV1ToV2ProfileMigration.ProfileMigrated.handler(async ({}) => {}); | |
| AlloV1ToV2ProfileMigration.ProfileMigrated.handler(async ({ event, context }) => { | |
| // TODO: Implement migration logic | |
| }); |
🧰 Tools
🪛 Biome (1.9.4)
[error] 6-6: Unexpected empty object pattern.
(lint/correctness/noEmptyPattern)
There was a problem hiding this comment.
we're fine with the empty handler for the handlers of the Indexer app
There was a problem hiding this comment.
@0xnigir1 Understood! I'll remember that empty handlers are acceptable for the Indexer app in your codebase. Thanks for clarifying your team's preference.
✏️ Learnings added
Learnt from: 0xnigir1
PR: defi-wonderland/grants-stack-indexer-v2#78
File: apps/indexer/src/handlers/AlloV1ToV2ProfileMigration.ts:6-6
Timestamp: 2025-02-26T21:54:46.207Z
Learning: Empty handlers (both empty parameter destructuring patterns and empty function bodies) are acceptable in the handlers of the Indexer app.
Note: Learnings are effective only in the context of similar code segments. To apply general coding guidelines, please configure review instructions. You can manage existing learnings in the app.
| @@ -10,3 +10,4 @@ export * from "./strategyProcessingCheckpoint.types.js"; | |||
| export * from "./transaction.types.js"; | |||
| export * from "./metadata.types.js"; | |||
| export * from "./price.types.js"; | |||
| export * from "./legacyProject.types.js"; | |||
There was a problem hiding this comment.
💡 Verification agent
🧩 Analysis chain
Verify existence of referenced type file
The code is exporting from "legacyProject.types.js" which is a critical addition for the builder integration feature. Ensure this file exists and contains the necessary type definitions.
🏁 Script executed:
#!/bin/bash
# Check if the legacyProject.types.js file exists in the repository
echo "Checking for legacyProject.types.ts file..."
fd --type f -g "legacyProject.types.ts" packages/repository/src/types/Length of output: 220
Mismatch between referenced file and actual file
The export in packages/repository/src/types/index.ts currently reads:
export * from "./legacyProject.types.js";However, our verification shows that the actual file in the directory is named legacyProject.types.ts. Please review whether this mismatch is intentional. If the build process is supposed to generate a .js file for the builder integration, ensure that the generated file is available at runtime. Otherwise, consider updating the export statement to reference legacyProject.types.ts to align with the source file name.
- Location to review:
packages/repository/src/types/index.ts(line 13) - Action required: Verify and adjust the file reference if necessary so that it correctly points to the existing type definitions.
There was a problem hiding this comment.
@jahabeebs I understand that this is intentional. Thanks for confirming! Using .js extensions in the export statements while working with TypeScript files is a common pattern, as it points to the compiled JavaScript files that will exist at runtime after the TypeScript compilation process.
| @@ -13,7 +13,7 @@ export async function up(db: Kysely<unknown>): Promise<void> { | |||
| // Create metadata cache table | |||
| await db.schema | |||
| .createTable("metadataCache") | |||
| .addColumn("id", "text", (col) => col.notNull()) | |||
| .addColumn("id", "text") | |||
There was a problem hiding this comment.
Primary key column should not allow NULL values.
The id column is defined as a primary key (line 19) but has been modified to allow NULL values. This can potentially cause database constraint issues since primary keys must be unique and non-null.
-.addColumn("id", "text")
+.addColumn("id", "text", (col) => col.notNull())📝 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.
| .addColumn("id", "text") | |
| .addColumn("id", "text", (col) => col.notNull()) |
There was a problem hiding this comment.
^ how come this validation was removed?
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Search for occurrences of "metadataCache" in the codebase to understand how this table is used
rg "metadataCache" --type ts -A 5 -B 5
Length of output: 6186
@jahabeebs This change appears to be redundant or possibly an oversight. The id column is defined as part of the primary key with .addPrimaryKeyConstraint("metadata_cache_pkey", ["id"]), which already implicitly enforces that the column cannot be NULL.
In PostgreSQL (which this project uses based on the timestamptz type), primary key columns are automatically NOT NULL even without the explicit constraint. However, explicitly declaring notNull() is still considered best practice for schema clarity and to prevent potential issues if the schema is modified in the future.
Was there a specific reason for removing this validation? If not, I'd recommend restoring the explicit NOT NULL constraint to maintain schema integrity and clarity.
| it("call ProfileMigratedHandler for PoolCreated event", async () => { | ||
| const mockEvent: ProcessorEvent<"AlloV1ToV2ProfileMigration", "ProfileMigrated"> = { | ||
| eventName: "ProfileMigrated", | ||
| // Add other necessary event properties here | ||
| } as ProcessorEvent<"AlloV1ToV2ProfileMigration", "ProfileMigrated">; | ||
|
|
||
| vi.spyOn(ProfileMigratedHandler.prototype, "handle").mockResolvedValue([]); | ||
|
|
||
| await processor.process(mockEvent); | ||
|
|
||
| expect(ProfileMigratedHandler).toHaveBeenCalledWith( | ||
| mockEvent, | ||
| mockChainId, | ||
| processor["dependencies"], | ||
| ); | ||
| expect(ProfileMigratedHandler.prototype.handle).toHaveBeenCalled(); | ||
| }); |
There was a problem hiding this comment.
🛠️ Refactor suggestion
Fix test name to match actual event being tested
There's an inconsistency in the test name that refers to "PoolCreated" event while the test is actually testing the "ProfileMigrated" event.
Apply this correction:
- it("call ProfileMigratedHandler for PoolCreated event", async () => {
+ it("calls ProfileMigratedHandler for ProfileMigrated event", async () => {Additionally, the mock event is incomplete - consider adding all required properties that the handler would expect rather than relying on type casting.
📝 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.
| it("call ProfileMigratedHandler for PoolCreated event", async () => { | |
| const mockEvent: ProcessorEvent<"AlloV1ToV2ProfileMigration", "ProfileMigrated"> = { | |
| eventName: "ProfileMigrated", | |
| // Add other necessary event properties here | |
| } as ProcessorEvent<"AlloV1ToV2ProfileMigration", "ProfileMigrated">; | |
| vi.spyOn(ProfileMigratedHandler.prototype, "handle").mockResolvedValue([]); | |
| await processor.process(mockEvent); | |
| expect(ProfileMigratedHandler).toHaveBeenCalledWith( | |
| mockEvent, | |
| mockChainId, | |
| processor["dependencies"], | |
| ); | |
| expect(ProfileMigratedHandler.prototype.handle).toHaveBeenCalled(); | |
| }); | |
| it("calls ProfileMigratedHandler for ProfileMigrated event", async () => { | |
| const mockEvent: ProcessorEvent<"AlloV1ToV2ProfileMigration", "ProfileMigrated"> = { | |
| eventName: "ProfileMigrated", | |
| // Add other necessary event properties here | |
| } as ProcessorEvent<"AlloV1ToV2ProfileMigration", "ProfileMigrated">; | |
| vi.spyOn(ProfileMigratedHandler.prototype, "handle").mockResolvedValue([]); | |
| await processor.process(mockEvent); | |
| expect(ProfileMigratedHandler).toHaveBeenCalledWith( | |
| mockEvent, | |
| mockChainId, | |
| processor["dependencies"], | |
| ); | |
| expect(ProfileMigratedHandler.prototype.handle).toHaveBeenCalled(); | |
| }); |
| /** | ||
| * Handles the ProfileMigrated event for the Registry contract from Allo protocol. | ||
| * | ||
| * This handler performs the following steps: | ||
| * - Fetches the metadata for the profile from the metadata provider | ||
| * - Parses the metadata to extract the project type | ||
| * - Returns the changeset to insert the project with the metadata | ||
| * | ||
| * If the metadata is not valid, it sets the metadata to null and the project type to canonical. | ||
| */ |
There was a problem hiding this comment.
🛠️ Refactor suggestion
JSDoc comments don't match implementation.
The JSDoc comments describe steps that aren't actually implemented in the code, such as fetching metadata, parsing it, and handling invalid metadata. The current implementation only creates a changeset with the event parameters without performing these described actions.
Update the comments to match the actual implementation or implement the described functionality:
/**
* Handles the ProfileMigrated event for the Registry contract from Allo protocol.
*
- * This handler performs the following steps:
- * - Fetches the metadata for the profile from the metadata provider
- * - Parses the metadata to extract the project type
- * - Returns the changeset to insert the project with the metadata
- *
- * If the metadata is not valid, it sets the metadata to null and the project type to canonical.
+ * This handler extracts the alloV1, alloV1ChainId, and alloV2 parameters from the event
+ * and creates a changeset to insert a new legacy project mapping between V1 and V2.
*/📝 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.
| /** | |
| * Handles the ProfileMigrated event for the Registry contract from Allo protocol. | |
| * | |
| * This handler performs the following steps: | |
| * - Fetches the metadata for the profile from the metadata provider | |
| * - Parses the metadata to extract the project type | |
| * - Returns the changeset to insert the project with the metadata | |
| * | |
| * If the metadata is not valid, it sets the metadata to null and the project type to canonical. | |
| */ | |
| /** | |
| * Handles the ProfileMigrated event for the Registry contract from Allo protocol. | |
| * | |
| * This handler extracts the alloV1, alloV1ChainId, and alloV2 parameters from the event | |
| * and creates a changeset to insert a new legacy project mapping between V1 and V2. | |
| */ |
scripts/hasura-config/src/utils.ts
Outdated
| * @returns The singularized word. | ||
| */ | ||
| export const singularize = (word: string): string => { | ||
| return word.endsWith("s") ? word.slice(0, -1) : word; |
There was a problem hiding this comment.
children, mice, people...will this just be used for plurals that end in s? 😄
There was a problem hiding this comment.
we won't probably have this edge cases but just in case, here's a library for the task (even has for camelizing and the other utils): https://www.npmjs.com/package/inflection
| @@ -13,7 +13,7 @@ export async function up(db: Kysely<unknown>): Promise<void> { | |||
| // Create metadata cache table | |||
| await db.schema | |||
| .createTable("metadataCache") | |||
| .addColumn("id", "text", (col) => col.notNull()) | |||
| .addColumn("id", "text") | |||
There was a problem hiding this comment.
^ how come this validation was removed?
| }; | ||
|
|
||
| export type NewLegacyProject = Insertable<LegacyProject>; | ||
| export type PartialLegacyProject = Partial<LegacyProject>; |
There was a problem hiding this comment.
it's a little confusing now that NewProject = Project but LegacyProject does not inherit from Project 🤔 and maybe PartialProject should become PartialNewProject unless it encompasses both legacy and new projects, in which case wouldn't LegacyProject inherit from Project?
There was a problem hiding this comment.
this is just a representation of Contracts migrations onchain, is not the usual backend migration that keep retrocompat between legacy and current implementation
correct me if im wrong @0xkenj1
There was a problem hiding this comment.
Yup, as nigiri said, its just the representation of the migrations of legacy projects, if you see the schema its more intuitive.
Basically, the table contains v1ProjectId and v2ProjectId.
| @@ -10,3 +10,4 @@ export * from "./strategyProcessingCheckpoint.types.js"; | |||
| export * from "./transaction.types.js"; | |||
| export * from "./metadata.types.js"; | |||
| export * from "./price.types.js"; | |||
| export * from "./legacyProject.types.js"; | |||
| NewLegacyProject, | ||
| } from "../../internal.js"; | ||
|
|
||
| export class KyselyLegacyProjectRepository implements ILegacyProjectRepository<KyselyTransaction> { |
There was a problem hiding this comment.
Its implicit i think, there is no docs for Repository classes
scripts/hasura-config/src/utils.ts
Outdated
| * @returns The singularized word. | ||
| */ | ||
| export const singularize = (word: string): string => { | ||
| return word.endsWith("s") ? word.slice(0, -1) : word; |
There was a problem hiding this comment.
we won't probably have this edge cases but just in case, here's a library for the task (even has for camelizing and the other utils): https://www.npmjs.com/package/inflection
| @@ -1,28 +1,25 @@ | |||
| import assert from "assert"; | |||
| // import assert from "assert"; | |||
There was a problem hiding this comment.
| // import assert from "assert"; |
| fkRelationships.forEach((item) => { | ||
| // Cada item.result es un array de dos elementos: | ||
| // - El primero es un array de strings (por ejemplo, ["coalesce"] o ["tables"]) | ||
| // - El segundo es un array que contiene una cadena JSON con los resultados. | ||
| const key = item.result[0][0]; | ||
| if (key === "coalesce") { | ||
| try { | ||
| const relStr: string = item.result[1][0]!; | ||
| const relData: Record<string, unknown>[] = JSON.parse(relStr) as Record< | ||
| string, | ||
| unknown | ||
| >[]; | ||
| relData.forEach((rel) => { | ||
| // Si el objeto tiene la propiedad "constraint_name", asumimos que es una relación FK | ||
| if (rel.constraint_name && rel.ref_table) { | ||
| fkRelationshipsResult.push(rel as unknown as FkRelationship); | ||
| } | ||
| }); | ||
| } catch (error) { | ||
| console.error("Error al parsear relaciones:", error); | ||
| } | ||
| } | ||
| }); |
| @@ -301,4 +311,94 @@ export class HasuraMetadataApi<Tables extends readonly string[]> { | |||
|
|
|||
| throw new HasuraApiException(errorMessage); | |||
| } | |||
| private getFetchFkRelationshipPayload(): { | |||
There was a problem hiding this comment.
we can assume from the function name but a brief explanation of the queries would be nice (even if it's from chatgpt)
| await this.createArrayRelationship(arrayRelationshipPayload); | ||
| await this.createObjectRelationship(objectRelationshipPayload); | ||
| } |
There was a problem hiding this comment.
both relationships apply at the same time?
There was a problem hiding this comment.
Yes, is a one to many(Array) and many to one relationship (Object). For each foreign key we want the relationship in both directions A->B and B->A
| @@ -26,6 +26,7 @@ const tables = [ | |||
| "applications_payouts", | |||
| "donations", | |||
| "legacy_projects", | |||
| "events_registry", | |||
There was a problem hiding this comment.
do we need to expose it in Hasura?
There was a problem hiding this comment.
yes, they asked for this :)
| }; | ||
|
|
||
| export type NewLegacyProject = Insertable<LegacyProject>; | ||
| export type PartialLegacyProject = Partial<LegacyProject>; |
There was a problem hiding this comment.
this is just a representation of Contracts migrations onchain, is not the usual backend migration that keep retrocompat between legacy and current implementation
correct me if im wrong @0xkenj1
| @@ -43,6 +43,7 @@ export type Round = { | |||
| matchingDistribution: MatchingDistribution[] | null; | |||
| projectId: string; | |||
| tags: string[]; | |||
| timestamp: Date; | |||
There was a problem hiding this comment.
do we want this as Date or we could have it as plain number? (just thinking out loud)
There was a problem hiding this comment.
I thought we were handling timestamp in this way, or iam wrong ?
There was a problem hiding this comment.
There was a problem hiding this comment.
i was just thinking out loud, maybe they wanted to filter using plain timestamp number instead of Date type but yeah they use Date every time
| * - Returns the changeset to insert the project with the metadata | ||
| * | ||
| * If the metadata is not valid, it sets the metadata to null and the project type to canonical. | ||
| */ |
| * | ||
| * @param repository - The application repository instance used for database operations | ||
| * @returns An object containing all application-related handlers | ||
| */ |
| /** | ||
| * Collection of handlers for application-related operations. | ||
| * Each handler corresponds to a specific Application changeset type. | ||
| */ |
| @@ -26,6 +26,7 @@ const tables = [ | |||
| "applications_payouts", | |||
| "donations", | |||
| "legacy_projects", | |||
| "events_registry", | |||
There was a problem hiding this comment.
yes, they asked for this :)
| await this.createArrayRelationship(arrayRelationshipPayload); | ||
| await this.createObjectRelationship(objectRelationshipPayload); | ||
| } |
There was a problem hiding this comment.
Yes, is a one to many(Array) and many to one relationship (Object). For each foreign key we want the relationship in both directions A->B and B->A
| fkRelationships.forEach((item) => { | ||
| // Cada item.result es un array de dos elementos: | ||
| // - El primero es un array de strings (por ejemplo, ["coalesce"] o ["tables"]) | ||
| // - El segundo es un array que contiene una cadena JSON con los resultados. | ||
| const key = item.result[0][0]; | ||
| if (key === "coalesce") { | ||
| try { | ||
| const relStr: string = item.result[1][0]!; | ||
| const relData: Record<string, unknown>[] = JSON.parse(relStr) as Record< | ||
| string, | ||
| unknown | ||
| >[]; | ||
| relData.forEach((rel) => { | ||
| // Si el objeto tiene la propiedad "constraint_name", asumimos que es una relación FK | ||
| if (rel.constraint_name && rel.ref_table) { | ||
| fkRelationshipsResult.push(rel as unknown as FkRelationship); | ||
| } | ||
| }); | ||
| } catch (error) { | ||
| console.error("Error al parsear relaciones:", error); | ||
| } | ||
| } | ||
| }); |
| }; | ||
|
|
||
| export type NewLegacyProject = Insertable<LegacyProject>; | ||
| export type PartialLegacyProject = Partial<LegacyProject>; |
There was a problem hiding this comment.
Yup, as nigiri said, its just the representation of the migrations of legacy projects, if you see the schema its more intuitive.
Basically, the table contains v1ProjectId and v2ProjectId.
| @@ -43,6 +43,7 @@ export type Round = { | |||
| matchingDistribution: MatchingDistribution[] | null; | |||
| projectId: string; | |||
| tags: string[]; | |||
| timestamp: Date; | |||
There was a problem hiding this comment.
I thought we were handling timestamp in this way, or iam wrong ?
| @@ -43,6 +43,7 @@ export type Round = { | |||
| matchingDistribution: MatchingDistribution[] | null; | |||
| projectId: string; | |||
| tags: string[]; | |||
| timestamp: Date; | |||
There was a problem hiding this comment.
🤖 Linear
Description
Includes:
applications,roundsandprojectstablesdonation->applicationrelationshipChecklist before requesting a review
Summary by CodeRabbit
New Features
Tests
Chores