error: XDR Read Error: attempt to read outside the boundary of the buffer

[kalepail]

Describe the bug

627 |     super(`XDR Write Error: ${message}`);
628 |   }
629 | }
630 | class XdrReaderError extends TypeError {
631 |   constructor(message) {
632 |     super(`XDR Read Error: ${message}`);
          ^
error: XDR Read Error: attempt to read outside the boundary of the buffer
      at new XdrReaderError (/Users/tylervanderhoeven/Desktop/Web/Stellar/js-stellar-sdk/node_modules/@stellar/js-xdr/lib/xdr.js:632:5)
      at advance (/Users/tylervanderhoeven/Desktop/Web/Stellar/js-stellar-sdk/node_modules/@stellar/js-xdr/lib/xdr.js:1194:43)
      at readInt32BE (/Users/tylervanderhoeven/Desktop/Web/Stellar/js-stellar-sdk/node_modules/@stellar/js-xdr/lib/xdr.js:1229:37)
      at read (/Users/tylervanderhoeven/Desktop/Web/Stellar/js-stellar-sdk/node_modules/@stellar/js-xdr/lib/xdr.js:557:20)
      at read (/Users/tylervanderhoeven/Desktop/Web/Stellar/js-stellar-sdk/node_modules/@stellar/js-xdr/lib/xdr.js:1762:21)
      at fromXDR (/Users/tylervanderhoeven/Desktop/Web/Stellar/js-stellar-sdk/node_modules/@stellar/js-xdr/lib/xdr.js:2172:20)
      at /Users/tylervanderhoeven/Desktop/Web/Stellar/js-stellar-sdk/lib/rpc/parsers.js:91:14
      at map (:1:21)
      at parseSuccessful (/Users/tylervanderhoeven/Desktop/Web/Stellar/js-stellar-sdk/lib/rpc/parsers.js:88:112)
      at parseRawSimulation (/Users/tylervanderhoeven/Desktop/Web/Stellar/js-stellar-sdk/lib/rpc/parsers.js:128:10)

Bun v1.1.8 (macOS arm64)

What version are you on?
"@stellar/stellar-sdk": "12.1.0",

To Reproduce
https://gist.github.com/kalepail/191923ce760a1bbbdc1cd4b6cdbbee46

Expected behavior
There should be no bug and the simulation response should be parsed successfully.

Additional context
See the note here https://gist.github.com/kalepail/191923ce760a1bbbdc1cd4b6cdbbee46?permalink_comment_id=5114024#gistcomment-5114024 but essentially the js-sdk is bugging on a null or "" state change. I'm not sure if this is an sdk or an rpc bug then as that seems like a pretty weird state change to report. Here's the full simulation response though the above gist will also get you this.

{
  transactionData: "AAAAAAAAAAMAAAAGAAAAAanMljm6XcxZ1Ejd99hYb7BZsCPBUlh6P5EcstOvaluQAAAAFAAAAAEAAAAHJcPCj9CShkjGbHKUqs1Sd/W9SrY0ONwz25JIOXdqWRUAAAAH2cMJhVuGXFUbuhlS+8yCaGfXBO8SqvWHqbwTNX9JFbMAAAADAAAABgAAAAEOxZJBBaRvVX+N4Kz+7y7IXDJiHKGcv2ZSS7gJ1CDYlAAAAA0AAAAUfbB1czkMrKKuXl3v3/twH0/VqJUAAAAAAAAABgAAAAEOxZJBBaRvVX+N4Kz+7y7IXDJiHKGcv2ZSS7gJ1CDYlAAAAA0AAAAUfbB1czkMrKKuXl3v3/twH0/VqJUAAAABAAAABgAAAAEOxZJBBaRvVX+N4Kz+7y7IXDJiHKGcv2ZSS7gJ1CDYlAAAABQAAAABACyJ+QAAJ5gAAAEgAAAAAABPODw=",
  minResourceFee: "5191740",
  events: [ "AAAAAQAAAAAAAAAAAAAAAgAAAAAAAAADAAAADwAAAAdmbl9jYWxsAAAAAA0AAAAgqcyWObpdzFnUSN332FhvsFmwI8FSWHo/kRyy069qW5AAAAAPAAAABmRlcGxveQAAAAAAEAAAAAEAAAACAAAADQAAABR9sHVzOQysoq5eXe/f+3AfT9WolQAAAA0AAABBBJFhCrhmp0SLcac+YTROcq+SKautVIDzg59ppjN7hir1Imo00C0b0uDYr/KDd4duQdSCqtfVFGR5H2yMmg1zxrgAAAA=",
    "AAAAAQAAAAAAAAABqcyWObpdzFnUSN332FhvsFmwI8FSWHo/kRyy069qW5AAAAACAAAAAAAAAAMAAAAPAAAAB2ZuX2NhbGwAAAAADQAAACAOxZJBBaRvVX+N4Kz+7y7IXDJiHKGcv2ZSS7gJ1CDYlAAAAA8AAAAEaW5pdAAAABAAAAABAAAAAgAAAA0AAAAUfbB1czkMrKKuXl3v3/twH0/VqJUAAAANAAAAQQSRYQq4ZqdEi3GnPmE0TnKvkimrrVSA84OfaaYze4Yq9SJqNNAtG9Lg2K/yg3eHbkHUgqrX1RRkeR9sjJoNc8a4AAAA",
    "AAAAAQAAAAAAAAABDsWSQQWkb1V/jeCs/u8uyFwyYhyhnL9mUku4CdQg2JQAAAABAAAAAAAAAAQAAAAPAAAABXN3X3YxAAAAAAAADwAAAANhZGQAAAAADQAAABR9sHVzOQysoq5eXe/f+3AfT9WolQAAAA8AAAAEaW5pdAAAABAAAAABAAAAAgAAAA0AAABBBJFhCrhmp0SLcac+YTROcq+SKautVIDzg59ppjN7hir1Imo00C0b0uDYr/KDd4duQdSCqtfVFGR5H2yMmg1zxrgAAAAAAAAAAAAAAQ==",
    "AAAAAQAAAAAAAAABDsWSQQWkb1V/jeCs/u8uyFwyYhyhnL9mUku4CdQg2JQAAAACAAAAAAAAAAIAAAAPAAAACWZuX3JldHVybgAAAAAAAA8AAAAEaW5pdAAAAAE=",
    "AAAAAQAAAAAAAAABqcyWObpdzFnUSN332FhvsFmwI8FSWHo/kRyy069qW5AAAAACAAAAAAAAAAIAAAAPAAAACWZuX3JldHVybgAAAAAAAA8AAAAGZGVwbG95AAAAAAASAAAAAQ7FkkEFpG9Vf43grP7vLshcMmIcoZy/ZlJLuAnUINiU"
  ],
  results: [
    {
      auth: [],
      xdr: "AAAAEgAAAAEOxZJBBaRvVX+N4Kz+7y7IXDJiHKGcv2ZSS7gJ1CDYlA==",
    }
  ],
  cost: {
    cpuInsns: "2806640",
    memBytes: "2762016",
  },
  stateChanges: [
    {
      type: "",
      key: "",
      before: null,
      after: null,
    }, {
      type: "created",
      key: "AAAABgAAAAEOxZJBBaRvVX+N4Kz+7y7IXDJiHKGcv2ZSS7gJ1CDYlAAAAA0AAAAUfbB1czkMrKKuXl3v3/twH0/VqJUAAAAB",
      before: null,
      after: "AAAAAAAAAAYAAAAAAAAAAQ7FkkEFpG9Vf43grP7vLshcMmIcoZy/ZlJLuAnUINiUAAAADQAAABR9sHVzOQysoq5eXe/f+3AfT9WolQAAAAEAAAANAAAAQQSRYQq4ZqdEi3GnPmE0TnKvkimrrVSA84OfaaYze4Yq9SJqNNAtG9Lg2K/yg3eHbkHUgqrX1RRkeR9sjJoNc8a4AAAAAAAAAA==",
    },
    {
      type: "created",
      key: "AAAABgAAAAEOxZJBBaRvVX+N4Kz+7y7IXDJiHKGcv2ZSS7gJ1CDYlAAAABQAAAAB",
      before: null,
      after: "AAAAAAAAAAYAAAAAAAAAAQ7FkkEFpG9Vf43grP7vLshcMmIcoZy/ZlJLuAnUINiUAAAAFAAAAAEAAAATAAAAACXDwo/QkoZIxmxylKrNUnf1vUq2NDjcM9uSSDl3alkVAAAAAQAAAAEAAAAPAAAABXN3X3YxAAAAAAAAAQAAAAA=",
    }
  ],
  latestLedger: 430215,
}

[kalepail]

Very specifically this arises from a scenario where a contract tries to delete a temporary entry which doesn't exist.

If I change my contract code from:

env.storage().temporary().remove(id);

to

if env.storage().temporary().has(id) {
    env.storage().temporary().remove(id);
}

The problem goes away.

This still seems like a bug though either in simulation, the simulation response or the js-sdk.

[kalepail]

Closed in favor of stellar/stellar-rpc#239