[BUG] Error thrown on doReadState

[atticusofsparta]

Describe the bug
When reading the state for new interactions an error is thrown, here is the stack trace:

   at nPe.doReadState (https://arns.app/assets/index-6547a579.js:581:7232)
   at async nPe.eval (https://arns.app/assets/index-6547a579.js:582:2628)
   at async $ee.callContract (https://arns.app/assets/index-6547a579.js:583:17353)
   at async $ee.dryWrite (https://arns.app/assets/index-6547a579.js:583:9367)
   at async Ioe.registerAtomicName (https://arns.app/assets/index-6547a579.js:912:2961)
   at async ate.registerAtomicName (https://arns.app/assets/index-6547a579.js:616:36058)
   at async D (https://arns.app/assets/index-6547a579.js:912:29966)
   at async G (https://arns.app/assets/index-6547a579.js:912:30934)
}

I believe this links to here and the code below needs to be moved up to before the validity object is accessed - normally, it seems this would have been set elsewhere or by reference elsewhere, however, i think, that due to the transaction being new (less than 2 minutes old at the time of this error) the GQL node's height was null which is a valid value for it to be.

To Reproduce
You should be able to reproduce this a couple different ways:

1. by duplicating the tags on this transaction : _oKeJUJLwtdD30uYzzV-afi0pQEpJIDZGCTC4qklWV0 - it is a Turbo (optimistically cached) L1 bundle with a $U token mint interaction and an ArNS tick interaction (should be able to copy the tags directly from the example tx), deploying it, and attempting an evaluation of the contract using the optimistically cached TX

2. by going into the warp SDK and modifying an interaction's gql node to mimic the return of optimistically cached interaction data

Expected behavior
The SDK should not crash on contract evaluation

Desktop (please complete the following information):

• OS: Win 10
• Node.js version: N/A (browser env)
• warp-contracts SDK version: 1.4.26
• warp-contracts plugins being used (+ versions): N/A
• Browser [e.g. chrome, safari]: Chrome, Brave, Firefox

Additional context
This happened on arns.app when executing a domain purchase and evaluating a tick state interaction.

[ppedziwiatr]

GQL node's height was null which is a valid value for it to be.

I don't think I get this one :-) null in block height would in general ruin contract evaluation - as contract code may depend on this value.
What is worse - if this value can 'change' during its lifetime (e.g. one request to GQL returns null height, another (some time after the previous request) - non null value - than this would result in a non-deterministic contract evaluation.

As of now - the mentioned _oKeJUJLwtdD30uYzzV-afi0pQEpJIDZGCTC4qklWV0 transaction returns 1325656 block height:

[dtfiedler]

Resolved with fix. This issue can be closed!