> For the complete documentation index, see [llms.txt](https://triton.pharos.ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://triton.pharos.ai/1-42/release-notes/release-notes/1.42.md). # 1.42 Release notes for Pharos Triton 1.42 — LWC performance tracking, Apex governor-limit tracking, full Jest coverage, and Log\_\_c metadata fixes. > **Source commit:** [adaa303](https://github.com/Pharos-AI/triton/commit/adaa303e9a40bb7afe52036163fee5c89a3f38a7) > > **Released:** 2026-05-26 ## Highlights * **LWC performance tracking is now a first-class feature.** A reworked `triton.js`, `tritonBuilder.js`, and `tritonUtils.js` introduce `timeBackendCall`, `timeUserInteraction`, `trackComponentLifecycle`, `trackComponentRender`, and `startPerformanceMark`/`endPerformanceMark` — all per-instance isolated and Locker Service-safe. See [Profiling](/1-42/beyond-apex/profiling.md). * **Apex governor-limit tracking on `TritonBuilder`.** New `limitInfo()`, `limitInfoLite()`, `withFullLimitInfo()`, and `withoutLimitInfo()` methods capture transaction usage and limits from `System.Limits`, plus a new `Action__c` field and `action(String)` builder method. * **Full Jest test coverage** for `triton`, `tritonBuilder`, and `tritonUtils`, with a new `TESTING.md`, `jest.config.js`, and `jest.setup.js` at the repo root. * **`pharos__Log__c` metadata fixes.** Missing XML attributes restored on all limit fields, plus permission set updates so the new fields are immediately readable/writable. ## LWC performance tracking The LWC module gains a complete performance-tracking surface that piggy-backs on the existing logger: | API | Purpose | Log type | | --------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------- | | `bindToComponent(name)` | Required anchor for all profiling APIs. Generates a per-instance UUID so multiple instances on a page stay isolated. | n/a | | `timeBackendCall(name, () => apexCall)` | Wrap Apex calls; emits start/complete/failure logs with duration. Returns a `PerformanceCallBuilder` with four error-handling scenarios (default, `withoutRethrow`, `withCustomErrorHandler`, both). | `TYPE.BACKEND_CALL` | | `timeUserInteraction(name, async fn)` | Wrap a higher-level user flow that may contain nested backend calls. Same builder/error-handling model. | `TYPE.USER_INTERACTION` | | `trackComponentLifecycle('connected'\|'disconnected')` | Log mount/unmount events per instance. | `TYPE.COMPONENT_LIFECYCLE` | | `trackComponentRender()` | Increment a per-instance render counter and log it. | `TYPE.COMPONENT_RENDER` | | `startPerformanceMark(name)` / `endPerformanceMark(name)` | Browser-style timing for arbitrary regions, isolated per component instance. | `TYPE.PERFORMANCE` | The `TYPE` enum has expanded accordingly: ```javascript export const TYPE = { BACKEND: 'Backend', FRONTEND: 'Frontend', BACKEND_CALL: 'BackendCall', COMPONENT_LIFECYCLE: 'ComponentLifecycle', COMPONENT_RENDER: 'ComponentRender', USER_INTERACTION: 'UserInteraction', PERFORMANCE: 'Performance' }; ``` Time measurement uses a Locker Service-safe helper that prefers `performance.now()` and falls back to `Date.now()` when the Performance API is restricted. Per-instance state (marks, render counts, lifecycle events) is keyed by `componentName-uuid`, so two instances of the same component on a page never collide. Full walkthrough: [Profiling](/1-42/beyond-apex/profiling.md). ## Apex governor-limit tracking on TritonBuilder `TritonBuilder` (Apex) now captures transaction usage from `System.Limits` directly onto the log record. There are two modes, controlled by builder methods that compose with the rest of the fluent API. * `limitInfoLite()` — populates the essential set: SOQL queries/rows, DML statements/rows, CPU time, heap size, callouts (and their corresponding `*_Limit__c` companion fields). * `limitInfo()` — calls `limitInfoLite()` and, if `withFullLimitInfo()` has been chained earlier, also captures the extended set: aggregate queries, SOSL queries, future calls, queueable jobs, email invocations, push notifications, batch (async) calls, publish-immediate DML — and their limits. * `withFullLimitInfo()` — opt in to the extended set on the next `limitInfo()` call. * `withoutLimitInfo()` — opt out entirely; `limitInfo()` becomes a no-op for this builder. In addition, `TritonBuilder` exposes a new `action(String)` method that writes to the new **`Action__c`** field on `pharos__Log__c`. The field is used by the LWC performance-tracking layer to record method names, interaction names, and mark names, and is also available to Apex callers that want to tag logs with an action label. ## `pharos__Log__c` field metadata fixes All limit-related fields on `pharos__Log__c` had missing XML attributes that prevented some attributes from being recognized correctly. The affected fields: * `Batch_Jobs__c`, `Batch_Jobs_Limit__c` * `CPU_Time__c`, `CPU_Time_Limit__c` * `Callouts__c`, `Callouts_Limit__c` * `DML_Rows__c`, `DML_Rows_Limit__c` * `DML_Statements__c`, `DML_Statements_Limit__c` * `Email_Invocations__c`, `Email_Invocations_Limit__c` * `Future_Calls__c`, `Future_Calls_Limit__c` * `Heap_Size__c`, `Heap_Size_Limit__c` * `Publish_Immediate_DML__c`, `Publish_Immediate_DML_Limit__c` * `Push_Notifications__c`, `Push_Notifications_Limit__c` * `Queueable_Jobs__c`, `Queueable_Jobs_Limit__c` * `SOQL_Aggregates__c`, `SOQL_Aggregates_Limit__c` * `SOQL_Queries__c`, `SOQL_Queries_Limit__c` * `SOQL_Rows__c`, `SOQL_Rows_Limit__c` * `SOSL_Queries__c`, `SOSL_Queries_Limit__c` The new `Action__c` field was added under the same object. ## Permission set updates Both `Triton_Read` and `Triton_Write` permission sets were updated to include the new `Action__c` field and ensure consistent access to the fixed limit fields. After deploying 1.42, re-assign the permission sets (or refresh them via your deployment pipeline) so users pick up the new field-level access. ## Test suite A complete Jest test suite has been added under `force-app/main/default/lwc/*/__tests__/`: * `lwc/triton/__tests__/triton.test.js` — full coverage of the core class, including `PerformanceCallBuilder`. * `lwc/tritonBuilder/__tests__/tritonBuilder.test.js` — full coverage of the builder. * `lwc/tritonUtils/__tests__/tritonUtils.test.js` — full coverage of utility helpers. The repo now ships with `babel.config.js`, `jest.config.js`, `jest.setup.js`, and Jest-mock stubs under `jest-mocks/` so contributors can run `npm test` out of the box. See `TESTING.md` in the Triton repo for the full developer workflow. ## Upgrade notes * **No breaking API changes.** All new LWC profiling methods and Apex builder methods are additive. Existing Apex and LWC callers continue to work unchanged. * **Permission sets must be re-assigned (or re-deployed) after upgrade** so the new `Action__c` field and the fixed limit fields are visible to users. * **LWC profiling APIs require `bindToComponent()` first.** If you call `timeBackendCall`, `trackComponentLifecycle`, etc. on an unbound instance, Triton emits a console warning and skips the call — nothing throws. Existing components that already bind for logging purposes get profiling support for free. * **Limit info is opt-in.** Calling `limitInfo()` from Apex requires explicit invocation; existing builders won't suddenly start writing limit data unless you call it. Use `withFullLimitInfo()` to opt into the extended set.