11:59 <stellar-slack> <armed10> Where can i find the tx id of a transaction before i send it. because the hash function doesn't match the txid.

12:00 <stellar-slack> <armed10> result database : CybcGx3ECtdi9xybg6F+p6NRZ9Oyup+vusUf72wdhbAAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAAAAAAAAAAAAA== txid database : 0b26dc1b1dc40ad762f71c9b83a17ea7a35167d3b2ba9fafbac51fef6c1d85b0 transaction.hash().toString('base64') : CybcGx3ECtdi9xybg6F+p6NRZ9Oyup+vusUf72wdhbA=

12:32 <stellar-slack> <raymens> what is the hash without the base64?

12:32 <stellar-slack> <bartek> can you change `base64` to `hex`?

12:33 <stellar-slack> <bartek> `transaction.hash().toString('hex')`

12:36 <stellar-slack> <armed10> it is the id

12:37 <stellar-slack> <armed10> i thought it had something to do with the result because parts are matching

12:37 <stellar-slack> <armed10> when encoding base64

12:39 <stellar-slack> <armed10> thx

14:04 <stellar-slack> <armed10> If one operation in a transaction fails. are the other operations still completed or do they all fail ?

14:05 <stellar-slack> <bartek> all fail

14:05 <stellar-slack> <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.

14:06 <stellar-slack> <bartek> (https://www.stellar.org/developers/learn/concepts/transactions.html)

14:06 <stellar-slack> <dzham> That’s what’s so beautiful about transaction envelopes

14:12 <stellar-slack> <dzham> E.g.: A lot of the back-and-forth you had to do before in certain situations, now you just plug that into one tx that both parties sign, and you’re done

14:38 <stellar-slack> <armed10> So I was trying out the new version of horizon. The importer is still required, so I've moved back to stellar-core version 0.3.3. The importer is able to its job as long as there are no transactions in the ledgers. As soon as anything happens on the network the importer crashes. What gives?

14:42 <stellar-slack> <raymens> What does it output as soon as it crashes?

14:48 <stellar-slack> <armed10> Actor crashed! RuntimeError: Could not find all participants

14:48 <stellar-slack> <armed10> \/home/chain/stellar/horizon-importer/app/jobs/history/ledger_importer_job.rb:331:in `block in import_history_operations'

14:55 <stellar-slack> <jed> Armed10: I think scott will have the importer free horizon done tomorrow

15:08 <stellar-slack> <raymens> @armed10: no clue, seems that it has some trouble finding actors

15:09 <stellar-slack> <raymens> horizon and importer are running fine over here

15:09 <stellar-slack> <raymens> horizon without the importer is great news though! :)

15:48 <stellar-slack> <scott> yeah, it’s going to be a couple more days on the importer… I ran into a weird issue with logging/testing yesterday and it took most of the day to track down :( Relics from the beginnings of my journey with go

15:51 <stellar-slack> <scott> @armed10: Could you provide the transaction envelope that is triggering that crash in horizon-importer? Import happens in order, so if your `history_transaction` table is empty, simple lookup the first `txbody` column for the `txhistory` when ordered by `ledgerseq, txindex`