Fix LDK reader crash under ES2023 target of @labkey/api#303
Merged
Conversation
Under the pre-@labkey/api-1.52.0 ES5 target, `FieldKey.fromParts` was compiled to a plain function property, which is [[Construct]]-able, so `new LABKEY.FieldKey.fromParts(...)` worked by convention. Once @labkey/api targets ES2023 (labkey-api-js#219) the class is emitted as a native ES6 class whose static methods are not constructors, so the `new` call throws `TypeError: not a constructor`. The exception unwinds `Ext4.each` before the reader's `readRecords` calls `callParent`, so `idProperty` is never set on the reader and every subsequent update fails the "Record passed as update which lacks keyfield" assertion in EHR data-entry stores.
bbimber
approved these changes
Jul 13, 2026
Author
|
@bbimber Thank you! |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Rationale
Under the pre-ES2023 target of
@labkey/api, TypeScript compiledFieldKey.fromPartsto a plain function property. Regular functions in JS are constructable, and when you call one withnewand the function explicitly returns an object,newjust hands back that returned object — sonew LABKEY.FieldKey.fromParts(x)andLABKEY.FieldKey.fromParts(x)produced the same value, and the misusednewwas redundant but harmless. Under ES2023,FieldKeyemits as a native ES6 class andfromPartsbecomes a real class static method. Static methods on native ES6 classes can be called normally but are not constructors — invoking one withnewthrowsTypeError: … is not a constructor.The bad call sits in the
readRecordsoverride inLabKeyStore.js. Whennewthrows, the reader aborts before finishing its setup, leaving downstream Ext stores unable to identify their records on submit. That's what broke the JHU_EHR and NIRC_EHR data-entry tests (https://teamcity.labkey.org/buildConfiguration/LabkeyTrunk_EhrPostgres?branch=%3Cdefault%3E&buildTypeTab=overview#all-projects). However, this isn't a test-only fix, any Ext4 store whose reader chain resolves to LDK.data.proxy.ExtendedJsonReader - the default for LDK.data.LabKeyStore and everything extending it (EHR.data.DataEntryServerStore in particular) - hangs or fails on submit for real users whenever the query metadata carries a field without a nameRelated Pull Requests
LABKEY.*runtime overrides. This particular PR handles another one affecting EHR data entry formsChanges
LDK/resources/web/LDK/data/LabKeyStore.js: drop the redundantnewfrom the call toLABKEY.FieldKey.fromParts(field.fieldKey).fromPartsis a factory that already constructs and returns aFieldKey; no behavior change other than restoring compatibility with ES2023-compiled@labkey/api.