fix: avoid premature execution before sdk initialization #2056
Conversation
📝 WalkthroughWalkthroughThis PR updates how the SDK and its associated components are initialized and configured. It replaces hardcoded initialization parameters with placeholders in the example, adds an Changes
Sequence Diagram(s)sequenceDiagram
participant RA as RudderAnalytics
participant EH as ErrorHandler
participant CS as CookieStorage
participant LS as LocalStorage
participant SS as SessionStorage
participant IMS as InMemoryStorage
RA->>RA: initializeGlobalResources()
RA->>EH: init()
Note over EH: Attaches error listeners
RA->>CS: configure?()
RA->>LS: configure?()
RA->>SS: configure?()
RA->>IMS: configure?()
Possibly related PRs
Suggested reviewers
📜 Recent review detailsConfiguration used: CodeRabbit UI ⛔ Files ignored due to path filters (1)
📒 Files selected for processing (21)
🚧 Files skipped from review as they are similar to previous changes (20)
⏰ Context from checks skipped due to timeout of 90000ms (3)
🔇 Additional comments (5)
✨ 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 (
|
saikumarrs
changed the title
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## develop #2056 +/- ##
===========================================
+ Coverage 61.42% 61.44% +0.02%
===========================================
Files 478 478
Lines 16407 16411 +4
Branches 3231 3259 +28
===========================================
+ Hits 10078 10084 +6
+ Misses 5140 5076 -64
- Partials 1189 1251 +62 ☔ View full report in Codecov by Sentry. |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (7)
packages/analytics-js/src/services/ErrorHandler/ErrorHandler.ts (1)
43-45: Add JSDoc documentation and prevent multiple initialization.The
init()method lacks documentation and doesn't protect against multiple initialization calls.Consider applying these improvements:
+ private initialized = false; + + /** + * Initializes the error handler by attaching global error listeners. + * This method should be called once after construction. + */ init() { + if (this.initialized) { + this.logger.warn('ErrorHandler already initialized'); + return; + } this.attachErrorListeners(); + this.initialized = true; }packages/analytics-js/__tests__/services/ErrorHandler/ErrorHandler.test.ts (1)
13-13: Add test cases for init() method behavior.While the initialization is correctly added to
beforeEach, specific test cases for theinit()method are missing.Consider adding these test cases:
describe('init', () => { it('should attach error listeners only once', () => { const attachListenersSpy = jest.spyOn(errorHandlerInstance, 'attachErrorListeners'); // Second init() call should not attach listeners again errorHandlerInstance.init(); expect(attachListenersSpy).not.toHaveBeenCalled(); attachListenersSpy.mockRestore(); }); });packages/analytics-js/__tests__/services/StoreManager/storages/LocalStorage.test.ts (1)
9-9: LGTM! Consider adding error handling.The addition of
engine.configure?.()ensures proper initialization before usage, aligning with the PR's goal of fixing premature initialization. The optional chaining operator prevents runtime errors.Consider adding error handling to catch and log configuration failures:
- engine.configure?.(); + try { + engine.configure?.(); + } catch (error) { + console.error('Failed to configure localStorage engine:', error); + }packages/analytics-js/__tests__/services/StoreManager/storages/CookieStorage.test.ts (1)
12-12: LGTM! Consider additional cookie configuration tests.The addition of
engine.configure?.()maintains consistent initialization pattern. The existing domain configuration test is valuable for security.Consider adding tests for other cookie configuration options:
it('should properly configure cookie attributes', () => { configureCookieStorageEngine({ samesite: 'Strict', secure: true, path: '/app', maxage: 3600000, }); const newEngine = getStorageEngine('cookieStorage'); expect(newEngine.options.samesite).toBe('Strict'); expect(newEngine.options.secure).toBe(true); expect(newEngine.options.path).toBe('/app'); expect(newEngine.options.maxage).toBe(3600000); });packages/analytics-js/__tests__/services/StoreManager/storages/sessionStorage.test.ts (1)
9-9: LGTM! Consider testing configuration with unavailable storage.The addition of
engine.configure?.()maintains consistent initialization pattern. The tests for unavailable storage are thorough.Consider adding a test to verify configuration behavior when storage is unavailable:
it('should handle configuration when session storage is unavailable', () => { const sessionStorageEngine = getStorageEngine('sessionStorage'); sessionStorageEngine.store = undefined; // Should not throw error when configuring unavailable storage expect(() => sessionStorageEngine.configure?.()).not.toThrow(); });packages/analytics-js/src/services/StoreManager/storages/LocalStorage.ts (1)
12-15: Address TODO comment about storejs dependency.The TODO comment indicates potential bundle size improvements by removing the storejs dependency. Since you're modifying the storage implementation, this would be a good time to evaluate this optimization.
Would you like me to help analyze the usage of storejs methods and propose an alternative implementation that could reduce the bundle size?
packages/analytics-js/__tests__/services/StoreManager/StoreManager.test.ts (1)
69-71: Consider documenting default storage behavior.The shift from explicit to implicit storage configuration makes the code cleaner but less transparent. Consider:
- Adding JSDoc comments to document the default behavior of each storage type
- Creating a configuration guide in the README
- Adding debug logs when falling back to default configurations
Also applies to: 81-83
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (1)
.github/workflows/draft-new-release.ymlis excluded by!**/*.yml
📒 Files selected for processing (21)
examples/v3/index.html(1 hunks)packages/analytics-js-common/__mocks__/ErrorHandler.ts(1 hunks)packages/analytics-js-common/__mocks__/Store.ts(1 hunks)packages/analytics-js-common/src/types/ErrorHandler.ts(1 hunks)packages/analytics-js-common/src/types/Store.ts(1 hunks)packages/analytics-js/__tests__/services/ErrorHandler/ErrorHandler.test.ts(1 hunks)packages/analytics-js/__tests__/services/StoreManager/StoreManager.test.ts(1 hunks)packages/analytics-js/__tests__/services/StoreManager/storages/CookieStorage.test.ts(1 hunks)packages/analytics-js/__tests__/services/StoreManager/storages/InMemoryStorage.test.ts(1 hunks)packages/analytics-js/__tests__/services/StoreManager/storages/LocalStorage.test.ts(1 hunks)packages/analytics-js/__tests__/services/StoreManager/storages/defaultOptions.test.ts(1 hunks)packages/analytics-js/__tests__/services/StoreManager/storages/sessionStorage.test.ts(1 hunks)packages/analytics-js/src/app/RudderAnalytics.ts(3 hunks)packages/analytics-js/src/services/ErrorHandler/ErrorHandler.ts(1 hunks)packages/analytics-js/src/services/StoreManager/Store.ts(1 hunks)packages/analytics-js/src/services/StoreManager/StoreManager.ts(1 hunks)packages/analytics-js/src/services/StoreManager/storages/CookieStorage.ts(2 hunks)packages/analytics-js/src/services/StoreManager/storages/InMemoryStorage.ts(2 hunks)packages/analytics-js/src/services/StoreManager/storages/LocalStorage.ts(2 hunks)packages/analytics-js/src/services/StoreManager/storages/sessionStorage.ts(2 hunks)packages/analytics-js/src/services/StoreManager/storages/storageEngine.ts(3 hunks)
✅ Files skipped from review due to trivial changes (1)
- packages/analytics-js/tests/services/StoreManager/storages/defaultOptions.test.ts
🧰 Additional context used
🧠 Learnings (1)
packages/analytics-js-common/src/types/ErrorHandler.ts (1)
Learnt from: saikumarrs
PR: rudderlabs/rudder-sdk-js#1907
File: packages/analytics-js/src/services/ErrorHandler/ErrorHandler.ts:172-174
Timestamp: 2024-11-12T15:14:23.319Z
Learning: The function `onError` in `packages/analytics-js/src/services/ErrorHandler/ErrorHandler.ts` is acceptable as currently implemented, and refactoring suggestions are not required unless necessary.
⏰ Context from checks skipped due to timeout of 90000ms (3)
- GitHub Check: Bundle size checks
- GitHub Check: Unit Tests and Lint
- GitHub Check: Security and code quality checks
🔇 Additional comments (24)
packages/analytics-js-common/__mocks__/ErrorHandler.ts (1)
9-9: LGTM! Mock implementation matches interface changes.The mock implementation correctly adds the
initmethod as a Jest mock function, maintaining consistency with the interface changes.packages/analytics-js-common/src/types/ErrorHandler.ts (1)
10-10: LGTM! Interface change improves initialization control.The addition of
init(): voidto the interface makes the initialization step explicit, following the principle of separation of concerns.packages/analytics-js/src/app/RudderAnalytics.ts (3)
40-44: LGTM! Imports added for global resources.The imports are correctly added for the error handler and storage engines that need to be initialized globally.
114-123: LGTM! Well-structured initialization of global resources.The
initializeGlobalResourcesmethod follows a good initialization pattern:
- Initializes error handler first to catch any initialization errors
- Configures storage engines with default options
73-73: LGTM! Global resources initialized at the right time.The
initializeGlobalResourcesis called early in the constructor, ensuring all global resources are ready before any SDK operations.examples/v3/index.html (1)
99-99: LGTM! Using placeholders in example code.Replacing hardcoded values with placeholders (
__WRITE_KEY__and__DATAPLANE_URL__) is a good practice in example code as it:
- Makes the example more generic
- Prevents accidental exposure of actual credentials
packages/analytics-js/__tests__/services/StoreManager/storages/InMemoryStorage.test.ts (1)
9-9: LGTM! Consistent with other storage implementations.The addition of
engine.configure?.()maintains a consistent initialization pattern across different storage types.packages/analytics-js/src/services/StoreManager/storages/InMemoryStorage.ts (3)
21-24: LGTM! Constructor simplified to prevent premature initialization.The removal of options from the constructor aligns with the PR's objective of avoiding premature initialization. The logger-only constructor is a cleaner approach.
26-28: LGTM! Configure method made more flexible.The optional options parameter with nullish coalescing operator provides a safe default while maintaining backward compatibility.
68-68: LGTM! Default instance creation updated.The simplified constructor usage for default instance aligns with the new initialization pattern.
packages/analytics-js-common/src/types/Store.ts (1)
56-56:❓ Verification inconclusive
Verify impact of optional configure method.
Making
configureoptional in theIStorageinterface is a breaking change that could affect existing code expecting this method to be present.
🏁 Script executed:
#!/bin/bash # Search for direct calls to configure method rg -A 2 '\.configure\(' --type tsLength of output: 184
Action Required: Verify Impact of Optional
configureMethod inIStorageInterfaceThe change making the
configuremethod optional is potentially breaking since existing implementations might expect this method to be defined. The initial search for direct calls toconfiguredid not yield results due to filtering issues. Please manually verify or run an updated script (see below) to ensure no parts of the codebase rely on a guaranteed implementation ofconfigure:
Re-run the search without filtering by file type to verify all potential usages:
# Re-run the search command without restricting to TypeScript files rg --debug -A 2 '\.configure\('If any direct calls to
configureare found, adjust them to safely handle its potential absence.packages/analytics-js-common/__mocks__/Store.ts (1)
16-16: LGTM! Removed implicit engine fallback.Direct assignment of the engine parameter without fallback aligns with the PR's objective of avoiding premature initialization.
packages/analytics-js/src/services/StoreManager/storages/LocalStorage.ts (3)
26-29: LGTM! Constructor simplified to prevent premature initialization.The removal of options from the constructor aligns with the PR's objective of avoiding premature initialization.
31-33: LGTM! Configure method made more flexible.The optional options parameter with nullish coalescing operator provides a safe default while maintaining backward compatibility.
70-70: LGTM! Default instance creation updated.The simplified constructor usage for default instance aligns with the new initialization pattern.
packages/analytics-js/src/services/StoreManager/storages/sessionStorage.ts (3)
25-28: LGTM! Constructor refactored to prevent premature initialization.The removal of options from the constructor and initialization of options with defaults aligns with the PR's objective of avoiding premature initialization.
30-32: LGTM! Improved options handling in configure method.The use of optional parameter with nullish coalescing operator (
??) is a good practice for handling undefined options.
90-90: LGTM! Simplified default storage instance creation.The simplified instantiation with just the logger parameter aligns with the changes in the constructor.
packages/analytics-js/src/services/StoreManager/storages/CookieStorage.ts (3)
17-17: LGTM! Constructor refactored consistently with other storage classes.The changes maintain consistency with other storage implementations while preventing premature initialization.
Also applies to: 22-25
27-35: LGTM! Improved options handling with domain cleanup.The configure method properly handles optional parameters and includes domain cleanup when sameDomainCookiesOnly is true.
74-76: LGTM! Added defaultCookieStorage export.The addition of defaultCookieStorage aligns with the pattern used in other storage implementations.
packages/analytics-js/src/services/StoreManager/storages/storageEngine.ts (1)
43-44: LGTM! Simplified cookie storage configuration.The change to use defaultCookieStorage.configure maintains consistency with other storage engines while reducing initialization complexity.
packages/analytics-js/src/services/StoreManager/StoreManager.ts (1)
69-71:❓ Verification inconclusive
Verify storage engine initialization behavior.
The removal of explicit storage options could affect how storage engines are initialized. Ensure that the storage engines have appropriate default behaviors when initialized with empty options.
🏁 Script executed:
#!/bin/bash # Description: Check storage engine initialization behavior # Search for default configurations in storage engine implementations # Look for default configurations in storage implementations ast-grep --pattern 'class $_ { constructor($_) { $$$ } }' # Search for any fallback configurations rg -A 5 "default.*config|fallback.*config"Length of output: 112
Attention: Verify Default Initialization in Storage Engines
The removal of explicit storage options (i.e. passing empty objects for local, in-memory, and session storages) means we must ensure that each storage engine correctly falls back to default settings during initialization. Our automated check didn't locate any obvious fallback logic in the constructors. Please manually verify that each storage engine (likely implemented in files under
packages/analytics-js/src/services/StoreManager/) properly assigns and handles default configurations when initialized with empty options.
- Confirm in each storage engine’s constructor (e.g., for LocalStorageEngine, InMemoryStorageEngine, and SessionStorageEngine) that if options are empty, the engine sets or infers the correct defaults.
- Ensure that removing the explicit configurations does not lead to unintended behavior.
packages/analytics-js/__tests__/services/StoreManager/StoreManager.test.ts (1)
81-83: LGTM! Test expectations updated to match implementation.The test has been correctly updated to verify the new storage engine configuration behavior with empty objects.
saikumarrs
changed the title
saikumarrs
changed the title
size-limit report 📦
|
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (2)
packages/analytics-js/src/services/ErrorHandler/ErrorHandler.ts (2)
44-55: Consider adding explicit access modifier and handling concurrent initialization.The
init()method implementation looks good, but consider these improvements:
- Add explicit
publicmodifier for better clarity- Consider using a synchronization mechanism to handle concurrent initialization calls safely
- init() { + public init() { if (this.initialized) { return; } + // Consider using a more robust synchronization mechanism + // if concurrent initialization is possible this.attachErrorListeners(); this.initialized = true; }
157-157: Add documentation for initialization requirement.The
defaultErrorHandlerinstance is created but not initialized. Consider adding a comment to document thatinit()must be called before use.+// Note: Remember to call defaultErrorHandler.init() before use const defaultErrorHandler = new ErrorHandler(defaultHttpClient, defaultLogger);
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (2)
packages/analytics-js/__tests__/services/StoreManager/storages/CookieStorage.test.ts(3 hunks)packages/analytics-js/src/services/ErrorHandler/ErrorHandler.ts(2 hunks)
🚧 Files skipped from review as they are similar to previous changes (1)
- packages/analytics-js/tests/services/StoreManager/storages/CookieStorage.test.ts
⏰ Context from checks skipped due to timeout of 90000ms (3)
- GitHub Check: Bundle size checks
- GitHub Check: Unit Tests and Lint
- GitHub Check: Security and code quality checks
🔇 Additional comments (4)
packages/analytics-js/src/services/ErrorHandler/ErrorHandler.ts (4)
36-36: LGTM! Good use of private flag for initialization control.The private
initializedflag is a good addition to prevent multiple initializations of the error handler.
39-42: LGTM! Good separation of construction and initialization.Moving initialization out of the constructor aligns with the PR's objective of avoiding premature execution and follows good practices for better initialization control.
44-48: LGTM! Clear and comprehensive documentation.The added JSDoc comments provide clear explanations of method purposes and usage, which improves code maintainability.
Also applies to: 57-59, 73-79
33-159:❓ Verification inconclusive
Verify the initialization sequence in the SDK.
The changes look good and align with the PR objective of avoiding premature execution. Let's verify the initialization sequence:
🏁 Script executed:
#!/bin/bash # Search for init() calls to ensure proper initialization sequence rg -A 5 "defaultErrorHandler.init\(\)" --type tsLength of output: 199
Let's re-run the search without the file type filter to ensure we capture any initialization calls for the default error handler. This should give us a more complete picture of where and how
defaultErrorHandler.init()is invoked.Once this script runs, please share its output or verify the results manually so we can confidently assess the initialization sequence in the SDK.
🏁 Script executed:
#!/bin/bash # Search for defaultErrorHandler.init() call across the repository without type filtering rg -A 5 "defaultErrorHandler\.init\(" .Length of output: 41
Ensure SDK initialization is correctly triggered.
The implementation in
ErrorHandler.tsaligns with the PR objective to avoid premature execution by deferring the error handler initialization. However, our repository search did not find any calls todefaultErrorHandler.init(). This likely means that initialization is expected to be triggered manually by the consuming application. Please verify that this initialization strategy is intentional and that the application documentation or bootstrap logic explicitly includes a call toinit()when appropriate.
saikumarrs
force-pushed
the
fix.avoid-pre-mature-initialization-sdk-3003
branch
from
1810a87 to
762eaeb
Compare
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (2)
packages/analytics-js/src/services/ErrorHandler/ErrorHandler.ts (2)
48-55: Add dependency validation in init method.While the initialization control is well-implemented, consider validating the required dependencies (
httpClientandlogger) to prevent potential runtime errors.public init() { if (this.initialized) { return; } + if (!this.httpClient || !this.logger) { + throw new Error('ErrorHandler dependencies not properly initialized'); + } + this.attachErrorListeners(); this.initialized = true; }
157-158: Consider enforcing initialization at type level.While the note is helpful, consider enforcing initialization through TypeScript to catch usage errors at compile time rather than runtime.
Here's a pattern you could use:
class ErrorHandler implements IErrorHandler { private constructor(httpClient: IHttpClient, logger: ILogger) { // ... existing constructor code } public static create(httpClient: IHttpClient, logger: ILogger): ErrorHandler { const handler = new ErrorHandler(httpClient, logger); handler.init(); return handler; } } // Usage const defaultErrorHandler = ErrorHandler.create(defaultHttpClient, defaultLogger);This pattern ensures that the error handler is always initialized at creation time.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (21)
examples/v3/index.html(1 hunks)packages/analytics-js-common/__mocks__/ErrorHandler.ts(1 hunks)packages/analytics-js-common/__mocks__/Store.ts(1 hunks)packages/analytics-js-common/src/types/ErrorHandler.ts(1 hunks)packages/analytics-js-common/src/types/Store.ts(1 hunks)packages/analytics-js/__tests__/services/ErrorHandler/ErrorHandler.test.ts(1 hunks)packages/analytics-js/__tests__/services/StoreManager/StoreManager.test.ts(1 hunks)packages/analytics-js/__tests__/services/StoreManager/storages/CookieStorage.test.ts(3 hunks)packages/analytics-js/__tests__/services/StoreManager/storages/InMemoryStorage.test.ts(1 hunks)packages/analytics-js/__tests__/services/StoreManager/storages/LocalStorage.test.ts(1 hunks)packages/analytics-js/__tests__/services/StoreManager/storages/defaultOptions.test.ts(1 hunks)packages/analytics-js/__tests__/services/StoreManager/storages/sessionStorage.test.ts(1 hunks)packages/analytics-js/src/app/RudderAnalytics.ts(3 hunks)packages/analytics-js/src/services/ErrorHandler/ErrorHandler.ts(3 hunks)packages/analytics-js/src/services/StoreManager/Store.ts(2 hunks)packages/analytics-js/src/services/StoreManager/StoreManager.ts(1 hunks)packages/analytics-js/src/services/StoreManager/storages/CookieStorage.ts(2 hunks)packages/analytics-js/src/services/StoreManager/storages/InMemoryStorage.ts(2 hunks)packages/analytics-js/src/services/StoreManager/storages/LocalStorage.ts(2 hunks)packages/analytics-js/src/services/StoreManager/storages/sessionStorage.ts(2 hunks)packages/analytics-js/src/services/StoreManager/storages/storageEngine.ts(3 hunks)
🚧 Files skipped from review as they are similar to previous changes (20)
- packages/analytics-js/tests/services/StoreManager/storages/defaultOptions.test.ts
- packages/analytics-js/tests/services/StoreManager/storages/sessionStorage.test.ts
- packages/analytics-js-common/mocks/ErrorHandler.ts
- packages/analytics-js/tests/services/ErrorHandler/ErrorHandler.test.ts
- packages/analytics-js/tests/services/StoreManager/storages/InMemoryStorage.test.ts
- packages/analytics-js/src/services/StoreManager/Store.ts
- packages/analytics-js-common/mocks/Store.ts
- packages/analytics-js-common/src/types/ErrorHandler.ts
- packages/analytics-js-common/src/types/Store.ts
- packages/analytics-js/src/services/StoreManager/storages/storageEngine.ts
- examples/v3/index.html
- packages/analytics-js/src/services/StoreManager/StoreManager.ts
- packages/analytics-js/tests/services/StoreManager/storages/CookieStorage.test.ts
- packages/analytics-js/src/app/RudderAnalytics.ts
- packages/analytics-js/tests/services/StoreManager/StoreManager.test.ts
- packages/analytics-js/src/services/StoreManager/storages/InMemoryStorage.ts
- packages/analytics-js/src/services/StoreManager/storages/sessionStorage.ts
- packages/analytics-js/src/services/StoreManager/storages/CookieStorage.ts
- packages/analytics-js/src/services/StoreManager/storages/LocalStorage.ts
- packages/analytics-js/tests/services/StoreManager/storages/LocalStorage.test.ts
⏰ Context from checks skipped due to timeout of 90000ms (3)
- GitHub Check: Bundle size checks
- GitHub Check: Security and code quality checks
- GitHub Check: Unit Tests and Lint
🔇 Additional comments (2)
packages/analytics-js/src/services/ErrorHandler/ErrorHandler.ts (2)
36-36: LGTM! Good use of private flag for initialization control.The private
initializedflag is well-designed to prevent multiple initializations.
44-47: LGTM! Well-documented methods.The JSDoc comments are clear, comprehensive, and follow best practices.
Also applies to: 57-59, 73-79
saikumarrs
force-pushed
the
fix.avoid-pre-mature-initialization-sdk-3003
branch
from
762eaeb to
8a5db91
Compare
|
PR Description
I've fixed a couple of issues in the core module that would otherwise execute some logic before the SDK initialisation.
We create default instances of some resources so we should be careful in executing some code in their constructors. Otherwise, some code can get executed just by importing the package.
All the storage engine modules are refactored to create default instances which will be configured only when the SDK instance is created.
The default instances will be used throughout the code.
Now, there is no need for global singletons.
Linear task (optional)
https://linear.app/rudderstack/issue/SDK-3003/avoid-attaching-error-listeners-by-default
Cross Browser Tests
Please confirm you have tested for the following browsers:
Sanity Suite
Security
Summary by CodeRabbit
Summary by CodeRabbit
New Features
Refactor
ErrorHandlerclass with a new initialization method for improved setup.