edfcore 0.5.71 → 0.5.73

package/dist/constants.d.ts

@@ -109,5 +109,5 @@ export declare const SIGNAL_FIELD_BLOCK_OFFSETS: {
     readonly reserved: 224;
 };
 /** Published package version. Kept in sync with package.json by a test. */
-export declare const VERSION = "0.5.71";
+export declare const VERSION = "0.5.73";
 //# sourceMappingURL=constants.d.ts.map

package/dist/constants.js

@@ -79,5 +79,5 @@ export const SIGNAL_FIELD_BLOCK_OFFSETS = {
     reserved: 224,
 };
 /** Published package version. Kept in sync with package.json by a test. */
-export const VERSION = '0.5.71';
+export const VERSION = '0.5.73';
 //# sourceMappingURL=constants.js.map

package/docs/CHANGELOG.md

@@ -6,6 +6,51 @@ alone does not tell you whether you were affected.
 edfcore is pre-1.0. Patch releases have carried behaviour changes where the old behaviour was a
 defect; those are called out below.
 
+## 0.5.73
+
+- **Added** the day the network hiccups. `index.onsetTicks(r)` memoises, which is why `locate()`
+  costs `O(log recordCount)` reads instead of repeating them — and memoising is the classic place
+  to store a FAILURE by accident. Cache the promise rather than the value and one dropped
+  connection is permanent: every later caller awaits the same rejection and no retry ever reaches
+  the network. Nothing tested a read that fails and is then tried again.
+- The distinction is invisible until it matters, and it is one small edit away. 0.5.44 pinned that
+  concurrent callers of `onsetTicks` all miss the memo, because it holds values and not promises —
+  and the obvious way to "fix" that is to hold the promise instead. Making exactly that change
+  fails three of the eight checks here, which is the point of writing them down.
+- `a-read-that-failed-is-not-remembered.test.ts` uses a source that rejects a stated number of
+  times and then behaves. An onset, a `locate`, and a window are each asked for while it is failing
+  and again after, and the answer after has to be the answer a source that never failed would have
+  given. The rejection arrives as the caller's own error — `isEdfError` is false for it, because a
+  dropped connection says nothing about the recording.
+- `cachedSource` gets the same question, provoked at the first read: it coalesces a small file into
+  one range, so by the time a recording is open there is nothing left for a later read to fail at.
+  A failed open leaves the cache holding nothing, and the retry through the same cache reads
+  correctly.
+- The other half is asserted so none of it passes on a package that simply never caches: a
+  SUCCESSFUL read is remembered, two calls for one record cost one read, and a record index that
+  cannot exist is refused out of the header without touching the source at all.
+
+## 0.5.72
+
+- **Added** the case none of the four caller-supplied callbacks documents: what happens when yours
+  throws. edfcore calls a `ByteSource.read`, an `onProgress` on each of the two traversals, and a
+  predicate on the two matching helpers. Three of the four say what they should RETURN and none of
+  the four says what a throw does — which is not exotic: a progress callback writes to a DOM node
+  that has been removed, a label predicate calls `toLowerCase` on a signal with no label.
+- Two answers matter and they pull opposite ways. The error must arrive UNCHANGED — the same
+  object, not wrapped, not turned into a diagnostic — because wrapping it makes the caller's own bug
+  look like a problem with the file, and `isEdfError` has to say false for it. And the recording
+  must SURVIVE it: every one of these calls happens partway through something with state, and a
+  throw unwinds through all of it.
+- `when-your-callback-throws.test.ts` checks both for the three that had nothing;
+  `source-contract.test.ts` already covers the source. After a callback throws mid-scan, the same
+  recording rebuilds to the same index, validates to the same verdict, and leaves the annotation
+  array it was given untouched — each compared against a recording that never saw a failure.
+- One check is about the failure a memoised promise would produce: a second attempt has to reach
+  the callback again rather than a remembered rejection, or one bad progress callback breaks the
+  operation for the life of the recording. Wrapping the progress call in a `try`/`catch` that
+  swallows fails three of the nine.
+
 ## 0.5.71
 
 - **Added** the case every diagnostic test avoids: a file with more than one thing wrong with it.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "edfcore",
-  "version": "0.5.71",
+  "version": "0.5.73",
   "description": "Modern, typed, zero-dependency reader for EDF, EDF+, BDF and BDF+ biosignal files. Works in browsers and Node with true random access.",
   "keywords": [
     "edf",

package/src/constants.ts

@@ -93,4 +93,4 @@ export const SIGNAL_FIELD_BLOCK_OFFSETS = {
 } as const;
 
 /** Published package version. Kept in sync with package.json by a test. */
-export const VERSION = '0.5.71';
+export const VERSION = '0.5.73';