@logbrew/react-native 0.1.9 → 0.1.11

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/README.md CHANGED
@@ -6,7 +6,7 @@
6
6
 
7
7
  React Native helpers for the public LogBrew JavaScript SDK.
8
8
 
9
- This package is intentionally thin. It keeps all event validation, retry, flush, and shutdown behavior in `@logbrew/sdk`, while adding mobile-friendly helpers for screen views, app-state changes, product actions, API milestones, handled JavaScript errors, app-owned Promise rejection reports, provider/hook usage, active W3C trace correlation, explicit W3C trace propagation, opt-in lifecycle spans, opt-in resource fetch spans, opt-in reversible global fetch spans, app-owned native bridge scope sync, and reversible instrumentation setup.
9
+ This package is intentionally thin. It keeps all event validation, retry, flush, and shutdown behavior in `@logbrew/sdk`, while adding mobile-friendly helpers for screen views, app-state changes, product actions, API milestones, handled JavaScript errors, opt-in Hermes Promise rejection tracking, app-owned Promise rejection callbacks, provider/hook usage, active W3C trace correlation, explicit W3C trace propagation, opt-in lifecycle spans, opt-in resource fetch spans, opt-in reversible global fetch spans, app-owned native bridge scope sync, and reversible instrumentation setup.
10
10
 
11
11
  ## Install
12
12
 
@@ -118,6 +118,73 @@ client key before creating a new client. A `429` preserves the queue and
118
118
  reports `pausedReason: "rate_limit"` plus the bounded retry signal exposed by
119
119
  the failed flush.
120
120
 
121
+ ## Offline And Restart Delivery
122
+
123
+ The React Native entry uses an app-private native queue by default when the
124
+ current app binary contains the linked LogBrew module. Each accepted event is
125
+ written before it enters memory. After a JavaScript runtime or app restart,
126
+ the client loads pending events oldest first with their original IDs. A
127
+ successful intake response commits which records were accepted before removing
128
+ them, so an interrupted removal can cause a duplicate but cannot silently lose
129
+ an unaccepted event. Replayed events keep their stable IDs. Delivery is at
130
+ least once, so apps must tolerate duplicates, including when retries regroup
131
+ events into different batches.
132
+
133
+ Inspect the delivery health snapshot to observe the active behavior:
134
+
135
+ ```js
136
+ const health = client.deliveryHealth();
137
+ if (health.storage !== "persistent") {
138
+ // The app is running without the linked native queue.
139
+ }
140
+ ```
141
+
142
+ The default `persistentQueue: "auto"` mode uses memory when the native module
143
+ is absent, including Expo Go and an older app binary after a JavaScript-only
144
+ update. For a production build that must not start without restart recovery,
145
+ set `persistentQueue: "required"`. Use `persistentQueue: "disabled"` only
146
+ when the app intentionally accepts a memory-only queue.
147
+
148
+ ```js
149
+ const client = createLogBrewReactNativeClient({
150
+ clientKey,
151
+ persistentQueue: "required",
152
+ transport: createReactNativeFetchTransport()
153
+ });
154
+ ```
155
+
156
+ The native queue stores one compact event per atomic record, is limited to
157
+ 1,000 events and 4 MiB of compact event data, and uses the same smaller limits
158
+ when you configure them on the client. Both platforms use app-private storage.
159
+ The client key is not written to disk; its SHA-256 digest separates queues
160
+ after key rotation. The queue does not provide mathematically exactly-once
161
+ delivery.
162
+
163
+ A successful `shutdown()` drains and closes the queue. A failed flush or
164
+ shutdown leaves the exact remainder available to the same client and the next
165
+ app start. Call `client.purgePendingEvents()` only when no flush or shutdown is
166
+ active. To retire an active key without sending its remainder, purge that
167
+ client first and then close it:
168
+
169
+ ```js
170
+ client.purgePendingEvents();
171
+ await client.shutdown();
172
+ ```
173
+
174
+ When no client owns the key, remove any remaining records explicitly with:
175
+
176
+ ```js
177
+ import { purgeLogBrewReactNativePersistentQueue } from "@logbrew/react-native";
178
+
179
+ purgeLogBrewReactNativePersistentQueue({ clientKey: previousClientKey });
180
+ ```
181
+
182
+ Use only one active persistent client for a given key across an app process.
183
+ The SDK rejects duplicates within one JavaScript runtime; apps with multiple
184
+ React Native runtimes or platform processes must coordinate that ownership.
185
+ Different client keys use separate native queues. The Node ESM and CommonJS
186
+ entries remain platform-neutral and never load React Native.
187
+
121
188
  ## Product Actions And API Milestones
122
189
 
123
190
  Use explicit action and network helpers for important mobile funnel steps your app already understands. These events are designed for timelines and agent analysis without enabling broad automatic replay:
@@ -202,7 +269,49 @@ Installation is idempotent for the active React Native `ErrorUtils` object. The
202
269
 
203
270
  The React Native conditional export obtains LogBrew's synchronous native fatal store through the supported TurboModule or `NativeModules` seam. Before chaining a fatal report, it writes one bounded record to app-private storage that is excluded from operating-system archives. On a later installation it performs stable-ID at-least-once replay, and acknowledgement happens only after local queue admission is observable through the SDK queue counters. Filtered, dropped, unknown-admission, persistence-failed, and acknowledgement-failed records are retained. A failed acknowledgement is retried without admitting the same ID twice in one JavaScript runtime. Use `fatalHealth()` for frozen bounded counters and status, or `discardPendingFatalRecord()` for an explicit rollback discard. The Node ESM and CommonJS entries never import React Native; non-React-Native callers must inject `fatalStore` explicitly.
204
271
 
205
- Automatic events exclude the original error message, raw stack, arbitrary metadata, full URLs, hosts, query strings, local absolute paths, payloads, and native error text. `onDiagnostic` receives only a fixed code. This integration does not claim mathematically exactly-once delivery, backend-visible deduplication, native crash capture, automatic Promise rejection tracker ownership, ANR or hang detection, general offline queueing, or symbolication.
272
+ Automatic events exclude the original error message, raw stack, arbitrary metadata, full URLs, hosts, query strings, local absolute paths, payloads, and native error text. `onDiagnostic` receives only a fixed code. This error-handler integration does not claim mathematically exactly-once delivery, native crash capture, ANR or hang detection, general offline queueing by the fatal-record slot, or symbolication. The client-level persistent queue above owns normal event restart delivery.
273
+
274
+ ### Opt-in Hermes Promise rejection tracking
275
+
276
+ React Native exposes one Promise rejection tracker slot. Claim it explicitly
277
+ when LogBrew is the only tracker owner:
278
+
279
+ ```js
280
+ import {
281
+ installLogBrewReactNativePromiseRejectionTracker
282
+ } from "@logbrew/react-native";
283
+
284
+ const promiseRejectionTracker =
285
+ installLogBrewReactNativePromiseRejectionTracker({
286
+ client,
287
+ takeOwnership: true,
288
+ onDiagnostic({ code }) {
289
+ console.warn(`LogBrew Promise rejection tracker: ${code}`);
290
+ }
291
+ });
292
+
293
+ promiseRejectionTracker.health();
294
+ promiseRejectionTracker.rejectionHealth();
295
+ ```
296
+
297
+ The React Native export discovers the active Hermes runtime and uses its
298
+ native tracker without replacing `globalThis.Promise`. Installation is
299
+ idempotent for that runtime slot. It records fixed-content issues without
300
+ reading the rejection value or emitting the runtime rejection identifier.
301
+ `rejectionHealth()` returns bounded duplicate, eviction, and later-handled
302
+ counters.
303
+
304
+ Do not install this helper while Sentry or another integration owns the same
305
+ tracker slot. Use the app-owned callback composition below when another
306
+ integration must remain the owner. Hermes does not expose a previous-owner
307
+ restoration API. `deactivate()` therefore stops LogBrew capture through its
308
+ installed callbacks but cannot reinstate an earlier tracker. Install
309
+ the replacement owner after deactivation when switching integrations.
310
+
311
+ For JavaScriptCore or another runtime, pass an explicit `tracker` with an
312
+ `enable(options)` function that already controls the Promise implementation
313
+ used by the app. LogBrew does not replace the global Promise or add a hidden
314
+ Promise polyfill.
206
315
 
207
316
  ### App-owned Promise rejection reports
208
317