Feature/add weekly financial report schedule #116
Conversation
…tion - Added a new function `setupWeeklyReportSchedule` in `schedules.ts` to create a weekly schedule for financial reports, running every Tuesday at 1 PM EST/EDT. - Integrated the schedule setup into the worker's `run` function in `index.ts`, ensuring it is established before the worker starts. - Enhanced error handling during schedule setup to log failures appropriately. These changes improve the automation of financial reporting, ensuring timely execution of workflows.
- Improved error handling in the `setupWeeklyReportSchedule` function by capturing and logging the error message when a schedule creation fails. - Updated log message to include the specific error encountered, aiding in debugging and monitoring. These changes enhance the visibility of issues during schedule setup, facilitating quicker resolution of potential problems.
- Removed unnecessary blank lines in the schedule configuration comments to enhance readability. - Ensured that the documentation clearly outlines the weekly financial report schedule details. These changes improve the clarity and presentation of the schedule configuration documentation.
- Updated the log message in `setupWeeklyReportSchedule` to clarify the reason for creating a new schedule when it is not found. - Enhanced the documentation in `temporal.ts` to direct users to the `scheduleConfig` object for detailed schedule configuration information. These changes improve the clarity of error messages and documentation, aiding in better understanding and maintenance of the scheduling system.
- Moved the logger instance to a new `logger.ts` file for better organization and reusability. - Updated import paths in `index.ts`, `index.test.ts`, and `schedules.ts` to reference the new logger module. - Ensured that the logger is consistently used across the application, improving maintainability and clarity. These changes streamline the logging setup and enhance code structure.
- Changed the workflowType in the setupWeeklyReportSchedule function from a direct import to a string reference for 'weeklyFinancialReportsWorkflow'. - This adjustment improves clarity and consistency in the schedule setup process. These changes enhance the maintainability of the scheduling configuration.
- Changed logger level from ERROR to INFO to capture important operational messages, including schedule setup, errors, and warnings. - Introduced validation functions to check if a schedule exists and handle "not found" errors more gracefully, improving error handling in the setupWeeklyReportSchedule function. These changes enhance logging clarity and improve the robustness of schedule management.
- Renamed `setupWeeklyReportSchedule` to `createScheduleWithRaceProtection` to better reflect its functionality. - Added logic to handle race conditions when creating schedules, allowing the function to gracefully handle cases where a schedule already exists. - Updated the `setupWeeklyReportSchedule` function to utilize the new schedule creation method, maintaining its original purpose while enhancing robustness. These changes improve the reliability of the scheduling system by preventing conflicts during schedule creation.
WalkthroughAdds weekly schedule creation during worker startup via Temporal client, centralizes a shared DefaultLogger, exports Temporal connection options, updates worker startup to create/close the client and run schedule setup, and modifies CI SonarQube configuration. Changes
Sequence Diagram(s)sequenceDiagram
participant Worker as Worker Process
participant Conn as Temporal Connection / Client
participant Server as Temporal Server
rect rgba(200,220,255,0.9)
note over Worker: Startup
Worker->>Conn: Connection.create() / Client.create()
Conn->>Server: open connection
Server-->>Conn: connected
Conn-->>Worker: client ready
end
rect rgba(220,240,220,0.9)
note over Worker: Weekly schedule setup
Worker->>Conn: setupWeeklyReportSchedule(scheduleConfig)
Conn->>Server: DescribeSchedule(scheduleId)
alt schedule exists
Server-->>Conn: Schedule description (exists)
Conn-->>Worker: log exists (no-op)
else not found
Server-->>Conn: NotFound error
Conn->>Server: CreateSchedule(scheduleConfig)
alt concurrent create / conflict
Server-->>Conn: AlreadyExists / Conflict
Conn-->>Worker: treat as success (race handled)
else create succeeded
Server-->>Conn: success
Conn-->>Worker: setup complete
end
end
end
rect rgba(240,220,220,0.9)
note over Worker: Continue startup & teardown
Worker->>Worker: create & run Temporal Worker
Worker->>Conn: close() on shutdown
end
Estimated code review effort🎯 4 (Complex) | ⏱️ ~40 minutes
Possibly related PRs
Suggested reviewers
Poem
Pre-merge checks and finishing touches❌ Failed checks (1 warning)
✅ Passed checks (2 passed)
✨ Finishing touches🧪 Generate unit tests (beta)
📜 Recent review detailsConfiguration used: Path: .coderabbit.yml Review profile: CHILL Plan: Pro 📒 Files selected for processing (1)
🚧 Files skipped from review as they are similar to previous changes (1)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (2)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
|
🤖 CodeRabbit AI Review AvailableTo request a code review from CodeRabbit AI, add CodeRabbit will analyze your code and provide feedback on:
Note: Reviews are only performed when |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (2)
workers/main/src/configs/schedules.ts (2)
11-17: Validate against specific gRPC status codes.The error code checks (code 5 for NOT_FOUND, code 6 for ALREADY_EXISTS) rely on Temporal's underlying gRPC status codes. While this approach works, consider extracting these as named constants for clarity.
+const GRPC_STATUS_NOT_FOUND = 5; +const GRPC_STATUS_ALREADY_EXISTS = 6; + function validateIsScheduleNotFoundError(error: unknown): boolean { return ( - (error as { code?: number }).code === 5 || + (error as { code?: number }).code === GRPC_STATUS_NOT_FOUND || (error instanceof Error && error.message.toLowerCase().includes('not found')) ); }
45-61: Consider usingscheduleConfigin the create call to avoid duplication.The cron expression and timezone are duplicated between
scheduleConfigand theclient.schedule.create()call. This could lead to inconsistencies if one is updated without the other.export const scheduleConfig = { scheduleId: SCHEDULE_ID, cronExpression: '0 13 * * 2', timezone: 'America/New_York', description: 'Runs every Tuesday at 1 PM EST/EDT', } as const;Then reference these values in the create call:
await client.schedule.create({ - scheduleId: SCHEDULE_ID, + scheduleId: scheduleConfig.scheduleId, spec: { - cronExpressions: ['0 13 * * 2'], - timezone: 'America/New_York', + cronExpressions: [scheduleConfig.cronExpression], + timezone: scheduleConfig.timezone, },Note: This requires moving
scheduleConfigdefinition abovecreateScheduleWithRaceProtection.Also applies to: 111-116
📜 Review details
Configuration used: Path: .coderabbit.yml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (5)
workers/main/src/configs/schedules.ts(1 hunks)workers/main/src/configs/temporal.ts(1 hunks)workers/main/src/index.test.ts(1 hunks)workers/main/src/index.ts(2 hunks)workers/main/src/logger.ts(1 hunks)
🧰 Additional context used
📓 Path-based instructions (3)
**/*.{ts,tsx}
📄 CodeRabbit inference engine (CLAUDE.md)
**/*.{ts,tsx}: Follow the function naming pattern: prefix? + action (A) + high context (HC) + low context? (LC), using action verbs such as get, fetch, send, create, validate, handle, calculate, and boolean prefixes is, has, should
Use descriptive, unabbreviated variable names; use singular for single values and plural for collections; ensure variable names are context-specific
Files:
workers/main/src/logger.tsworkers/main/src/index.test.tsworkers/main/src/configs/schedules.tsworkers/main/src/configs/temporal.tsworkers/main/src/index.ts
**/*.test.ts
📄 CodeRabbit inference engine (CLAUDE.md)
Tests are co-located with source files and should be named with the pattern *.test.ts
Files:
workers/main/src/index.test.ts
workers/main/src/configs/**
📄 CodeRabbit inference engine (CLAUDE.md)
workers/main/src/configs/**: Environment validation should be implemented in workers/main/src/configs/
Use Zod schemas for environment validation
Files:
workers/main/src/configs/schedules.tsworkers/main/src/configs/temporal.ts
🧠 Learnings (6)
📓 Common learnings
Learnt from: anatolyshipitz
Repo: speedandfunction/automatization PR: 34
File: workers/main/src/workflows/financial/FinancialReportFormatter.ts:3-7
Timestamp: 2025-05-30T17:57:21.010Z
Learning: User anatolyshipitz prefers to keep code implementations simple during early development stages rather than adding comprehensive error handling and validation. They consider extensive type annotations and error handling "redundant" when focusing on core functionality and testing.
📚 Learning: 2025-07-29T15:56:21.892Z
Learnt from: CR
Repo: speedandfunction/automatization PR: 0
File: .cursor/rules/temporal-project-structure.mdc:0-0
Timestamp: 2025-07-29T15:56:21.892Z
Learning: New workers must not duplicate logic already present in shared modules; place all shared code in 'workers-shared/' to maximize reuse and maintainability.
Applied to files:
workers/main/src/logger.ts
📚 Learning: 2025-08-05T13:42:48.295Z
Learnt from: CR
Repo: speedandfunction/automatization PR: 0
File: CLAUDE.md:0-0
Timestamp: 2025-08-05T13:42:48.295Z
Learning: Applies to workers/main/vitest.config.ts : Test configuration should be defined in workers/main/vitest.config.ts
Applied to files:
workers/main/src/index.test.ts
📚 Learning: 2025-07-29T15:56:21.892Z
Learnt from: CR
Repo: speedandfunction/automatization PR: 0
File: .cursor/rules/temporal-project-structure.mdc:0-0
Timestamp: 2025-07-29T15:56:21.892Z
Learning: Applies to workers/*/{workflows,activities,index.ts,README.md,types.ts} : All Temporal workers must be placed under 'workers/<worker-name>/' and include: 'workflows/' (workflow definitions), 'activities/' (activity implementations), 'index.ts' (worker entry point), 'types.ts' (optional), and 'README.md' (usage and development instructions).
Applied to files:
workers/main/src/configs/schedules.tsworkers/main/src/configs/temporal.tsworkers/main/src/index.ts
📚 Learning: 2025-08-05T13:42:48.295Z
Learnt from: CR
Repo: speedandfunction/automatization PR: 0
File: CLAUDE.md:0-0
Timestamp: 2025-08-05T13:42:48.295Z
Learning: Applies to workers/main/tsconfig.json : TypeScript configuration should be defined in workers/main/tsconfig.json
Applied to files:
workers/main/src/configs/schedules.tsworkers/main/src/configs/temporal.ts
📚 Learning: 2025-07-29T15:56:21.892Z
Learnt from: CR
Repo: speedandfunction/automatization PR: 0
File: .cursor/rules/temporal-project-structure.mdc:0-0
Timestamp: 2025-07-29T15:56:21.892Z
Learning: Applies to docs/user-guide/temporal/workers/*.md : Each worker must have a dedicated documentation file at 'docs/user-guide/temporal/workers/<worker-name>.md' including purpose, workflows, activities, environment variables, integration points, best practices, and troubleshooting.
Applied to files:
workers/main/src/index.ts
🧬 Code graph analysis (1)
workers/main/src/configs/schedules.ts (2)
workers/main/src/logger.ts (1)
logger(8-8)workers/main/src/configs/worker.ts (1)
workerConfig(4-6)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (2)
- GitHub Check: Docker Security Scanning (n8n, Dockerfile.n8n, n8n-test:latest)
- GitHub Check: Service Availability Check
🔇 Additional comments (7)
workers/main/src/logger.ts (1)
1-8: LGTM!Clean extraction of the logger into a dedicated module. The documentation clearly explains the purpose and log level choice.
workers/main/src/configs/temporal.ts (1)
6-28: LGTM!Good documentation additions that explain the configuration usage and point to the schedule implementation for details.
workers/main/src/configs/schedules.ts (1)
43-84: Good race-condition handling for multi-worker deployments.The combination of checking for existing schedules and handling the "already exists" error on creation properly addresses the race condition where multiple workers might try to create the schedule simultaneously.
workers/main/src/index.test.ts (1)
3-4: LGTM!Import paths correctly updated to reflect the logger module extraction.
workers/main/src/index.ts (3)
1-2: LGTM!Clean import organization separating client and worker concerns.
Also applies to: 6-6, 9-9
32-42: Verify: Worker starts even if schedule setup fails.The current error handling catches schedule setup failures and logs them but allows the worker to continue starting. This means if scheduling fails (e.g., Temporal server issues), the worker will run without the weekly report schedule being created.
If this is intentional for resilience, consider adding a comment to clarify. If schedule setup is critical, you may want to rethrow the error or add a health check mechanism.
28-57: Approve with note: dual connections are required by Temporal's API.The
run()function creates two connections: aConnectionfor the client (schedule setup) and aNativeConnectionfor the worker. While this adds some startup latency, these are distinct types in Temporal's API and cannot be shared. The implementation correctly handles both with proper cleanup infinallyblocks.
🔍 Vulnerabilities of
|
| digest | sha256:fbd989b442d9d393464e7d5767eb87d5444fc43cf8fca796d665044351839b9e |
| vulnerabilities |     |
| platform | linux/amd64 |
| size | 348 MB |
| packages | 1845 |
📦 Base Image node:22-alpine
| also known as |
|
| digest | sha256:704b199e36b5c1bc505da773f742299dc1ee5a4c70b86d1eb406c334f63253c6 |
| vulnerabilities |     |
Description
Description
Description
Description | ||||||||||||||||||||||||||||||||||||||||
Description
Description
Description
Description
Description
| ||||||||||||||||||||||||||||||||||||||||
Description
Description
Description | ||||||||||||||||||||||||||||||||||||||||
Description
Description
| ||||||||||||||||||||||||||||||||||||||||
Description
Description
| ||||||||||||||||||||||||||||||||||||||||
Description
Description
| ||||||||||||||||||||||||||||||||||||||||
Description
Description
| ||||||||||||||||||||||||||||||||||||||||
Description
| ||||||||||||||||||||||||||||||||||||||||
Description | ||||||||||||||||||||||||||||||||||||||||
Description
| ||||||||||||||||||||||||||||||||||||||||
Description | ||||||||||||||||||||||||||||||||||||||||
Description
| ||||||||||||||||||||||||||||||||||||||||
Description
| ||||||||||||||||||||||||||||||||||||||||
Description
| ||||||||||||||||||||||||||||||||||||||||
Description | ||||||||||||||||||||||||||||||||||||||||
Description
| ||||||||||||||||||||||||||||||||||||||||
Description
| ||||||||||||||||||||||||||||||||||||||||
Description
| ||||||||||||||||||||||||||||||||||||||||
Description
| ||||||||||||||||||||||||||||||||||||||||
Description
| ||||||||||||||||||||||||||||||||||||||||
Description
|
- Added arguments to the SonarQube scan action to specify the organization and enable verbose output. - Ensured that the workflow continues to utilize a full fetch depth for better analysis relevance. These changes improve the integration with SonarQube, enhancing the quality analysis process.
There was a problem hiding this comment.
Actionable comments posted: 1
📜 Review details
Configuration used: Path: .coderabbit.yml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
.github/workflows/code-quality.yml(1 hunks)
🧰 Additional context used
🧠 Learnings (1)
📓 Common learnings
Learnt from: anatolyshipitz
Repo: speedandfunction/automatization PR: 34
File: workers/main/src/workflows/financial/FinancialReportFormatter.ts:3-7
Timestamp: 2025-05-30T17:57:21.010Z
Learning: User anatolyshipitz prefers to keep code implementations simple during early development stages rather than adding comprehensive error handling and validation. They consider extensive type annotations and error handling "redundant" when focusing on core functionality and testing.
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (2)
- GitHub Check: Docker Security Scanning (n8n, Dockerfile.n8n, n8n-test:latest)
- GitHub Check: Service Availability Check
🔇 Additional comments (1)
.github/workflows/code-quality.yml (1)
29-29: Comment formatting cleanup LGTM.The fetch-depth comment has been reformatted with no functional changes to the shallow clone behavior.
…y workflow - Changed the argument syntax in the SonarQube scan action from colon to equals for better compatibility and clarity. - This update ensures a more standardized configuration format, enhancing the overall integration with SonarQube.
- Changed the organization key from 'speedandfunction' to 'automatization-bot' to reflect the new organizational structure. This update ensures accurate project association within SonarQube, improving the integration and analysis process.
- Introduced a conditional statement to the SonarQube job to skip execution when the SONAR_DISABLE_CI variable is set to 'true'. - This enhancement allows for more flexible control over the CI process, improving workflow efficiency. These changes optimize the code quality workflow by providing better management of SonarQube execution based on configuration settings.
|
anatolyshipitz
deleted the
feature/add-weekly-financial-report-schedule
branch
New Features
Summary by CodeRabbit
New Features
Refactor
Chores
✏️ Tip: You can customize this high-level summary in your review settings.