@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 +111 -2
- package/android/src/main/java/co/logbrew/reactnative/EventRecordStore.java +611 -0
- package/android/src/main/java/co/logbrew/reactnative/FatalStoreModuleImpl.java +129 -0
- package/android/src/newarch/java/co/logbrew/reactnative/FatalStoreModule.java +26 -0
- package/android/src/oldarch/java/co/logbrew/reactnative/FatalStoreModule.java +26 -0
- package/global-errors.cjs +4 -2
- package/global-errors.d.cts +63 -0
- package/global-errors.d.ts +63 -0
- package/global-errors.js +2 -1
- package/global-errors.native.js +63 -2
- package/index.cjs +2 -0
- package/index.d.cts +3 -0
- package/index.d.ts +3 -0
- package/index.js +2 -0
- package/index.native.d.ts +47 -2
- package/index.native.js +70 -2
- package/ios/LBRNEventRecordStore.h +29 -0
- package/ios/LBRNEventRecordStore.m +746 -0
- package/ios/LBRNFatalStoreModule.mm +159 -14
- package/ios/LBRNPrivateStorage.h +7 -0
- package/ios/LBRNPrivateStorage.m +38 -0
- package/package.json +7 -2
- package/persistent-delivery.native.js +282 -0
- package/promise-rejections.cjs +128 -4
- package/src/NativeLogBrewFatalStore.ts +9 -0
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
|
|
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,
|
|
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
|
|