doppelgnubeard has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
gnubeard has quit [Ping timeout: 264 seconds]
gnubeard has joined #stellar-dev
<stellar-slack1>
<armed10> The XDR decode worked, turns out if the first operation fails, the rest gets a success message, so you won't know exactly which operations failed in a transaction.
<stellar-slack1>
<armed10> However, there's a new block we're stumbling upon. We stopped combining operations in transactions because you can't just retry with a subset (given you don't know which failed).
<stellar-slack1>
<armed10> The problem is the core crashes on a XDR overflow error. Does anyone know why this error occurs (heavy load maybe?) or how to deal with it?
<stellar-slack1>
<bartek> > Operations are executed in order as one ACID transaction, meaning that either all operations are applied or none are. If any operation fails, the whole transaction fails.
<stellar-slack1>
<bartek> when it comes to XDR overflow error, do you have a log for this?
<stellar-slack1>
<armed10> I know all operation fail if one fails. That's why we used to try and filter faulty operations and retry a subset that we though would succeed.
<stellar-slack1>
<armed10> Let me see if I can find a log
<stellar-slack1>
<bartek> ok, I see
<stellar-slack1>
<armed10> bundling operations has a significant performance boost IF all operations succeed. We just assumed it would check all of them for errors before rejecting the entire transaction
<stellar-slack1>
<armed10> We're re-running the test to reproduce the error. it'll take a few minutes
acetakwas has joined #stellar-dev
<stellar-slack1>
<armed10> I can't reproduce this error at this moment, but I'll retry later and bring the issue up then.
<stellar-slack1>
<dchrist22> @armed10: did you manage to fix your problem with the transactions, that didn´t showed up in the database?
<stellar-slack1>
<armed10> @dchrist22: Yes, turns out the query we used wasn't right because of a sorting problem.
<stellar-slack1>
<mvaneijk> Hello, is it possible to regenerate the history of a node from ledger 0 to a location?
<stellar-slack1>
<bartek> What do you mean by regenerate?
<stellar-slack1>
<mvaneijk> The node is running and database exists. I incorrectly setup history storage using a script, and it returned 0 while it was not storing the history
<stellar-slack1>
<bartek> you can flush DB and start a node. it will catch up again. if need that node running, you can create another db and start a new stellar-core instance to store history.
<stellar-slack1>
<mvaneijk> But the second option would require some history store to catch up from
<stellar-slack1>
<mvaneijk> Because I don't have that.
<stellar-slack1>
<bartek> oh, so it's a private network?
<stellar-slack1>
<mvaneijk> yep
<stellar-slack1>
<mvaneijk> Restarting is an option, but it is not preferred
<stellar-slack1>
<mvaneijk> restarting as in "flushing the db"
<stellar-slack1>
<bartek> yeah, I meant the public network. I think that `--newhist` option may help but I'm not sure. j.ed or s.cott should be able to help.
acetakwas has quit [Ping timeout: 244 seconds]
<stellar-slack1>
<mvaneijk> I thought --newhist only initializes, so will probably not do the job
<stellar-slack1>
<jed> You need some history store or you can't catch up to the network
<stellar-slack1>
<jed> So if you don't have any history then you should restart the network
acetakwas has joined #stellar-dev
<stellar-slack1>
<mvaneijk> Ok. Would it be possible anyway to create the history from the SQL db? Or is there some info in the history store only
<stellar-slack1>
<bartek> if you don't care about the time/ledger when transaction happened I think you could create a script that would simply resubmit all transactions from the old network.
<stellar-slack1>
<jed> You could replay all the txs into a fresh a new instance of the network. That would probably be easiest
<stellar-slack1>
<jed> You could write something that recreates the history from the SQL but it would take a bit of work
<stellar-slack1>
<mvaneijk> That's the thing I wanted to know, thanks!
<stellar-slack1>
<armed10> @bartek: We've managed to replicate the XDR error