#Seeing a lot of `txSorobanInvalid` using the local Docker quickstart
33 messages · Page 1 of 1 (latest)
Could be related to https://discord.com/channels/897514728459468821/1155167115142254643.
Discord is the easiest way to communicate over voice, video, and text. Chat, hang out, and stay close with your friends and communities.
fwiw these same series of calls work on futurenet
My contract doesn't do any deploying, but it is adding to and reading from an increasingly large vector, why read_bytes and instructions grow over time
My understanding though was standalone had less stringent fee checks than futurenet/testnet
So I should be able to do more vs less in standalone
Sorry it's called local now
fwiw I'm using stellar/quickstart:testing. Lmk if there's a newer tag I should try
Yup this sounds exactly like this issue https://discord.com/channels/897514728459468821/1155167115142254643
I suspect stellar-core's high override feature is buggy.
I'd like to get quickstart off of using that flag, and get it updated to use the stellar-core config, but the config is currently updated via a gnarly python script, and there's this stellar-core issue to clean that up:
This is the quickstart issue:
https://github.com/stellar/quickstart/issues/508
@polar vector Is there a plan to prioritize ☝🏻 ?
Hi @alpine hollow , We discussed this within the team today and we will be prioritizing to get this issue addressed for the v20 stable release.
We've actually got a fix building at the moment.
Fix was in https://github.com/stellar/quickstart/pull/509. It's merged, and the final image is building.
Can confirm this update fixed my issues. I HAVE SO MUCH POWER NOW!!!
Testing on local is so nice, lighter limits, faster speeds, SWEET
Makes me really want a tool that can run an invocation and then match it's output against this table
https://soroban.stellar.org/docs/fundamentals-and-concepts/fees-and-metering#resource-limits
If the limits were available on an endpoint of the rpc, the cli could output how close you are to limits.
I may try and rough something up soon since the simulation gives you a lot of stuff, I'm just not sure it gives you all the stuff
RAM in particular I'm finding is a tough one as it's never surfaced back This isn't true it's surfaced back in the response to the sim just outside the sorobanData
Events & return value sizeI think I could get this back from the sim I'd just need to be sure I was including the right values to derive the correct sumLedger entry sizeI'm not quite sure what that is but I'd imagine it's somewhere in there. The rest I believe I already know how to get
I give to you sorobill. Pass it a simulation json file and it will output a response of the fees. If you use the local Docker quickstart you can gen simulations far above those of the Phase 1 futurenet and testnet which can help with finding where you may be exceeding limits.
e.g. ./sorobill --file ./simulation_response.json
{
CPU_instructions: 18752917,
RAM: 2629481,
ledger_entry_reads: 2,
ledger_entry_writes: 12,
ledger_write_bytes: 4112,
ledger_read_bytes: 32428,
events_and_return_value_size: 2236
}
e.g. ./simulation_response.json
You can see from this in my case events_and_return_value_size > 2 KB or 2,024 bytes which would break in futurenet / testnet according to the current Phase 1 limits
@half grail @wispy temple tyler's tool auto calculates the usage... wanna give it a go for our chat re: limits.
Hii @halcyon coyote, you intent maintain or create a repo with the source code of sorobill? I believe it would be a beneficial approach to integrate sorobill into the testing framework we are developing, as we require transaction metrics.