Properly parse simulateTransaction response variations
#146
Conversation
| )) || | ||
| (asRaw.results ?? []).length > 0 | ||
| ); | ||
| return !(sim as SorobanRpc.SimulateTransactionResponse)._parsed; |
| @@ -235,3 +237,43 @@ function invokeSimulationResponseWithRestoration(address) { | |||
| } | |||
| }; | |||
| } | |||
|
|
|||
| describe('works with real responses', function() { | |||
There was a problem hiding this comment.
not suggesting a change, just wondering on hardcoding xdr as precedence in tests or build the js xdr object graph and then serialize via .toXdr() rather than hardcoding?
There was a problem hiding this comment.
honestly I mostly just added this as a sanity check that the specific error we were seeing got fixed. another nice part about this is that if the XDR changes, this test will fail, prompting investigation and tests with a new RPC
I agree in general that it's better to build XDR then parse it rather than hardcoding, but that also doesn't reflect real RPC behavior sometimes.. we really need to build integration tests for RPC ➡️ soroban-client, but now isn't the time for that heh
There was a problem hiding this comment.
agreed, this isn't the place for that type of integration test, this should just work against the rpc interface, that's what system-test/e2e is for.
This modifies the response parsing to simply attach a
_parsedfield onto the parsed structure, simplifying the error-prone schema detection mechanism from before.It also updates various TypeScript definitions with the correct field types: latestLedger is a string, not a number, in most responses.