bulltrackers-module 1.0.53 → 1.0.54

package/README.MD

@@ -1,153 +1,227 @@
-# BullTrackers Module (`bulltrackers-module`)
 
-**Version:** 1.0.27
+-----
 
-## Overview
-
-This package encapsulates the core logic and shared utilities for the BullTrackers cloud function architecture. It promotes code reuse and separation of concerns by providing abstracted handlers and helper functions for various backend services.
+# bulltrackers-module
 
-## Core Concepts
+**Version:** 1.0.53
 
-* **eToro User IDs (CIDs):** Sequential integers assigned upon registration.
-
-eToro assigns a hidden UID to each users' account in order for their backend configurations to identify users without needing to reference a username.
-This is a common fact across most modern sites, but eToro is slightly unique in that their UIDs are not randomised, they are sequential.
-This means that UID 1 is the first account ever made, and UID 1 million is the 1 millionth account made.
+## Overview
 
-* **Block Sampling:** Randomly sampling users within 1M ID blocks to ensure representative data across different registration cohorts.
+This package encapsulates the core backend logic for the BullTrackers platform. It is designed as a modular, stateless library to be used within a Google Cloud Functions environment.
 
-Given how the UIDs are assigned on eToro, we can group users by their UID into 1m block ranges, and then from this we can sample users randomly to produce data across each Block.
-Now there is a slight caveat to the current implementation, where our current implementation is designed to fill up a set capacity of users, per user type, per block range. 
-This is statistically biased, because there will be more public users in certain blocks than other blocks.
-The future resolution to this, is to weight the block capacity by that blocks' ratio of public to private users, ensuring representative sampling.
-For now, this is not implemented.
+It promotes a clean, testable, and maintainable architecture by enforcing a clear separation of concerns and using a consistent dependency injection pattern. All business logic is exposed via a single, nested `pipe` object.
 
-* **User Types:** Differentiating between 'normal' users and 'speculators' based on portfolio activity and specific asset holdings.
+## Core Concepts
 
-This system attempts to categorise user portfolios, and the users themselves, by types and (in the future, sub types).
-These are based on the response of the rankings API call, which returns enough detail to figure out whether a user is speculative, normal, inactive or private.
-In the future the plan is to create sub categories that state the users' risk group alongside their main category.
-Private is not a category, it is rather the lack of a category. Users who are private, are implicitely removed from the response of the API, auto-filtering for the system.
-Inactive users are a future implementation of a user type, to allow us to track users who have not logged into the platformm recently but hold positions.
+  * **eToro User IDs (CIDs):** Sequential integers assigned upon registration. This sequential nature allows for "Block Sampling".
+  * **Block Sampling:** The process of randomly sampling users within 1 million ID blocks (e.g., 1M-2M, 2M-3M) to ensure a representative dataset across different user registration cohorts.
+  * **User Types:** The system differentiates between two primary user types:
+      * **`normal`**: Standard users.
+      * **`speculator`**: Users identified by specific portfolio activities, such as holding certain high-risk assets.
+  * **Dependency Injection (DI):** No function in this module initializes its own clients (like Firestore or Pub/Sub) or accesses global configuration. All logic is exposed as stateless functions that receive two arguments: `(config, dependencies)`. This makes the entire module testable and portable.
 
-* **Data Flow:** An architecture primarily using Google Cloud Pub/Sub and Cloud Functions.
+## Architecture: The `pipe` Object
 
-The flow of data is, in part, event-driven, and in part scheduler driven.
-The system begins by searching for users to fill up the capacity of the block counts for normal and speculator users. This is the discovery process.
-These users are then verified, and if they meet the criteria of a normal or speculator user, then their UID is stored.
-The update task triggers once a day and finds all the users it needs to update the data of, this will include those users the discovery process located and then verified.
-The update task will look at their portfolios, store the contents. 
+This module exports a single root object named `pipe`. This object organizes all application logic into distinct, self-contained "pipelines," each corresponding to a major microservice or domain.
 
-The submitting of the task type and UIDs is done by the Orchestrators, either the update or discovery orchestrator.
-In discovery mode, the tasks are submitted directly to the task engine through a pub/sub
-In update mode, the tasks are passed to the dispatcher, to then slowly release to the task engine, an intentional choice to ensure the task engine can scale gradually to handle the incoming requests.
-The task engine is event-driven, triggered by pub/sub messages.
-The portfolio data is then stored, and once a day the computation system is run on a cron schedule trigger, fetches all the portfolio data and applies computations to the data, returning results that are stored.
-The API is then able to read these results.
+```javascript
+// Example of the module's structure
+const { pipe } = require('bulltrackers-module');
+
+// You initialize dependencies ONCE in your main function entry point
+const dependencies = {
+    db: new Firestore(),
+    pubsub: new PubSub(),
+    logger: myLogger,
+    headerManager: new pipe.core.IntelligentHeaderManager(...),
+    proxyManager: new pipe.core.IntelligentProxyManager(...),
+    // ...etc.
+};
+
+// You then pass those dependencies into any pipe function
+async function runDiscovery(config) {
+    await pipe.orchestrator.runDiscoveryOrchestrator(config, dependencies);
+}
+```
+
+-----
 
 ## Module Structure
 
-The module is organized by function, mirroring the cloud function deployment structure.
+### `pipe.core`
 
-### `/core`
+Contains the fundamental, reusable classes and utilities that power the other pipes.
 
-Contains utilities shared across multiple functions within the module.
+  * **`IntelligentHeaderManager`**: A class that manages a pool of browser headers, rotating them based on historical success rates to avoid API blocks. Performance is tracked in Firestore.
+  * **`IntelligentProxyManager`**: A class that manages a pool of Google Apps Script proxy URLs. It selects available proxies, handles request fetching, and locks proxies that fail (e.g., due to quota errors).
+  * **`FirestoreBatchManager`**: A utility class used by the Task Engine to manage stateful, asynchronous batch writes to Firestore. It handles sharding portfolio data, batching timestamp updates, and flushing processed speculator IDs.
+  * **`firestoreUtils`**: A collection of stateless helper functions for common Firestore operations, such as resetting proxy locks, getting block capacities, fetching exclusion IDs, and querying users who need updates.
+  * **`pubsubUtils`**: A collection of stateless helper functions for publishing messages to Pub/Sub in batches.
 
-* **`/utils`:**
-    * `firestore_utils.js`: Helpers for common Firestore operations (batching, querying blocks, resetting proxies, getting IDs).
-    * `pubsub_utils.js`: Helpers for publishing messages to Pub/Sub topics in batches.
-    * `intelligent_header_manager.js`: Manages a pool of browser headers, selecting them based on past success rates to mimic real user traffic. Stores performance data in Firestore.
-    * `intelligent_proxy_manager.js`: Manages a pool of Google Apps Script proxies, selecting available ones and handling failures/locking.
+### `pipe.orchestrator`
 
-### `/orchestrator`
+The "brain" of the system. This pipe is responsible for deciding *what* work needs to be done, but not *how* to do it. It's typically run on a schedule (e.g., via Cloud Scheduler).
 
-Handles the triggering and coordination of data fetching tasks (Discovery and Update).
+  * **`runDiscoveryOrchestrator(config, dependencies)`**: The main entry point for the discovery process. It checks which user blocks are under-capacity, gets candidate CIDs to scan, and dispatches `discover` tasks.
+  * **`runUpdateOrchestrator(config, dependencies)`**: The main entry point for the daily update process. It queries Firestore for all verified users who haven't been updated recently and dispatches `update` tasks.
+  * **Discovery Helpers** (`checkDiscoveryNeed`, `getDiscoveryCandidates`, `dispatchDiscovery`): Sub-pipes that handle the logic for finding underpopulated blocks, generating new CIDs (while respecting exclusion lists), and publishing discovery tasks.
+  * **Update Helpers** (`getUpdateTargets`, `dispatchUpdates`): Sub-pipes that find all `normal` and `speculator` users eligible for an update and publish tasks to the `Dispatcher`.
 
-* **`index.js`:** Exports factory functions (`createDiscoveryOrchestrator`, `createUpdateOrchestrator`).
-* **`/helpers`:**
-    * `discovery_helpers.js`: Logic for checking if discovery is needed, finding candidate users (prioritizing known users, then random generation with exclusions), managing pending lists, and dispatching tasks.
-    * `update_helpers.js`: Logic for identifying users needing updates based on timestamps and dispatching update tasks.
+### `pipe.dispatcher`
 
-### `/dispatcher`
+The "throttle" of the system. Its sole purpose is to receive a large number of tasks (typically from the `orchestrator`) and slowly release them in small batches to a Pub/Sub topic. This prevents the `taskEngine` from scaling too quickly and incurring high costs.
 
-Acts as an intermediary buffer, receiving tasks from the Orchestrator and slowly releasing them to the Task Engine to prevent overwhelming it.
+  * **`handleRequest(message, context, config, dependencies)`**: The main entry point, designed to be triggered by a Pub/Sub message containing an array of `tasks`.
+  * **`dispatchTasksInBatches(tasks, dependencies, config)`**: The core logic that loops through tasks, publishing them in batches with a configurable delay.
 
-* **`index.js`:** Exports the factory function `createDispatcherHandler`.
-* **`/helpers/dispatch_helpers.js`:** Contains the core logic for batching and delaying task publishing.
+### `pipe.taskEngine`
 
-### `/task-engine`
+The "factory" or "workhorse" of the system. This pipe is event-driven, triggered by individual Pub/Sub messages from the `orchestrator` or `dispatcher`. It executes the core data-fetching operations.
 
-The core processing unit. Receives tasks (discover, verify, update) for different user types (normal, speculator) and executes the corresponding logic using eToro APIs via the proxy manager.
+  * **`handleRequest(message, context, config, dependencies)`**: The main entry point. It parses the Pub/Sub message, identifies the task `type`, and routes it to the correct sub-pipe handler.
+  * **`handleDiscover(task, taskId, dependencies, config)`**: Fetches public ranking data for a batch of CIDs. It filters out private/inactive users, applies heuristics (for speculators), and chains to the `verify` task for any promising candidates.
+  * **`handleVerify(task, taskId, dependencies, config)`**: Fetches the portfolio of a *single* user. It verifies they meet the criteria (e.g., holds a speculator asset) and, if so, saves their data and increments the block count.
+  * **`handleUpdate(task, taskId, dependencies, config)`**: Fetches the latest portfolio for an *existing, verified* user and stores the new data in a sharded Firestore document.
 
-* **`index.js`:** Exports the factory function `createTaskEngineHandler`.
-* **`handler_creator.js`:** Sets up the handler, initializes clients (Firestore, PubSub, managers), and defines the main processing flow.
-* **`/helpers`:**
-    * `discover_helpers.js`: Handles fetching user ranking/activity data, filtering private/inactive users, applying heuristics (especially for speculators), and chaining to the 'verify' task. Also handles logging invalid speculator IDs.
-    * `verify_helpers.js`: Handles fetching portfolio details, checking for specific assets (for speculators) or any positions (for normal users), storing bronze state, updating block counts, and storing verified users.
-    * `update_helpers.js`: Handles fetching the latest portfolio or position data for already verified users, handling private users, and storing the updated data.
-* **`/utils`:**
-    * `firestore_batch_manager.js`: Manages batch writes to Firestore for portfolios (sharded), timestamps, and removing processed speculators from the pending list.
----
+### `pipe.computationSystem`
 
-### `/computation-system`
+The "refinery" of the system. This pipe is run on a schedule *after* data collection. It loads all the raw portfolio data, runs a suite of calculations (e.g., risk scores, profit migrations), and saves the results in a separate "unified insights" collection for the API to read.
 
-Handles the orchestration and execution of the **unified computation system**. This system runs scheduled calculations (both daily and historical comparisons) using calculation logic imported from the `aiden-shared-calculations-unified` package. It identifies date ranges needing processing or backfilling, loads the necessary portfolio data, runs the calculations, and stores the results.
+  * **`runOrchestration(config, dependencies)`**: The main entry point. It identifies which dates need processing (or backfilling), loads all data for those dates, initializes all calculation classes, and streams the data through them.
+  * **`dataLoader`**: A set of helpers for loading the sharded portfolio data from Firestore efficiently.
+  * **`computationUtils`**: A set of helpers for categorizing calculations (historical vs. daily), committing results in chunks, and finding the earliest available data date.
 
-* **`index.js`:** Exports the factory function `createComputationSystemHandler` and the main orchestration logic `runComputationOrchestrator`.
-* **`handler_creator.js`:** Creates the HTTP-triggered Cloud Function handler that initiates the computation orchestration.
-* **`/helpers/orchestration_helpers.js`:** Contains the core logic for determining dates to process, identifying missing computations, loading data (using `data_loader.js`), initializing calculators from the unified package, processing data across dates, and committing results to Firestore.
-* **`/utils`:**
-    * `data_loader.js`: Functions specifically for loading portfolio data in parts/shards from Firestore for the computation system.
-    * `utils.js`: Helper functions for categorizing calculations (historical vs. daily), managing Firestore batches, handling date ranges, parallel processing, and finding the earliest data dates.
+### `pipe.api`
 
+The "tap" that serves the processed data. This pipe is an Express.js application designed to be run as a single Cloud Function, providing a public-facing API for the frontend.
 
-### `/generic-api`
+  * **`createApiApp(config, dependencies, unifiedCalculations)`**: The main entry point. It returns a fully configured Express app instance, complete with middleware (CORS, JSON) and all API routes.
+  * **API Helpers** (`buildCalculationMap`, `validateRequest`, `fetchUnifiedData`, etc.): Sub-pipes that handle request validation, fetching data from the "unified insights" collection, and generating debug manifests.
 
-Provides a flexible, cached API endpoint (intended for frontend use) to query computed data stored in Firestore.
+### `pipe.maintenance`
 
-* **`index.js`:** Exports the factory function `createApiApp` to set up the Express app.
-* **`/helpers/api_helpers.js`:** Contains logic for request validation, date range generation, data fetching from the unified insights collection, and building the calculation map.
+A collection of standalone utility and cleanup functions, typically run on a schedule.
 
-### `/invalid-speculator-handler`
+  * **`runSpeculatorCleanup(config, dependencies)`**: De-registers stale speculators who haven't held a qualifying asset for a set grace period, and decrements the block counts.
+  * **`handleInvalidSpeculator(message, context, config, dependencies)`**: An event-driven function that listens for Pub/Sub messages containing CIDs of users found to be private or invalid, adding them to an exclusion list.
+  * **`runFetchInsights(config, dependencies)`**: A scheduled function to fetch general eToro market insights (e.g., buy/sell percentages).
+  * **`runFetchPrices(config, dependencies)`**: A scheduled function to fetch daily closing prices for all instruments.
 
-Listens to a Pub/Sub topic for messages containing IDs of users identified as private or inactive speculators and stores them in Firestore for future exclusion during discovery.
+### `pipe.proxy`
 
-* **`index.js`:** Exports helpers.
-* **`/helpers/handler_helpers.js`:** Core logic for finding/creating a Firestore document and adding the invalid IDs, managing document size limits.
+The logic for the Google Apps Script web app that acts as the secure proxy layer. This code is *not* run in the Node.js environment; it's intended to be deployed directly into an Apps Script project.
 
-### `/speculator-cleanup-orchestrator`
+  * **`handlePost(e)`**: The main `doPost(e)` function for the Apps Script. It parses the request from the `IntelligentProxyManager`, executes it using `UrlFetchApp`, and returns the response.
 
-A scheduled function to remove stale speculators from the active blocks based on inactivity and clean up old entries from the pending speculator list.
+-----
 
-* **`index.js`:** Exports the factory function `createSpeculatorCleanupHandler`.
-* **`/helpers/cleanup_helpers.js`:** Contains the core logic for querying blocks/pending lists based on grace periods and batching deletions/count updates.
+## Data Flow
 
-### `/fetch-insights`
+The system operates in four distinct, decoupled stages:
 
-Scheduled function to fetch daily instrument ownership insights (buy/sell percentages, total owners) from the eToro API.
+1.  **Stage 1: Discovery (Scheduled)**
 
-* **`index.js`:** Exports the factory function `createFetchInsightsHandler`.
-* **`/helpers/handler_helpers.js`:** Core logic for making the API call (via proxy manager) and storing the results in Firestore.
+      * `pipe.orchestrator.runDiscoveryOrchestrator` runs.
+      * It determines it needs 5,000 new `normal` users.
+      * It creates 50 `discover` tasks (100 CIDs each) and publishes them to the `task-engine` topic.
+      * `pipe.taskEngine` functions spin up, `handleDiscover` finds 200 promising users.
+      * It publishes 200 `verify` tasks back to the `task-engine` topic.
+      * `pipe.taskEngine` functions `handleVerify` these users, and 75 are saved to the database.
 
-### `/etoro-price-fetcher`
+2.  **Stage 2: Update (Scheduled)**
 
-Scheduled function to fetch daily closing prices for instruments from the eToro API.
+      * `pipe.orchestrator.runUpdateOrchestrator` runs.
+      * It finds 50,000 existing users that need an update.
+      * It publishes *one* message containing all 50,000 tasks to the `dispatcher` topic.
+      * `pipe.dispatcher.handleRequest` receives the message.
+      * It loops, publishing 500 tasks at a time to the `task-engine` topic, with a 30-second delay between batches.
+      * `pipe.taskEngine` functions `handleUpdate` the portfolios, scaling gradually.
 
-* **`index.js`:** Exports the factory function `createPriceFetcherHandler`.
-* **`/helpers/handler_helpers.js`:** Core logic for making the API call (via proxy manager) and batch-writing price updates to Firestore.
+3.  **Stage 3: Computation (Scheduled)**
 
-### `/appscript-api`
+      * `pipe.computationSystem.runOrchestration` runs (e.g., at 1:00 AM).
+      * It loads all portfolio data collected in Stages 1 & 2.
+      * It runs all calculations and saves the results to the `unified_insights` collection.
 
-Contains the helper logic intended to be deployed as a Google Apps Script web app, acting as the HTTP proxy layer.
+4.  **Stage 4: Serving (On-Demand)**
 
-* **`index.js`:** Exports the `handlePost` function.
-* **`/helpers/errors.js`:** Utility for creating standardized error responses.
+      * A frontend user loads a chart.
+      * The browser sends a request to the `pipe.api` function.
+      * The API validates the request, reads the *pre-computed* data from `unified_insights`, and returns it.
 
-## Setup & Usage
+## Usage
 
-```javascript
-// Example 
-const { Orchestrator } = require('bulltrackers-module');
-const cfg = require('./config/orchestrator_config'); // Load specific config
+In your Google Cloud Function `index.js` file:
 
-exports.discoveryOrchestrator = Orchestrator.createDiscoveryOrchestrator(cfg);
+```javascript
+const { initializeApp } = require('firebase-admin/app');
+const { getFirestore } = require('firebase-admin/firestore');
+const { PubSub } = require('@google-cloud/pubsub');
+const { pipe } = require('bulltrackers-module');
+const { createLogger } = require('sharedsetup'); // (Or your logger)
+
+// --- 1. Initialize Clients ---
+initializeApp();
+const db = getFirestore();
+const pubsub = new PubSub();
+const logger = createLogger();
+
+// --- 2. Load Function-Specific Config ---
+const orchestratorConfig = require('./config/orchestrator_config.js');
+const taskEngineConfig = require('./config/task_engine_config.js');
+
+// --- 3. Initialize Core Dependencies ---
+// These are shared across all functions that need them
+const dependencies = {
+    db,
+    pubsub,
+    logger,
+    headerManager: new pipe.core.IntelligentHeaderManager(
+        db, 
+        logger, 
+        taskEngineConfig.headerManager
+    ),
+    proxyManager: new pipe.core.IntelligentProxyManager(
+        db, 
+        logger, 
+        taskEngineConfig.proxyManager
+    ),
+    // ... add batchManager if needed for task-engine
+    batchManager: new pipe.core.FirestoreBatchManager(
+        db,
+        // The batch manager needs the header manager to flush performance
+        dependencies.headerManager, 
+        logger,
+        taskEngineConfig.batchManager
+    ),
+    // ... add core utils
+    firestoreUtils: pipe.core.firestoreUtils,
+    pubsubUtils: pipe.core.pubsubUtils
+};
+
+// --- 4. Export Cloud Functions ---
+
+// Example: Discovery Orchestrator (HTTP Trigger)
+exports.discoveryOrchestrator = async (req, res) => {
+    try {
+        await pipe.orchestrator.runDiscoveryOrchestrator(
+            orchestratorConfig, 
+            dependencies
+        );
+        res.status(200).send('Discovery orchestration complete.');
+    } catch (error) {
+        logger.log('ERROR', 'Discovery failed', { error: error.message });
+        res.status(500).send('Error');
+    }
+};
+
+// Example: Task Engine (Pub/Sub Trigger)
+exports.taskEngine = async (message, context) => {
+    await pipe.taskEngine.handleRequest(
+        message, 
+        context, 
+        taskEngineConfig, 
+        dependencies
+    );
+};
+```

package/functions/task-engine/helpers/update_helpers.js

@@ -42,16 +42,25 @@ async function handleUpdate(task, taskId, dependencies, config) {
             // Use batchManager from dependencies
             batchManager.deleteFromTimestampBatch(userId, userType, instrumentId);
 
-            const blockId = `${Math.floor(parseInt(userId) / 1000000)}M`;
+            // <<< START FIX for private user blockId format >>>
+            // The blockId format for Speculator Blocks is numeric (e.g., "1000000")
+            // The blockId for Normal Blocks is string (e.g., "1M")
+            let blockId;
+            let incrementField;
+
+            if (userType === 'speculator') {
+                blockId = String(Math.floor(parseInt(userId) / 1000000) * 1000000);
+                incrementField = `counts.${instrumentId}_${blockId}`;
+            } else {
+                blockId = `${Math.floor(parseInt(userId) / 1000000)}M`;
+                incrementField = `counts.${blockId}`;
+            }
             
             // Use db from dependencies
             const blockCountsRef = db.doc(userType === 'speculator' 
                 ? config.FIRESTORE_DOC_SPECULATOR_BLOCK_COUNTS 
                 : config.FIRESTORE_DOC_BLOCK_COUNTS);
-            
-            const incrementField = userType === 'speculator' 
-                ? `counts.${instrumentId}_${blockId}` 
-                : `counts.${blockId}`;
+            // <<< END FIX for private user blockId format >>>
                 
             await blockCountsRef.set({ [incrementField]: FieldValue.increment(-1) }, { merge: true });
 
@@ -65,15 +74,48 @@ async function handleUpdate(task, taskId, dependencies, config) {
         const portfolioData = JSON.parse(responseBody);
 
         const today = new Date().toISOString().slice(0, 10);
-        const blockId = `${Math.floor(parseInt(userId) / 1000000)}M`;
+        
+        // <<< START FULL CODE FIX >>>
 
-        // Use batchManager from dependencies
-        await batchManager.addToPortfolioBatch(userId, blockId, today, portfolioData, userType, instrumentId);
+        // BUG 1: The blockId format is different for portfolio storage ('1M') 
+        // vs. orchestrator logic ('1000000').
+        const portfolioStorageBlockId = `${Math.floor(parseInt(userId) / 1000000)}M`;
+        
+        // This call is correct for storing portfolio data (which uses the 'M' format)
+        await batchManager.addToPortfolioBatch(userId, portfolioStorageBlockId, today, portfolioData, userType, instrumentId);
+        
+        // This call is correct for 'normal' users, but for 'speculator' users
+        // it writes to a timestamp doc that the orchestrator *does not read*.
+        // We still call it to update 'normal' users correctly.
         await batchManager.updateUserTimestamp(userId, userType, instrumentId);
 
+        // BUG 2 (The Main Problem): We must *also* update the 'SpeculatorBlocks'
+        // collection, which is what the orchestrator *does* read.
+        if (userType === 'speculator') {
+            const orchestratorBlockId = String(Math.floor(parseInt(userId) / 1000000) * 1000000);
+
+            logger.log('INFO', `[UPDATE] Applying speculator timestamp fix for user ${userId} in block ${orchestratorBlockId}`);
+            
+            // Create a new, separate batch to commit this timestamp *immediately*.
+            // This mirrors the logic in 'verify_helpers.js'.
+            const fixBatch = db.batch();
+            const speculatorBlockRef = db.collection(config.FIRESTORE_COLLECTION_SPECULATOR_BLOCKS).doc(orchestratorBlockId);
+            
+            // These are the two fields the orchestrator and cleanup functions read
+            const updates = {
+                [`users.${userId}.lastVerified`]: new Date(),
+                [`users.${userId}.lastHeldSpeculatorAsset`]: new Date()
+            };
+
+            fixBatch.set(speculatorBlockRef, updates, { merge: true });
+            await fixBatch.commit();
+            logger.log('INFO', `[UPDATE] Speculator timestamp fix for user ${userId} committed.`);
+        }
+        // <<< END FULL CODE FIX >>>
+
     } finally {
         if (selectedHeader) headerManager.updatePerformance(selectedHeader.id, wasSuccess);
     }
 }
 
-module.exports = { handleUpdate };
+module.exports = { handleUpdate };

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "bulltrackers-module",
-  "version": "1.0.53",
+  "version": "1.0.54",
   "description": "Helper Functions for Bulltrackers.",
   "main": "index.js",
   "files": [