Sync producer erroring for repeated transactions with the same transaction ID

Description
There seems to be an issue with repeatedly creating transactions with the same transaction ID. I have a toy example that creates a SyncProducer with a stable transaction ID "transaction-id", repeatedly calls BeginTxn(), SendMessages(), CommitTxn() in a loop until failure. I have debug logging enabled, and almost immediately, I see the error:
txnmgr/add-partition-to-txn retrying after 20ms... (1 attempts remaining) (transaction manager: failed to send partitions to transaction: kafka server: The producer attempted to update a transaction while another concurrent operation on the same transaction was ongoing)
When I increase config.Producer.Transaction.Retry.Backoff, I see crashes happen less often, but I still see the same error from the transaction manager.
When I increase sleepTime (which introduces a delay between starting transactions), I see this issue go away entirely.
Is this an issue in sarama's handling of transaction state? Or do I have a misunderstanding?
Versions

Sarama
Kafka
Go

1.43.1
3.6.0
1.21.8

Configuration

	config.Version = sarama.V3_6_0_0
	config.ClientID = "client-id"
	config.Producer.RequiredAcks = sarama.WaitForAll
	config.Producer.Transaction.Retry.Max = 1
	config.Producer.Return.Errors = true
	config.Producer.Return.Successes = true
	config.Producer.Idempotent = true
	config.Net.MaxOpenRequests = 1
	config.Producer.Timeout = 1 * time.Minute
	config.Producer.Transaction.ID = "transaction-id"

Logs

logs: CLICK ME

{"level":"debug","time":"2024-04-12T13:14:40-06:00","caller":"/Users/thomaslarge/sarama/vendor/github.com/IBM/sarama/sarama.go:132","message":"Initializing new client\n"}
{"level":"debug","time":"2024-04-12T13:14:40-06:00","caller":"/Users/thomaslarge/sarama/vendor/github.com/IBM/sarama/sarama.go:129","message":"client/metadata fetching metadata for all topics from broker localhost:9092\n"}
{"level":"debug","time":"2024-04-12T13:14:40-06:00","caller":"/Users/thomaslarge/sarama/vendor/github.com/IBM/sarama/sarama.go:129","message":"Connected to broker at localhost:9092 (unregistered)\n"}
{"level":"debug","time":"2024-04-12T13:14:40-06:00","caller":"/Users/thomaslarge/sarama/vendor/github.com/IBM/sarama/sarama.go:129","message":"client/brokers registered new broker #0 at localhost:9092"}
{"level":"debug","time":"2024-04-12T13:14:40-06:00","caller":"/Users/thomaslarge/sarama/vendor/github.com/IBM/sarama/sarama.go:132","message":"Successfully initialized new client\n"}
{"level":"debug","time":"2024-04-12T13:14:40-06:00","caller":"/Users/thomaslarge/sarama/vendor/github.com/IBM/sarama/sarama.go:129","message":"txnmgr/init-producer-id [transaction-id] invoking InitProducerId with current producer ID -1 and epoch -1 in order to bump the epoch\n"}
{"level":"debug","time":"2024-04-12T13:14:40-06:00","caller":"/Users/thomaslarge/sarama/vendor/github.com/IBM/sarama/sarama.go:129","message":"client/coordinator requesting coordinator for transaction-id from localhost:9092\n"}
{"level":"debug","time":"2024-04-12T13:14:40-06:00","caller":"/Users/thomaslarge/sarama/vendor/github.com/IBM/sarama/sarama.go:129","message":"Connected to broker at localhost:9092 (registered as #0)\n"}
{"level":"debug","time":"2024-04-12T13:14:40-06:00","caller":"/Users/thomaslarge/sarama/vendor/github.com/IBM/sarama/sarama.go:129","message":"client/coordinator coordinator for transaction-id is #0 (localhost:9092)\n"}
{"level":"debug","time":"2024-04-12T13:14:40-06:00","caller":"/Users/thomaslarge/sarama/vendor/github.com/IBM/sarama/sarama.go:129","message":"txnmgr/transition [transaction-id] transition from ProducerTxnStateUninitialized to ProducerTxnStateReady\n"}
{"level":"debug","time":"2024-04-12T13:14:40-06:00","caller":"/Users/thomaslarge/sarama/vendor/github.com/IBM/sarama/sarama.go:129","message":"txnmgr/init-producer-id [transaction-id] successful init producer id &{ThrottleTime:0s Err:kafka server: Not an error, why are you printing me? Version:4 ProducerID:3017 ProducerEpoch:71}\n"}
{"level":"debug","time":"2024-04-12T13:14:40-06:00","caller":"/Users/thomaslarge/sarama/vendor/github.com/IBM/sarama/transaction_manager.go:919","message":"txnmgr/init-producer-id [transaction-id] obtained a ProducerId: 3017 and ProducerEpoch: 71\n"}
Starting transaction:  ProducerTxnStateReady
{"level":"debug","time":"2024-04-12T13:14:40-06:00","caller":"/Users/thomaslarge/sarama/vendor/github.com/IBM/sarama/sarama.go:129","message":"txnmgr/transition [transaction-id] transition from ProducerTxnStateReady to ProducerTxnStateInTransaction\n"}
{"level":"debug","time":"2024-04-12T13:14:40-06:00","caller":"/Users/thomaslarge/sarama/vendor/github.com/IBM/sarama/async_producer.go:914","message":"producer/broker/0 starting up\n"}
{"level":"debug","time":"2024-04-12T13:14:40-06:00","caller":"/Users/thomaslarge/sarama/vendor/github.com/IBM/sarama/async_producer.go:930","message":"producer/broker/0 state change to [open] on test/0\n"}
{"level":"debug","time":"2024-04-12T13:14:40-06:00","caller":"/Users/thomaslarge/sarama/vendor/github.com/IBM/sarama/sarama.go:129","message":"txnmgr/add-partition-to-txn [transaction-id] successful to add partitions txn &{Version:2 ThrottleTime:0s Errors:map[test:[0x140000100d0]]}\n"}
{"level":"debug","time":"2024-04-12T13:14:40-06:00","caller":"/Users/thomaslarge/sarama/vendor/github.com/IBM/sarama/sarama.go:129","message":"producer/txnmgr [transaction-id] committing transaction\n"}
{"level":"debug","time":"2024-04-12T13:14:40-06:00","caller":"/Users/thomaslarge/sarama/vendor/github.com/IBM/sarama/sarama.go:129","message":"txnmgr/transition [transaction-id] transition from ProducerTxnStateInTransaction to ProducerTxnStateEndTransaction|ProducerTxnStateCommittingTransaction\n"}
{"level":"debug","time":"2024-04-12T13:14:40-06:00","caller":"/Users/thomaslarge/sarama/vendor/github.com/IBM/sarama/sarama.go:129","message":"txnmgr/endtxn [transaction-id] successful to end txn &{Version:0 ThrottleTime:0s Err:kafka server: Not an error, why are you printing me?}\n"}
{"level":"debug","time":"2024-04-12T13:14:40-06:00","caller":"/Users/thomaslarge/sarama/vendor/github.com/IBM/sarama/sarama.go:129","message":"txnmgr/transition [transaction-id] transition from ProducerTxnStateEndTransaction|ProducerTxnStateCommittingTransaction to ProducerTxnStateReady\n"}
{"level":"debug","time":"2024-04-12T13:14:40-06:00","caller":"/Users/thomaslarge/sarama/vendor/github.com/IBM/sarama/sarama.go:129","message":"producer/txnmgr [transaction-id] transaction committed\n"}
Committed transaction:  ProducerTxnStateReady
Starting transaction:  ProducerTxnStateReady
{"level":"debug","time":"2024-04-12T13:14:40-06:00","caller":"/Users/thomaslarge/sarama/vendor/github.com/IBM/sarama/sarama.go:129","message":"txnmgr/transition [transaction-id] transition from ProducerTxnStateReady to ProducerTxnStateInTransaction\n"}
{"level":"debug","time":"2024-04-12T13:14:40-06:00","caller":"/Users/thomaslarge/sarama/vendor/github.com/IBM/sarama/transaction_manager.go:807","message":"txnmgr/add-partition-to-txn retrying after 1ms... (1 attempts remaining) (transaction manager: failed to send partitions to transaction: kafka server: The producer attempted to update a transaction while another concurrent operation on the same transaction was ongoing)\n"}
{"level":"debug","time":"2024-04-12T13:14:40-06:00","caller":"/Users/thomaslarge/sarama/vendor/github.com/IBM/sarama/sarama.go:129","message":"txnmgr/add-partition-to-txn [transaction-id] successful to add partitions txn &{Version:2 ThrottleTime:0s Errors:map[test:[0x14000126928]]}\n"}
{"level":"debug","time":"2024-04-12T13:14:40-06:00","caller":"/Users/thomaslarge/sarama/vendor/github.com/IBM/sarama/sarama.go:129","message":"producer/txnmgr [transaction-id] committing transaction\n"}
{"level":"debug","time":"2024-04-12T13:14:40-06:00","caller":"/Users/thomaslarge/sarama/vendor/github.com/IBM/sarama/sarama.go:129","message":"txnmgr/transition [transaction-id] transition from ProducerTxnStateInTransaction to ProducerTxnStateEndTransaction|ProducerTxnStateCommittingTransaction\n"}
{"level":"debug","time":"2024-04-12T13:14:40-06:00","caller":"/Users/thomaslarge/sarama/vendor/github.com/IBM/sarama/sarama.go:129","message":"txnmgr/endtxn [transaction-id] successful to end txn &{Version:0 ThrottleTime:0s Err:kafka server: Not an error, why are you printing me?}\n"}
{"level":"debug","time":"2024-04-12T13:14:40-06:00","caller":"/Users/thomaslarge/sarama/vendor/github.com/IBM/sarama/sarama.go:129","message":"txnmgr/transition [transaction-id] transition from ProducerTxnStateEndTransaction|ProducerTxnStateCommittingTransaction to ProducerTxnStateReady\n"}
{"level":"debug","time":"2024-04-12T13:14:40-06:00","caller":"/Users/thomaslarge/sarama/vendor/github.com/IBM/sarama/sarama.go:129","message":"producer/txnmgr [transaction-id] transaction committed\n"}
Committed transaction:  ProducerTxnStateReady
Starting transaction:  ProducerTxnStateReady
{"level":"debug","time":"2024-04-12T13:14:40-06:00","caller":"/Users/thomaslarge/sarama/vendor/github.com/IBM/sarama/sarama.go:129","message":"txnmgr/transition [transaction-id] transition from ProducerTxnStateReady to ProducerTxnStateInTransaction\n"}
{"level":"debug","time":"2024-04-12T13:14:40-06:00","caller":"/Users/thomaslarge/sarama/vendor/github.com/IBM/sarama/transaction_manager.go:807","message":"txnmgr/add-partition-to-txn retrying after 1ms... (1 attempts remaining) (transaction manager: failed to send partitions to transaction: kafka server: The producer attempted to update a transaction while another concurrent operation on the same transaction was ongoing)\n"}
{"level":"debug","time":"2024-04-12T13:14:40-06:00","caller":"/Users/thomaslarge/sarama/vendor/github.com/IBM/sarama/sarama.go:129","message":"txnmgr/add-partition-to-txn [transaction-id] successful to add partitions txn &{Version:2 ThrottleTime:0s Errors:map[test:[0x14000126bc8]]}\n"}
{"level":"debug","time":"2024-04-12T13:14:40-06:00","caller":"/Users/thomaslarge/sarama/vendor/github.com/IBM/sarama/sarama.go:129","message":"producer/txnmgr [transaction-id] committing transaction\n"}
{"level":"debug","time":"2024-04-12T13:14:40-06:00","caller":"/Users/thomaslarge/sarama/vendor/github.com/IBM/sarama/sarama.go:129","message":"txnmgr/transition [transaction-id] transition from ProducerTxnStateInTransaction to ProducerTxnStateEndTransaction|ProducerTxnStateCommittingTransaction\n"}
{"level":"debug","time":"2024-04-12T13:14:40-06:00","caller":"/Users/thomaslarge/sarama/vendor/github.com/IBM/sarama/sarama.go:129","message":"txnmgr/endtxn [transaction-id] successful to end txn &{Version:0 ThrottleTime:0s Err:kafka server: Not an error, why are you printing me?}\n"}
{"level":"debug","time":"2024-04-12T13:14:40-06:00","caller":"/Users/thomaslarge/sarama/vendor/github.com/IBM/sarama/sarama.go:129","message":"txnmgr/transition [transaction-id] transition from ProducerTxnStateEndTransaction|ProducerTxnStateCommittingTransaction to ProducerTxnStateReady\n"}
{"level":"debug","time":"2024-04-12T13:14:40-06:00","caller":"/Users/thomaslarge/sarama/vendor/github.com/IBM/sarama/sarama.go:129","message":"producer/txnmgr [transaction-id] transaction committed\n"}
Committed transaction:  ProducerTxnStateReady
Starting transaction:  ProducerTxnStateReady
{"level":"debug","time":"2024-04-12T13:14:40-06:00","caller":"/Users/thomaslarge/sarama/vendor/github.com/IBM/sarama/sarama.go:129","message":"txnmgr/transition [transaction-id] transition from ProducerTxnStateReady to ProducerTxnStateInTransaction\n"}
{"level":"debug","time":"2024-04-12T13:14:40-06:00","caller":"/Users/thomaslarge/sarama/vendor/github.com/IBM/sarama/transaction_manager.go:807","message":"txnmgr/add-partition-to-txn retrying after 1ms... (1 attempts remaining) (transaction manager: failed to send partitions to transaction: kafka server: The producer attempted to update a transaction while another concurrent operation on the same transaction was ongoing)\n"}
{"level":"debug","time":"2024-04-12T13:14:40-06:00","caller":"/Users/thomaslarge/sarama/vendor/github.com/IBM/sarama/sarama.go:129","message":"txnmgr/add-partition-to-txn [transaction-id] successful to add partitions txn &{Version:2 ThrottleTime:0s Errors:map[test:[0x140000aade0]]}\n"}
{"level":"debug","time":"2024-04-12T13:14:40-06:00","caller":"/Users/thomaslarge/sarama/vendor/github.com/IBM/sarama/sarama.go:129","message":"producer/txnmgr [transaction-id] committing transaction\n"}
{"level":"debug","time":"2024-04-12T13:14:40-06:00","caller":"/Users/thomaslarge/sarama/vendor/github.com/IBM/sarama/sarama.go:129","message":"txnmgr/transition [transaction-id] transition from ProducerTxnStateInTransaction to ProducerTxnStateEndTransaction|ProducerTxnStateCommittingTransaction\n"}
{"level":"debug","time":"2024-04-12T13:14:40-06:00","caller":"/Users/thomaslarge/sarama/vendor/github.com/IBM/sarama/sarama.go:129","message":"txnmgr/endtxn [transaction-id] successful to end txn &{Version:0 ThrottleTime:0s Err:kafka server: Not an error, why are you printing me?}\n"}
{"level":"debug","time":"2024-04-12T13:14:40-06:00","caller":"/Users/thomaslarge/sarama/vendor/github.com/IBM/sarama/sarama.go:129","message":"txnmgr/transition [transaction-id] transition from ProducerTxnStateEndTransaction|ProducerTxnStateCommittingTransaction to ProducerTxnStateReady\n"}
{"level":"debug","time":"2024-04-12T13:14:40-06:00","caller":"/Users/thomaslarge/sarama/vendor/github.com/IBM/sarama/sarama.go:129","message":"producer/txnmgr [transaction-id] transaction committed\n"}
Committed transaction:  ProducerTxnStateReady
Starting transaction:  ProducerTxnStateReady
{"level":"debug","time":"2024-04-12T13:14:40-06:00","caller":"/Users/thomaslarge/sarama/vendor/github.com/IBM/sarama/sarama.go:129","message":"txnmgr/transition [transaction-id] transition from ProducerTxnStateReady to ProducerTxnStateInTransaction\n"}
{"level":"debug","time":"2024-04-12T13:14:40-06:00","caller":"/Users/thomaslarge/sarama/vendor/github.com/IBM/sarama/transaction_manager.go:807","message":"txnmgr/add-partition-to-txn retrying after 1ms... (1 attempts remaining) (transaction manager: failed to send partitions to transaction: kafka server: The producer attempted to update a transaction while another concurrent operation on the same transaction was ongoing)\n"}
{"level":"debug","time":"2024-04-12T13:14:40-06:00","caller":"/Users/thomaslarge/sarama/vendor/github.com/IBM/sarama/sarama.go:129","message":"txnmgr/add-partition-to-txn [transaction-id] successful to add partitions txn &{Version:2 ThrottleTime:0s Errors:map[test:[0x140001270d0]]}\n"}
{"level":"debug","time":"2024-04-12T13:14:40-06:00","caller":"/Users/thomaslarge/sarama/vendor/github.com/IBM/sarama/sarama.go:129","message":"producer/txnmgr [transaction-id] committing transaction\n"}
{"level":"debug","time":"2024-04-12T13:14:40-06:00","caller":"/Users/thomaslarge/sarama/vendor/github.com/IBM/sarama/sarama.go:129","message":"txnmgr/transition [transaction-id] transition from ProducerTxnStateInTransaction to ProducerTxnStateEndTransaction|ProducerTxnStateCommittingTransaction\n"}
{"level":"debug","time":"2024-04-12T13:14:40-06:00","caller":"/Users/thomaslarge/sarama/vendor/github.com/IBM/sarama/sarama.go:129","message":"txnmgr/endtxn [transaction-id] successful to end txn &{Version:0 ThrottleTime:0s Err:kafka server: Not an error, why are you printing me?}\n"}
{"level":"debug","time":"2024-04-12T13:14:40-06:00","caller":"/Users/thomaslarge/sarama/vendor/github.com/IBM/sarama/sarama.go:129","message":"txnmgr/transition [transaction-id] transition from ProducerTxnStateEndTransaction|ProducerTxnStateCommittingTransaction to ProducerTxnStateReady\n"}
{"level":"debug","time":"2024-04-12T13:14:40-06:00","caller":"/Users/thomaslarge/sarama/vendor/github.com/IBM/sarama/sarama.go:129","message":"producer/txnmgr [transaction-id] transaction committed\n"}
Committed transaction:  ProducerTxnStateReady
Starting transaction:  ProducerTxnStateReady
{"level":"debug","time":"2024-04-12T13:14:40-06:00","caller":"/Users/thomaslarge/sarama/vendor/github.com/IBM/sarama/sarama.go:129","message":"txnmgr/transition [transaction-id] transition from ProducerTxnStateReady to ProducerTxnStateInTransaction\n"}
{"level":"debug","time":"2024-04-12T13:14:40-06:00","caller":"/Users/thomaslarge/sarama/vendor/github.com/IBM/sarama/transaction_manager.go:807","message":"txnmgr/add-partition-to-txn retrying after 1ms... (1 attempts remaining) (transaction manager: failed to send partitions to transaction: kafka server: The producer attempted to update a transaction while another concurrent operation on the same transaction was ongoing)\n"}
{"level":"debug","time":"2024-04-12T13:14:40-06:00","caller":"/Users/thomaslarge/sarama/vendor/github.com/IBM/sarama/sarama.go:129","message":"txnmgr/add-partition-to-txn [transaction-id] successful to add partitions txn &{Version:2 ThrottleTime:0s Errors:map[test:[0x140001272e8]]}\n"}
{"level":"debug","time":"2024-04-12T13:14:40-06:00","caller":"/Users/thomaslarge/sarama/vendor/github.com/IBM/sarama/sarama.go:129","message":"producer/txnmgr [transaction-id] committing transaction\n"}
{"level":"debug","time":"2024-04-12T13:14:40-06:00","caller":"/Users/thomaslarge/sarama/vendor/github.com/IBM/sarama/sarama.go:129","message":"txnmgr/transition [transaction-id] transition from ProducerTxnStateInTransaction to ProducerTxnStateEndTransaction|ProducerTxnStateCommittingTransaction\n"}
{"level":"debug","time":"2024-04-12T13:14:40-06:00","caller":"/Users/thomaslarge/sarama/vendor/github.com/IBM/sarama/sarama.go:129","message":"txnmgr/endtxn [transaction-id] successful to end txn &{Version:0 ThrottleTime:0s Err:kafka server: Not an error, why are you printing me?}\n"}
{"level":"debug","time":"2024-04-12T13:14:40-06:00","caller":"/Users/thomaslarge/sarama/vendor/github.com/IBM/sarama/sarama.go:129","message":"txnmgr/transition [transaction-id] transition from ProducerTxnStateEndTransaction|ProducerTxnStateCommittingTransaction to ProducerTxnStateReady\n"}
{"level":"debug","time":"2024-04-12T13:14:40-06:00","caller":"/Users/thomaslarge/sarama/vendor/github.com/IBM/sarama/sarama.go:129","message":"producer/txnmgr [transaction-id] transaction committed\n"}
Committed transaction:  ProducerTxnStateReady
Starting transaction:  ProducerTxnStateReady
{"level":"debug","time":"2024-04-12T13:14:40-06:00","caller":"/Users/thomaslarge/sarama/vendor/github.com/IBM/sarama/sarama.go:129","message":"txnmgr/transition [transaction-id] transition from ProducerTxnStateReady to ProducerTxnStateInTransaction\n"}
{"level":"debug","time":"2024-04-12T13:14:40-06:00","caller":"/Users/thomaslarge/sarama/vendor/github.com/IBM/sarama/transaction_manager.go:807","message":"txnmgr/add-partition-to-txn retrying after 1ms... (1 attempts remaining) (transaction manager: failed to send partitions to transaction: kafka server: The producer attempted to update a transaction while another concurrent operation on the same transaction was ongoing)\n"}
{"level":"debug","time":"2024-04-12T13:14:40-06:00","caller":"/Users/thomaslarge/sarama/vendor/github.com/IBM/sarama/transaction_manager.go:807","message":"txnmgr/add-partition-to-txn retrying after 1ms... (0 attempts remaining) (transaction manager: failed to send partitions to transaction: kafka server: The producer attempted to update a transaction while another concurrent operation on the same transaction was ongoing)\n"}
{"level":"debug","time":"2024-04-12T13:14:40-06:00","caller":"/Users/thomaslarge/sarama/vendor/github.com/IBM/sarama/async_producer.go:1192","message":"producer/broker/0 state change to [closing] because transaction manager: failed to send partitions to transaction: kafka server: The producer attempted to update a transaction while another concurrent operation on the same transaction was ongoing\n"}
{"level":"debug","time":"2024-04-12T13:14:40-06:00","caller":"/Users/thomaslarge/sarama/vendor/github.com/IBM/sarama/sarama.go:129","message":"txnmgr/add-partition-to-txn [transaction-id] successful to add partitions txn &{Version:2 ThrottleTime:0s Errors:map[test:[0x140000ab2b0]]}\n"}
{"level":"debug","time":"2024-04-12T13:14:40-06:00","caller":"/Users/thomaslarge/sarama/vendor/github.com/IBM/sarama/sarama.go:129","message":"Closed connection to broker localhost:9092\n"}
{"level":"debug","time":"2024-04-12T13:14:40-06:00","caller":"/Users/thomaslarge/sarama/vendor/github.com/IBM/sarama/sarama.go:129","message":"txnmgr/transition [transaction-id] transition from ProducerTxnStateInTransaction to ProducerTxnStateInError|ProducerTxnStateAbortableError\n"}
{"level":"debug","time":"2024-04-12T13:14:40-06:00","caller":"/Users/thomaslarge/sarama/vendor/github.com/IBM/sarama/sarama.go:129","message":"txnmgr/transition [transaction-id] transition from ProducerTxnStateInError|ProducerTxnStateAbortableError to ProducerTxnStateInError|ProducerTxnStateAbortableError\n"}
{"level":"debug","time":"2024-04-12T13:14:40-06:00","caller":"/Users/thomaslarge/sarama/vendor/github.com/IBM/sarama/sarama.go:129","message":"txnmgr/transition [transaction-id] transition from ProducerTxnStateInError|ProducerTxnStateAbortableError to ProducerTxnStateInError|ProducerTxnStateAbortableError\n"}
{"level":"debug","time":"2024-04-12T13:14:40-06:00","caller":"/Users/thomaslarge/sarama/vendor/github.com/IBM/sarama/sarama.go:129","message":"txnmgr/transition [transaction-id] transition from ProducerTxnStateInError|ProducerTxnStateAbortableError to ProducerTxnStateInError|ProducerTxnStateAbortableError\n"}
{"level":"debug","time":"2024-04-12T13:14:40-06:00","caller":"/Users/thomaslarge/sarama/vendor/github.com/IBM/sarama/sarama.go:129","message":"txnmgr/transition [transaction-id] transition from ProducerTxnStateInError|ProducerTxnStateAbortableError to ProducerTxnStateInError|ProducerTxnStateAbortableError\n"}
{"level":"debug","time":"2024-04-12T13:14:40-06:00","caller":"/Users/thomaslarge/sarama/vendor/github.com/IBM/sarama/sarama.go:129","message":"txnmgr/transition [transaction-id] transition from ProducerTxnStateInError|ProducerTxnStateAbortableError to ProducerTxnStateInError|ProducerTxnStateAbortableError\n"}
{"level":"debug","time":"2024-04-12T13:14:40-06:00","caller":"/Users/thomaslarge/sarama/vendor/github.com/IBM/sarama/sarama.go:129","message":"txnmgr/transition [transaction-id] transition from ProducerTxnStateInError|ProducerTxnStateAbortableError to ProducerTxnStateInError|ProducerTxnStateAbortableError\n"}
{"level":"debug","time":"2024-04-12T13:14:40-06:00","caller":"/Users/thomaslarge/sarama/vendor/github.com/IBM/sarama/sarama.go:129","message":"txnmgr/transition [transaction-id] transition from ProducerTxnStateInError|ProducerTxnStateAbortableError to ProducerTxnStateInError|ProducerTxnStateAbortableError\n"}
{"level":"debug","time":"2024-04-12T13:14:40-06:00","caller":"/Users/thomaslarge/sarama/vendor/github.com/IBM/sarama/sarama.go:129","message":"txnmgr/transition [transaction-id] transition from ProducerTxnStateInError|ProducerTxnStateAbortableError to ProducerTxnStateInError|ProducerTxnStateAbortableError\n"}
{"level":"debug","time":"2024-04-12T13:14:40-06:00","caller":"/Users/thomaslarge/sarama/vendor/github.com/IBM/sarama/sarama.go:129","message":"txnmgr/transition [transaction-id] transition from ProducerTxnStateInError|ProducerTxnStateAbortableError to ProducerTxnStateInError|ProducerTxnStateAbortableError\n"}
{"level":"debug","time":"2024-04-12T13:14:40-06:00","caller":"/Users/thomaslarge/sarama/vendor/github.com/IBM/sarama/sarama.go:129","message":"txnmgr/transition [transaction-id] transition from ProducerTxnStateInError|ProducerTxnStateAbortableError to ProducerTxnStateInError|ProducerTxnStateAbortableError\n"}
{"level":"debug","time":"2024-04-12T13:14:40-06:00","caller":"/Users/thomaslarge/sarama/vendor/github.com/IBM/sarama/sarama.go:129","message":"txnmgr/transition [transaction-id] transition from ProducerTxnStateInError|ProducerTxnStateAbortableError to ProducerTxnStateInError|ProducerTxnStateAbortableError\n"}
{"level":"debug","time":"2024-04-12T13:14:40-06:00","caller":"/Users/thomaslarge/sarama/vendor/github.com/IBM/sarama/sarama.go:129","message":"txnmgr/transition [transaction-id] transition from ProducerTxnStateInError|ProducerTxnStateAbortableError to ProducerTxnStateInError|ProducerTxnStateAbortableError\n"}
{"level":"debug","time":"2024-04-12T13:14:40-06:00","caller":"/Users/thomaslarge/sarama/vendor/github.com/IBM/sarama/sarama.go:129","message":"txnmgr/transition [transaction-id] transition from ProducerTxnStateInError|ProducerTxnStateAbortableError to ProducerTxnStateInError|ProducerTxnStateAbortableError\n"}
{"level":"debug","time":"2024-04-12T13:14:40-06:00","caller":"/Users/thomaslarge/sarama/vendor/github.com/IBM/sarama/sarama.go:129","message":"txnmgr/transition [transaction-id] transition from ProducerTxnStateInError|ProducerTxnStateAbortableError to ProducerTxnStateInError|ProducerTxnStateAbortableError\n"}
{"level":"debug","time":"2024-04-12T13:14:40-06:00","caller":"/Users/thomaslarge/sarama/vendor/github.com/IBM/sarama/sarama.go:129","message":"txnmgr/transition [transaction-id] transition from ProducerTxnStateInError|ProducerTxnStateAbortableError to ProducerTxnStateInError|ProducerTxnStateAbortableError\n"}
{"level":"debug","time":"2024-04-12T13:14:40-06:00","caller":"/Users/thomaslarge/sarama/vendor/github.com/IBM/sarama/sarama.go:129","message":"txnmgr/transition [transaction-id] transition from ProducerTxnStateInError|ProducerTxnStateAbortableError to ProducerTxnStateInError|ProducerTxnStateAbortableError\n"}
{"level":"debug","time":"2024-04-12T13:14:40-06:00","caller":"/Users/thomaslarge/sarama/vendor/github.com/IBM/sarama/sarama.go:129","message":"txnmgr/transition [transaction-id] transition from ProducerTxnStateInError|ProducerTxnStateAbortableError to ProducerTxnStateInError|ProducerTxnStateAbortableError\n"}
{"level":"debug","time":"2024-04-12T13:14:40-06:00","caller":"/Users/thomaslarge/sarama/vendor/github.com/IBM/sarama/sarama.go:129","message":"txnmgr/transition [transaction-id] transition from ProducerTxnStateInError|ProducerTxnStateAbortableError to ProducerTxnStateInError|ProducerTxnStateAbortableError\n"}
{"level":"debug","time":"2024-04-12T13:14:40-06:00","caller":"/Users/thomaslarge/sarama/vendor/github.com/IBM/sarama/sarama.go:129","message":"txnmgr/transition [transaction-id] transition from ProducerTxnStateInError|ProducerTxnStateAbortableError to ProducerTxnStateInError|ProducerTxnStateAbortableError\n"}
{"level":"debug","time":"2024-04-12T13:14:40-06:00","caller":"/Users/thomaslarge/sarama/vendor/github.com/IBM/sarama/sarama.go:129","message":"txnmgr/transition [transaction-id] transition from ProducerTxnStateInError|ProducerTxnStateAbortableError to ProducerTxnStateInError|ProducerTxnStateAbortableError\n"}
{"level":"debug","time":"2024-04-12T13:14:40-06:00","caller":"/Users/thomaslarge/sarama/vendor/github.com/IBM/sarama/sarama.go:129","message":"txnmgr/transition [transaction-id] transition from ProducerTxnStateInError|ProducerTxnStateAbortableError to ProducerTxnStateInError|ProducerTxnStateAbortableError\n"}
{"level":"debug","time":"2024-04-12T13:14:40-06:00","caller":"/Users/thomaslarge/sarama/vendor/github.com/IBM/sarama/sarama.go:129","message":"txnmgr/transition [transaction-id] transition from ProducerTxnStateInError|ProducerTxnStateAbortableError to ProducerTxnStateInError|ProducerTxnStateAbortableError\n"}
{"level":"debug","time":"2024-04-12T13:14:40-06:00","caller":"/Users/thomaslarge/sarama/vendor/github.com/IBM/sarama/sarama.go:129","message":"txnmgr/transition [transaction-id] transition from ProducerTxnStateInError|ProducerTxnStateAbortableError to ProducerTxnStateInError|ProducerTxnStateAbortableError\n"}
{"level":"debug","time":"2024-04-12T13:14:40-06:00","caller":"/Users/thomaslarge/sarama/vendor/github.com/IBM/sarama/sarama.go:129","message":"txnmgr/transition [transaction-id] transition from ProducerTxnStateInError|ProducerTxnStateAbortableError to ProducerTxnStateInError|ProducerTxnStateAbortableError\n"}
{"level":"debug","time":"2024-04-12T13:14:40-06:00","caller":"/Users/thomaslarge/sarama/vendor/github.com/IBM/sarama/sarama.go:129","message":"txnmgr/transition [transaction-id] transition from ProducerTxnStateInError|ProducerTxnStateAbortableError to ProducerTxnStateInError|ProducerTxnStateAbortableError\n"}
{"level":"debug","time":"2024-04-12T13:14:40-06:00","caller":"/Users/thomaslarge/sarama/vendor/github.com/IBM/sarama/sarama.go:129","message":"txnmgr/transition [transaction-id] transition from ProducerTxnStateInError|ProducerTxnStateAbortableError to ProducerTxnStateInError|ProducerTxnStateAbortableError\n"}
{"level":"debug","time":"2024-04-12T13:14:40-06:00","caller":"/Users/thomaslarge/sarama/vendor/github.com/IBM/sarama/sarama.go:129","message":"txnmgr/transition [transaction-id] transition from ProducerTxnStateInError|ProducerTxnStateAbortableError to ProducerTxnStateInError|ProducerTxnStateAbortableError\n"}
{"level":"debug","time":"2024-04-12T13:14:40-06:00","caller":"/Users/thomaslarge/sarama/vendor/github.com/IBM/sarama/sarama.go:129","message":"txnmgr/transition [transaction-id] transition from ProducerTxnStateInError|ProducerTxnStateAbortableError to ProducerTxnStateInError|ProducerTxnStateAbortableError\n"}
{"level":"debug","time":"2024-04-12T13:14:40-06:00","caller":"/Users/thomaslarge/sarama/vendor/github.com/IBM/sarama/sarama.go:129","message":"txnmgr/transition [transaction-id] transition from ProducerTxnStateInError|ProducerTxnStateAbortableError to ProducerTxnStateInError|ProducerTxnStateAbortableError\n"}
{"level":"debug","time":"2024-04-12T13:14:40-06:00","caller":"/Users/thomaslarge/sarama/vendor/github.com/IBM/sarama/sarama.go:129","message":"txnmgr/transition [transaction-id] transition from ProducerTxnStateInError|ProducerTxnStateAbortableError to ProducerTxnStateInError|ProducerTxnStateAbortableError\n"}
{"level":"debug","time":"2024-04-12T13:14:40-06:00","caller":"/Users/thomaslarge/sarama/vendor/github.com/IBM/sarama/sarama.go:129","message":"txnmgr/transition [transaction-id] transition from ProducerTxnStateInError|ProducerTxnStateAbortableError to ProducerTxnStateInError|ProducerTxnStateAbortableError\n"}
{"level":"debug","time":"2024-04-12T13:14:40-06:00","caller":"/Users/thomaslarge/sarama/vendor/github.com/IBM/sarama/sarama.go:129","message":"txnmgr/transition [transaction-id] transition from ProducerTxnStateInError|ProducerTxnStateAbortableError to ProducerTxnStateInError|ProducerTxnStateAbortableError\n"}
{"level":"debug","time":"2024-04-12T13:14:40-06:00","caller":"/Users/thomaslarge/sarama/vendor/github.com/IBM/sarama/sarama.go:129","message":"txnmgr/transition [transaction-id] transition from ProducerTxnStateInError|ProducerTxnStateAbortableError to ProducerTxnStateInError|ProducerTxnStateAbortableError\n"}
{"level":"debug","time":"2024-04-12T13:14:40-06:00","caller":"/Users/thomaslarge/sarama/vendor/github.com/IBM/sarama/sarama.go:129","message":"txnmgr/transition [transaction-id] transition from ProducerTxnStateInError|ProducerTxnStateAbortableError to ProducerTxnStateInError|ProducerTxnStateAbortableError\n"}
{"level":"debug","time":"2024-04-12T13:14:40-06:00","caller":"/Users/thomaslarge/sarama/vendor/github.com/IBM/sarama/sarama.go:129","message":"txnmgr/transition [transaction-id] transition from ProducerTxnStateInError|ProducerTxnStateAbortableError to ProducerTxnStateInError|ProducerTxnStateAbortableError\n"}
{"level":"debug","time":"2024-04-12T13:14:40-06:00","caller":"/Users/thomaslarge/sarama/vendor/github.com/IBM/sarama/sarama.go:129","message":"txnmgr/transition [transaction-id] transition from ProducerTxnStateInError|ProducerTxnStateAbortableError to ProducerTxnStateInError|ProducerTxnStateAbortableError\n"}
{"level":"debug","time":"2024-04-12T13:14:40-06:00","caller":"/Users/thomaslarge/sarama/vendor/github.com/IBM/sarama/sarama.go:129","message":"txnmgr/transition [transaction-id] transition from ProducerTxnStateInError|ProducerTxnStateAbortableError to ProducerTxnStateInError|ProducerTxnStateAbortableError\n"}
{"level":"debug","time":"2024-04-12T13:14:40-06:00","caller":"/Users/thomaslarge/sarama/vendor/github.com/IBM/sarama/sarama.go:129","message":"txnmgr/transition [transaction-id] transition from ProducerTxnStateInError|ProducerTxnStateAbortableError to ProducerTxnStateInError|ProducerTxnStateAbortableError\n"}
{"level":"debug","time":"2024-04-12T13:14:40-06:00","caller":"/Users/thomaslarge/sarama/vendor/github.com/IBM/sarama/sarama.go:129","message":"txnmgr/transition [transaction-id] transition from ProducerTxnStateInError|ProducerTxnStateAbortableError to ProducerTxnStateInError|ProducerTxnStateAbortableError\n"}
{"level":"debug","time":"2024-04-12T13:14:40-06:00","caller":"/Users/thomaslarge/sarama/vendor/github.com/IBM/sarama/sarama.go:129","message":"txnmgr/transition [transaction-id] transition from ProducerTxnStateInError|ProducerTxnStateAbortableError to ProducerTxnStateInError|ProducerTxnStateAbortableError\n"}
{"level":"debug","time":"2024-04-12T13:14:40-06:00","caller":"/Users/thomaslarge/sarama/vendor/github.com/IBM/sarama/sarama.go:129","message":"txnmgr/transition [transaction-id] transition from ProducerTxnStateInError|ProducerTxnStateAbortableError to ProducerTxnStateInError|ProducerTxnStateAbortableError\n"}
{"level":"debug","time":"2024-04-12T13:14:40-06:00","caller":"/Users/thomaslarge/sarama/vendor/github.com/IBM/sarama/sarama.go:129","message":"txnmgr/transition [transaction-id] transition from ProducerTxnStateInError|ProducerTxnStateAbortableError to ProducerTxnStateInError|ProducerTxnStateAbortableError\n"}
{"level":"debug","time":"2024-04-12T13:14:40-06:00","caller":"/Users/thomaslarge/sarama/vendor/github.com/IBM/sarama/sarama.go:129","message":"txnmgr/transition [transaction-id] transition from ProducerTxnStateInError|ProducerTxnStateAbortableError to ProducerTxnStateInError|ProducerTxnStateAbortableError\n"}
{"level":"debug","time":"2024-04-12T13:14:40-06:00","caller":"/Users/thomaslarge/sarama/vendor/github.com/IBM/sarama/sarama.go:129","message":"txnmgr/transition [transaction-id] transition from ProducerTxnStateInError|ProducerTxnStateAbortableError to ProducerTxnStateInError|ProducerTxnStateAbortableError\n"}
{"level":"debug","time":"2024-04-12T13:14:40-06:00","caller":"/Users/thomaslarge/sarama/vendor/github.com/IBM/sarama/sarama.go:129","message":"txnmgr/transition [transaction-id] transition from ProducerTxnStateInError|ProducerTxnStateAbortableError to ProducerTxnStateInError|ProducerTxnStateAbortableError\n"}
{"level":"debug","time":"2024-04-12T13:14:40-06:00","caller":"/Users/thomaslarge/sarama/vendor/github.com/IBM/sarama/sarama.go:129","message":"txnmgr/transition [transaction-id] transition from ProducerTxnStateInError|ProducerTxnStateAbortableError to ProducerTxnStateInError|ProducerTxnStateAbortableError\n"}
{"level":"debug","time":"2024-04-12T13:14:40-06:00","caller":"/Users/thomaslarge/sarama/vendor/github.com/IBM/sarama/sarama.go:129","message":"txnmgr/transition [transaction-id] transition from ProducerTxnStateInError|ProducerTxnStateAbortableError to ProducerTxnStateInError|ProducerTxnStateAbortableError\n"}
{"level":"debug","time":"2024-04-12T13:14:40-06:00","caller":"/Users/thomaslarge/sarama/vendor/github.com/IBM/sarama/sarama.go:129","message":"txnmgr/transition [transaction-id] transition from ProducerTxnStateInError|ProducerTxnStateAbortableError to ProducerTxnStateInError|ProducerTxnStateAbortableError\n"}
{"level":"debug","time":"2024-04-12T13:14:40-06:00","caller":"/Users/thomaslarge/sarama/vendor/github.com/IBM/sarama/async_producer.go:711","message":"producer/leader/test/0 state change to [retrying-1]\n"}
{"level":"debug","time":"2024-04-12T13:14:40-06:00","caller":"/Users/thomaslarge/sarama/vendor/github.com/IBM/sarama/async_producer.go:721","message":"producer/leader/test/0 abandoning broker 0\n"}
{"level":"debug","time":"2024-04-12T13:14:40-06:00","caller":"/Users/thomaslarge/sarama/vendor/github.com/IBM/sarama/async_producer.go:920","message":"producer/broker/0 input chan closed\n"}
{"level":"debug","time":"2024-04-12T13:14:40-06:00","caller":"/Users/thomaslarge/sarama/vendor/github.com/IBM/sarama/async_producer.go:1020","message":"producer/broker/0 shut down\n"}
{"level":"debug","time":"2024-04-12T13:14:40-06:00","caller":"/Users/thomaslarge/sarama/vendor/github.com/IBM/sarama/sarama.go:129","message":"client/metadata fetching metadata for [test] from broker localhost:9092\n"}
{"level":"debug","time":"2024-04-12T13:14:40-06:00","caller":"/Users/thomaslarge/sarama/vendor/github.com/IBM/sarama/sarama.go:129","message":"Connected to broker at localhost:9092 (registered as #0)\n"}
{"level":"debug","time":"2024-04-12T13:14:40-06:00","caller":"/Users/thomaslarge/sarama/vendor/github.com/IBM/sarama/async_producer.go:914","message":"producer/broker/0 starting up\n"}
{"level":"debug","time":"2024-04-12T13:14:40-06:00","caller":"/Users/thomaslarge/sarama/vendor/github.com/IBM/sarama/async_producer.go:930","message":"producer/broker/0 state change to [open] on test/0\n"}
{"level":"debug","time":"2024-04-12T13:14:40-06:00","caller":"/Users/thomaslarge/sarama/vendor/github.com/IBM/sarama/async_producer.go:624","message":"producer/leader/test/0 selected broker 0\n"}
{"level":"debug","time":"2024-04-12T13:14:40-06:00","caller":"/Users/thomaslarge/sarama/vendor/github.com/IBM/sarama/async_producer.go:727","message":"producer/leader/test/0 state change to [flushing-1]\n"}
{"level":"debug","time":"2024-04-12T13:14:40-06:00","caller":"/Users/thomaslarge/sarama/vendor/github.com/IBM/sarama/async_producer.go:749","message":"producer/leader/test/0 state change to [normal]\n"}
{"level":"debug","time":"2024-04-12T13:14:40-06:00","caller":"/Users/thomaslarge/sarama/vendor/github.com/IBM/sarama/async_producer.go:1192","message":"producer/broker/0 state change to [closing] because kafka server: The broker received an out of order sequence number\n"}
{"level":"debug","time":"2024-04-12T13:14:40-06:00","caller":"/Users/thomaslarge/sarama/vendor/github.com/IBM/sarama/sarama.go:129","message":"Closed connection to broker localhost:9092\n"}
{"level":"debug","time":"2024-04-12T13:14:40-06:00","caller":"/Users/thomaslarge/sarama/vendor/github.com/IBM/sarama/async_producer.go:711","message":"producer/leader/test/0 state change to [retrying-2]\n"}
{"level":"debug","time":"2024-04-12T13:14:40-06:00","caller":"/Users/thomaslarge/sarama/vendor/github.com/IBM/sarama/async_producer.go:721","message":"producer/leader/test/0 abandoning broker 0\n"}
{"level":"debug","time":"2024-04-12T13:14:40-06:00","caller":"/Users/thomaslarge/sarama/vendor/github.com/IBM/sarama/async_producer.go:920","message":"producer/broker/0 input chan closed\n"}
{"level":"debug","time":"2024-04-12T13:14:40-06:00","caller":"/Users/thomaslarge/sarama/vendor/github.com/IBM/sarama/async_producer.go:1020","message":"producer/broker/0 shut down\n"}
{"level":"debug","time":"2024-04-12T13:14:40-06:00","caller":"/Users/thomaslarge/sarama/vendor/github.com/IBM/sarama/sarama.go:129","message":"client/metadata fetching metadata for [test] from broker localhost:9092\n"}
{"level":"debug","time":"2024-04-12T13:14:40-06:00","caller":"/Users/thomaslarge/sarama/vendor/github.com/IBM/sarama/sarama.go:129","message":"Connected to broker at localhost:9092 (registered as #0)\n"}
{"level":"debug","time":"2024-04-12T13:14:40-06:00","caller":"/Users/thomaslarge/sarama/vendor/github.com/IBM/sarama/async_producer.go:914","message":"producer/broker/0 starting up\n"}
{"level":"debug","time":"2024-04-12T13:14:40-06:00","caller":"/Users/thomaslarge/sarama/vendor/github.com/IBM/sarama/async_producer.go:930","message":"producer/broker/0 state change to [open] on test/0\n"}
{"level":"debug","time":"2024-04-12T13:14:40-06:00","caller":"/Users/thomaslarge/sarama/vendor/github.com/IBM/sarama/async_producer.go:624","message":"producer/leader/test/0 selected broker 0\n"}
{"level":"debug","time":"2024-04-12T13:14:40-06:00","caller":"/Users/thomaslarge/sarama/vendor/github.com/IBM/sarama/async_producer.go:727","message":"producer/leader/test/0 state change to [flushing-2]\n"}
{"level":"debug","time":"2024-04-12T13:14:40-06:00","caller":"/Users/thomaslarge/sarama/vendor/github.com/IBM/sarama/async_producer.go:749","message":"producer/leader/test/0 state change to [normal]\n"}
{"level":"debug","time":"2024-04-12T13:14:40-06:00","caller":"/Users/thomaslarge/sarama/vendor/github.com/IBM/sarama/async_producer.go:1192","message":"producer/broker/0 state change to [closing] because kafka server: The broker received an out of order sequence number\n"}
{"level":"debug","time":"2024-04-12T13:14:40-06:00","caller":"/Users/thomaslarge/sarama/vendor/github.com/IBM/sarama/sarama.go:129","message":"Closed connection to broker localhost:9092\n"}
{"level":"debug","time":"2024-04-12T13:14:40-06:00","caller":"/Users/thomaslarge/sarama/vendor/github.com/IBM/sarama/async_producer.go:711","message":"producer/leader/test/0 state change to [retrying-3]\n"}
{"level":"debug","time":"2024-04-12T13:14:40-06:00","caller":"/Users/thomaslarge/sarama/vendor/github.com/IBM/sarama/async_producer.go:721","message":"producer/leader/test/0 abandoning broker 0\n"}
{"level":"debug","time":"2024-04-12T13:14:40-06:00","caller":"/Users/thomaslarge/sarama/vendor/github.com/IBM/sarama/async_producer.go:920","message":"producer/broker/0 input chan closed\n"}
{"level":"debug","time":"2024-04-12T13:14:40-06:00","caller":"/Users/thomaslarge/sarama/vendor/github.com/IBM/sarama/async_producer.go:1020","message":"producer/broker/0 shut down\n"}
{"level":"debug","time":"2024-04-12T13:14:40-06:00","caller":"/Users/thomaslarge/sarama/vendor/github.com/IBM/sarama/sarama.go:129","message":"client/metadata fetching metadata for [test] from broker localhost:9092\n"}
{"level":"debug","time":"2024-04-12T13:14:40-06:00","caller":"/Users/thomaslarge/sarama/vendor/github.com/IBM/sarama/sarama.go:129","message":"Connected to broker at localhost:9092 (registered as #0)\n"}
{"level":"debug","time":"2024-04-12T13:14:40-06:00","caller":"/Users/thomaslarge/sarama/vendor/github.com/IBM/sarama/async_producer.go:914","message":"producer/broker/0 starting up\n"}
{"level":"debug","time":"2024-04-12T13:14:40-06:00","caller":"/Users/thomaslarge/sarama/vendor/github.com/IBM/sarama/async_producer.go:930","message":"producer/broker/0 state change to [open] on test/0\n"}
{"level":"debug","time":"2024-04-12T13:14:40-06:00","caller":"/Users/thomaslarge/sarama/vendor/github.com/IBM/sarama/async_producer.go:624","message":"producer/leader/test/0 selected broker 0\n"}
{"level":"debug","time":"2024-04-12T13:14:40-06:00","caller":"/Users/thomaslarge/sarama/vendor/github.com/IBM/sarama/async_producer.go:727","message":"producer/leader/test/0 state change to [flushing-3]\n"}
{"level":"debug","time":"2024-04-12T13:14:40-06:00","caller":"/Users/thomaslarge/sarama/vendor/github.com/IBM/sarama/async_producer.go:749","message":"producer/leader/test/0 state change to [normal]\n"}
{"level":"debug","time":"2024-04-12T13:14:40-06:00","caller":"/Users/thomaslarge/sarama/vendor/github.com/IBM/sarama/async_producer.go:1192","message":"producer/broker/0 state change to [closing] because kafka server: The broker received an out of order sequence number\n"}
{"level":"debug","time":"2024-04-12T13:14:40-06:00","caller":"/Users/thomaslarge/sarama/vendor/github.com/IBM/sarama/sarama.go:129","message":"Closed connection to broker localhost:9092\n"}
{"level":"debug","time":"2024-04-12T13:14:40-06:00","caller":"/Users/thomaslarge/sarama/vendor/github.com/IBM/sarama/sarama.go:129","message":"txnmgr/transition [transaction-id] transition from ProducerTxnStateInError|ProducerTxnStateAbortableError to ProducerTxnStateInError|ProducerTxnStateAbortableError\n"}
{"level":"debug","time":"2024-04-12T13:14:40-06:00","caller":"/Users/thomaslarge/sarama/vendor/github.com/IBM/sarama/sarama.go:129","message":"producer/txnmgr [transaction-id] aborting transaction\n"}
{"level":"debug","time":"2024-04-12T13:14:40-06:00","caller":"/Users/thomaslarge/sarama/vendor/github.com/IBM/sarama/sarama.go:129","message":"txnmgr/transition [transaction-id] transition from ProducerTxnStateInError|ProducerTxnStateAbortableError to ProducerTxnStateEndTransaction|ProducerTxnStateAbortingTransaction\n"}
{"level":"debug","time":"2024-04-12T13:14:40-06:00","caller":"/Users/thomaslarge/sarama/vendor/github.com/IBM/sarama/sarama.go:129","message":"Connected to broker at localhost:9092 (registered as #0)\n"}
{"level":"debug","time":"2024-04-12T13:14:40-06:00","caller":"/Users/thomaslarge/sarama/vendor/github.com/IBM/sarama/sarama.go:129","message":"txnmgr/endtxn [transaction-id] successful to end txn &{Version:0 ThrottleTime:0s Err:kafka server: Not an error, why are you printing me?}\n"}
{"level":"debug","time":"2024-04-12T13:14:40-06:00","caller":"/Users/thomaslarge/sarama/vendor/github.com/IBM/sarama/sarama.go:129","message":"txnmgr/transition [transaction-id] transition from ProducerTxnStateEndTransaction|ProducerTxnStateAbortingTransaction to ProducerTxnStateInitializing\n"}
{"level":"debug","time":"2024-04-12T13:14:40-06:00","caller":"/Users/thomaslarge/sarama/vendor/github.com/IBM/sarama/sarama.go:129","message":"txnmgr/transition [transaction-id] transition from ProducerTxnStateInitializing to ProducerTxnStateInitializing\n"}
{"level":"debug","time":"2024-04-12T13:14:40-06:00","caller":"/Users/thomaslarge/sarama/vendor/github.com/IBM/sarama/sarama.go:129","message":"txnmgr/init-producer-id [transaction-id] invoking InitProducerId for the first time in order to acquire a producer ID\n"}
{"level":"debug","time":"2024-04-12T13:14:40-06:00","caller":"/Users/thomaslarge/sarama/vendor/github.com/IBM/sarama/sarama.go:129","message":"txnmgr/transition [transaction-id] transition from ProducerTxnStateInitializing to ProducerTxnStateInError|ProducerTxnStateFatalError\n"}
AbortTxn:  kafka server: The producer attempted to update a transaction while another concurrent operation on the same transaction was ongoing
panic: SendMessages: kafka: Failed to deliver 50 messages.

goroutine 1 [running]:
main.main()
	/Users/thomaslarge/sarama/cmd/test/main.go:57 +0x6a4
exit status 2

Additional Context
Here is the program
package main

import (
	"context"
	"fmt"
	"os"
	"os/signal"
	"syscall"
	"time"

	"github.com/IBM/sarama"
	"github.com/rs/zerolog/log"
)

func main() {
	logger := log.With().Caller().Logger()
	sarama.Logger = &logger

	producer, err := sarama.NewSyncProducer([]string{"localhost:9092"}, newConfig())
	if err != nil {
		panic(fmt.Sprintf("NewSyncProducer: %s", err.Error()))
	}
	defer func() {
		if producer.TxnStatus()&sarama.ProducerTxnFlagAbortableError != 0 {
			err = producer.AbortTxn()
			if err != nil {
				fmt.Println("AbortTxn: ", err.Error())
			}
		}
	}()

	signals := []os.Signal{syscall.SIGHUP, syscall.SIGINT, syscall.SIGTERM, syscall.SIGQUIT, syscall.SIGKILL}
	ctx, cancel := signal.NotifyContext(context.Background(), signals...)
        defer cancel()

	messages := make([]*sarama.ProducerMessage, 0)
	for i := 0; i < 50; i++ {
		messages = append(messages, &sarama.ProducerMessage{
			Topic: "test",
		})
	}

	sleepTime := 0 * time.Millisecond
	for {
		select {
		case <-ctx.Done():
			return
		default:
			fmt.Println("Starting transaction: ", producer.TxnStatus())

			err = producer.BeginTxn()
			if err != nil {
				panic(fmt.Sprintf("BeginTxn: %s", err.Error()))
			}

			err = producer.SendMessages(messages)
			if err != nil {
				panic(fmt.Sprintf("SendMessages: %s", err.Error()))
			}

			err = producer.CommitTxn()
			if err != nil {
				panic(fmt.Sprintf("CommitTxn: %s", err.Error()))
			}

			fmt.Println("Committed transaction: ", producer.TxnStatus())
		}

		time.Sleep(sleepTime)
	}
}

func newConfig() *sarama.Config {
	config := sarama.NewConfig()
	config.Version = sarama.V3_6_0_0
	config.ClientID = "client-id"

	config.Producer.RequiredAcks = sarama.WaitForAll
	config.Producer.Transaction.Retry.Max = 1
	config.Producer.Transaction.Retry.Backoff = 1 * time.Millisecond
	config.Producer.Return.Errors = true
	config.Producer.Return.Successes = true
	config.Producer.Idempotent = true
	config.Net.MaxOpenRequests = 1
	config.Producer.Timeout = 1 * time.Minute
	config.Producer.Transaction.ID = "transaction-id"

	return config
}

@tomplarge thanks for raising this one. When we commit the transaction, the txnmgr/endtxn request is sent to the coordinator, which writes a PrepareCommit message to the transaction log and then returns the response to us. However, it the final 'CompleteCommit' message is written asynchronously so there is a timing windows if you immediately try to use the transaction again then you get the Errors.CONCURRENT_TRANSACTIONS response back.
The Java client just treats this as a retriable error and tries again after a backoff (see here) so we should probably make sure we're doing the same

Ah, I just spotted your Retry.Max = 1 and Retry.Backoff = 1 * time.Millisecond, so that's probably why the existing Retry code isn't working for you here
https://github.com/IBM/sarama/blob/4ad35041300e1c15ba58b630745ac8eb05f30c10/transaction_manager.go#L359-L360

@dnwe thanks for the response! I also ran the exactly once example and noticed it had the same issue when debug logging was enabled. The exactly once example suggests that retrying in application logic is recommended (https://github.com/IBM/sarama/blob/main/examples/exactly_once/main.go#L295). So are you saying that the way to handle this is just to be more generous with Retry.Max and Retry.Backoff as well as in application logic for retrying the desired operation? If so, what are reasonable values for these configurations?
As an aside, in an optimal world, would it not make more sense to enforce synchronous behavior when committing a transaction? I'm curious what your thoughts are here.

@tomplarge yeah I agree it shouldn't be async, ideally we wouldn't get the response from the Commit until it had 100% completed server side, but that async behaviour seems to be a bit of a nit in the Kafka code ever since the transactional producer was introduced in 0.11.0 rather than a mistake Sarama is making, and something they were just happy to hide away in the client retries
See KAFKA-5477 where the 'transaction in progress' retry backoff was special cased to be shorter than the regular backoff specifically because the client can seemingly always get the in progress on the first attempt

@dnwe this is great to know, thanks for pointing out that issue entry. I'll do some reconfiguring and more flexible retry logic. The larger question I have is at what point do we actually fail on the application side? For example, during a rebalance, I have noticed this error spewing from the fenced producers: Error: Unknown error, how did this happen? Error code = 90. Error code 90 corresponds to PRODUCER_FENCED, but this error is not resolvable after any number of retries. How should this be handled? Does this scenario break any part of exactly-once guarantees?

Same problem here.

https://github.com/IBM/sarama/discussions/2912#discussioncomment-9555131


CPU only inference

Hi
Is there a proper setting to use cpu only inference?
I tried changing device setting at run_styleid.py, but seems some other tensor is still using gpu
RuntimeError: Expected all tensors to be on the same device, but found at least two devices, cpu and cuda:0! (when checking argument for argument index in method wrapper__index_select)

solved


Update non-english documentation/use Hugo's builtin i18n system for docs

Gitea version (or commit ref):

[x] Not relevant

Description
Hi, as discussed in https://github.com/go-gitea/gitea/pull/6348, gitea documentation in french language (and probably others) is outdated. As most of the work happens on the english documentation (example recent patch) docs in other languages quickly fall out of date (missing or inaccurate sections) with no indication.
Hugo is used to build the documentation at https://docs.gitea.io/, and Hugo's multilingual feature can manage translations of strings and replaces missing strings with the default language string
Example:
docs/content/doc/installation/from-binary.en-us.md:
{{ i18n "install_readonly" }}

docs/themes/gitea/i18n/en-us.toml:
[install_readonly]
other = "If you don't want the web installer to be able to write the config file at all, it is also possible to make the config file read-only for the gitea user (owner/group `root:root`, mode `0660`), and set `INSTALL_LOCK = true`. In that case all database configuration details must be set beforehand in the config file, as well as the `SECRET_KEY` and `INTERNAL_TOKEN` values. See the [command line documentation]({{< relref "doc/usage/command-line.en-us.md" >}}) for information on using `gitea generate secret INTERNAL_TOKEN`."

docs/themes/gitea/i18n/fr-fr.toml:
[install_readonly]
other = "Si vous ne souhaitez pas que l'installeur puisse écrire dans le fichier de configuration, il est possible de placer le fichier de config en lecture seul pour l'utilisateur gitea (utilisateur/group `root:root`, mode `0660`), et de définir `INSTALL_LOCK = true`. Dans ce cas les détails de configuration doivent être définis d'avance dans le fichier de config, ainsi que les valeurs `SECRET_KEY` and `INTERNAL_TOKEN`. Voir la documentation sur la [ligne de commande]({{< relref "doc/usage/command-line.fr-.md" >}}) pour des informations sur l'utilisation de  `gitea generate secret INTERNAL_TOKEN`."

This change would require converting converting current .md page contents (in all languages) to .toml. I would be happy to help on french docs but I understand most languages would need to be redone...
This would fix the "page is outdated but there is no warning" problem. An (easier but less clean) alternative is manually adding a warning banner on outdated localized pages.
Edit: It would allow managing documentation from Crowdin along with the main gitea localization.

I would be very happy if we had proper internationalised docs. I have one reservation though, anything that makes writing documentation harder may mean that it doesn't happen.
Is there any way to automate the conversion from a say a normal md to an internationalised toml? Then we get the benefit of easy to write documentation with internationalisation?

@nodiscc currently we also implemented that with some scripts and didn't use builtin i18n. Why we should convert to builtin i18n?

@nodiscc currently we also implemented that with some scripts and didn't use builtin i18n. Why we should convert to builtin i18n?

Regarding difficulty of writing documentation: using builtin i18n would allow managing the translations through Crowdin which looks easy to use for translators (difficulty on par  with the current process, fork the repo, update markdown, sen a pull request...)

Is there any way to automate the conversion from a say a normal md to an internationalised toml?

In the current state I think the translated docs would have to be deleted, and a translation from scratch from en-US docs would have to be started (there is too much divergence).

Why we should convert to builtin i18n?

It prevents localized pages from lagging behind the english docs

If an english paragraph changes, corresponding localized paragraphs are marked as untranslated and displayed in their complete form in english (instead of just staying partial, translated info without warnings).
If an english paragraph is added, it is also added (in english) to localized pages (instead of the page just remaining incomplete)

It allows translators to use the same workflow as the rest of Gitea localization.

@nodiscc I don't think you understood me.
Writing translatable strings in code is a non-trivial task. It involves abstracting your strings out to a label codename and keeping the variables separate until you reach the UI layer whereupon you produce a human readable string. Every time you want to change anything you need to change it in two places - one of which is semantically unrelated to the code you're editing, (tooling of course should help but go doesn't appear to have very good ide tooling for this.) Coming up with a good label for the translations is also non-trivial.
Now if you are suggesting that when we write documentation - a task which many people find difficult to remember to do, presumably because not only is its position outside of the code, but also is difficult in its own right - we have to do a similar game then that's not ideal. We need to choose a mechanism that is as easy as possible for a documenter because otherwise it won't happen.

Setup trans to use 2 stage pipeline

Google translator
Human translator

This cuts the work by 90% in keeping translations up to date.
You really don't need crowdin.
We used it but it was much easier with Hugo to use a basic pipeline.
Each page of the we site has a link to open the same data inside the git repo.
The user just working on their own branch and then pushes a or via the GUI.
That's all you need

Every time you want to change anything you need to change it in two places - one of which is semantically unrelated to the code you're editing,

@zeripath You are right. My solution is not ideal.
@gedw99 How would that work?

Setup trans to use 2 stage pipeline

I imagine you meant Travis CI. Travis would detect in a Pull Request that it affects the documentation, run a machine translation for all languages on the diff, and attach the output to the PR comments? Then the output would have to be reviewed manually by a translator for each language, and added to the Pull Request? This looks tedious too.

@gedw99 right. Good idea. We could also add automatically translations on some step of drone before uploading it to crowdin. That should reduce many translation operations. Anyone know any drone plugin could do that?

You can use Ci but you will need to code up some basic stuff too.

You MUST have a cache that is file based, not DB based.
File based allows the git and CI system to be able to see changes and drive the notifications.

This is so you get to run the whole trans process and if the cache has a record you use that, and if not you hit  google tran.
likewise at the human stage, if the user finds a mistake in the google trans, then when they fix it, the system must update the cache.

Setup google tran

https://github.com/bregydoc/gtranslate

Setup a email notification for human so they knwo when work is needed

Now the Human stage

You know what fresh machine translated and the humans check this
If they correct a machine trans, it must update the cache

Hope this is making some sense. It pretty simple really.
I have been using this. It solves the i10n stuff like dates, currencies, etc etc etc.
Its uses ARB, which i really like as its very concise. Other formats are creaking old and highly verbose.
The way Plurals work with ARB is very concise for example.
This use protobufs to handle that messy stuff and codegens the golang and Dart code for everything needed at runtime. HUGO can also use this !!!
https://github.com/empirefox/protoc-gen-dart-ext/blob/master/Makefile

@lunny
I have setup a repo here to do it.
https://github.com/joeblew99/gitea-trans
I need to add a few more bits and docs to show how it works

This looks like something hard to implement correctly, so the issue might as well be closed for the moment.
I still recommend that you include a short banner at the beginning of every translated page. Some of them were badly out of date, and it will confuse users trying to follow old setup procedures, trying to find info on recent features etc
Cheers


Update pipeline nodejs

Node.js 12 actions are deprecated. For more information see: https://github.blog/changelog/2022-09-22-github-actions-all-actions-will-begin-running-on-node16-instead-of-node12/. Please update the following actions to use Node.js 16: actions/setup-node@v1

Fixed in https://github.com/XenitAB/xenitab.github.io/pull/170


Implement hide method.

I've tried to use your repo but I can't get done, because I see it related to ionic-native plugin. Could you help me to guide how to use?
Thanks & Best regards,


For

Hi team,
In this document:
https://docs.microsoft.com/en-us/azure/azure-monitor/logs/logs-data-export?tabs=portal#:~:text=InsightsMetrics
It mentioned for insightsmetrics table:
InsightsMetrics	Partial support – some of the data is ingested through internal services that aren't supported in export. This portion is missing in export currently.
However per my test there is no field lost after export to storage account. Could you please help confirm which part not support to export? Thanks!

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 5daf3365-76b8-b98f-7fc8-51f520e6276b
Version Independent ID: 93a216a6-fd66-cc0a-9346-58955bd0a7ba
Content: Log Analytics workspace data export in Azure Monitor - Azure Monitor
Content Source: articles/azure-monitor/logs/logs-data-export.md
Service: azure-monitor
Sub-service: logs
GitHub Login: @yossi-y
Microsoft Alias: yossiy

@xuegao112 Thanks for your feedback.
Assigning to content author @yossi-y  for review.

Hello,
Data export is supported in the Azure Monitor pipeline, while there are flows that are yet through the old pipeline. InsightsMetrics has two flows and it might be that your data is exported in full. I believe that the other flow to InsightsMetrics is related to ServiceMap, and if you aren’t using it, your data is complete.
thanks,

@xuegao112 thanks for your inquiry! I'm closing this issue. Please reopen if you need additional information.
#please-close


Failed to load the atom-python-run package

[Enter steps to reproduce:]

...
...

Atom: 1.31.1 x64
Electron: 2.0.7
OS: Microsoft Windows 10 Home
Thrown From: atom-python-run package 0.9.7
Stack Trace
Failed to load the atom-python-run package
At Unexpected token a in JSON at position 1

SyntaxError: Unexpected token a in JSON at position 1
    at JSON.parse (<anonymous>)
    at parseObject (~/AppData/Local/atom/app-1.31.1/resources/app/node_modules/season/lib/cson.js:58:25)
    at parseContentsSync (~/AppData/Local/atom/app-1.31.1/resources/app/node_modules/season/lib/cson.js:72:22)
    at Object.readFileSync (~/AppData/Local/atom/app-1.31.1/resources/app/node_modules/season/lib/cson.js:184:20)
    at keymaps.getKeymapPaths.map (~/AppData/Local/atom/app-1.31.1/resources/app/src/package.js:454:20)
    at Array.map (<anonymous>)
    at Package.loadKeymaps (~/AppData/Local/atom/app-1.31.1/resources/app/src/package.js:452:50)
    at measure (~/AppData/Local/atom/app-1.31.1/resources/app/src/package.js:133:20)
    at Package.measure (~/AppData/Local/atom/app-1.31.1/resources/app/src/package.js:88:25)
    at Package.load (~/AppData/Local/atom/app-1.31.1/resources/app/src/package.js:129:16)
    at PackageManager.loadAvailablePackage (~/AppData/Local/atom/app-1.31.1/resources/app/src/package-manager.js:619:16)
    at config.transact (~/AppData/Local/atom/app-1.31.1/resources/app/src/package-manager.js:532:20)
    at Config.transact (~/AppData/Local/atom/app-1.31.1/resources/app/src/config.js:819:20)
    at PackageManager.loadPackages (~/AppData/Local/atom/app-1.31.1/resources/app/src/package-manager.js:530:23)
    at loadStatePromise.loadState.then (~/AppData/Local/atom/app-1.31.1/resources/app/src/atom-environment.js:837:27)
    at <anonymous>

Commands

Non-Core Packages
atom-python-run 0.9.7
atom-runner 2.7.1
atom-terminal 0.8.0
autocomplete-python 1.10.12
file-icons 2.1.25
highlight-selected 0.14.0
Hydrogen 2.6.0
linter 2.2.0
minimap 4.29.9
minimap-highlight-selected 4.6.1
platformio-ide-terminal 2.8.4
python-autopep8 0.1.3
python-tools 0.6.9
script 3.18.1
script-runner 2.3.1

does any one saw this issue?


Polymer 2.0 API may add stutter, or increase learning curve

Wohoo! Congrats! Looking forward to seeing how 2.0 pans out!
The gist of this feedback is that IMHO the 2.0 class-based definition adds stutter to a very clean API, albeit at a few advantages.
I know Polymer 2.0 will have a compatibility layer for the old factory method, but I think the old factory method should be kept as the recommended element creation method. IMHO, it makes it much easier to grok an element's functionality at a glance--and I promise I'm not saying this because I've been staring at those for a while now.
Supporting arguments based on visual guide on migrating.

Extending/subclassing MyElement from multiple behaviors will now either require a really long line, or a line that's broken and has to then be closed with many parentheses, whereas before we just used an array of class-like objects.
static get is() { return 'my-element'; } repeats the element's class name and is much longer than just is: 'my-element': Keeping the factory-like Polymer() helper would allow the class to be dynamically created, would be shorter, and would not require two versions of the MyElement name.
static get config() { return ...} similar argument to that of is, except that it also takes observers, but not listeners. The map-style API we had with observers and listeners was really terse and really easy to understand. Removing listeners from here breaks that terseness and adds a bit of complexity.
customElements.define is another piece of boilerplate that seems ripe for extracting into a factory method.

In short, I think you could (and should) hide the fact that you're creating a class in a factory method, and keep the clean API we already have. Yes, classes are convenient, but I think in this case, they are getting in the way of keeping the API clean.

I have to disagree, the legacy method for constructing elements is far from what Polymer aims to be: a web component base/library.
How do you define a web component?
class MyElement extends HTMLElement { }

As you can see, Polymer 2.x stays very close to this (extends Polymer.Element), as it should.
Your arguments against such a class are the reason Polymer 1.x was so far from how a normal web component looks. We shouldn't be aiming to make your code shorter but rather to provide a base element to inherit rather than HTMLElement. In 2.x, what you see is what gets defined as a custom element, rather than being a configuration object which internally produced such a definition (1.x) hidden away from you.

Yup, you're right... Polymer tries to be a thin layer above on top of the native API, and since the existing API isn't that complicated (extends HTMLElement), there's no need to complicate things or obfuscate them by adding a layer/factory method. You've convinced me that keeping that base class style is an okay idea, and I concede.
Keeping code short and easy to parse for the human brain should still be at the top of the priorities though. So how about the following amendment to my initial ideas?

Is there a way to avoid setting is? It seems to duplicate the MyElement name. Maybe something like this?

class Polymer.Element {
  static get is() {
    this.name.replace(/\B[A-Z]([A-Z])*/g, '-$&').toLowerCase()
  }
}

Making properties and observers part of the metadata/config but not listeners and hostAttributes,  seems a bit arbitrary and adds to the learning curve. How about either moving properties and observers out into their own static getters, or moving listeners and hostAttributes into the config?

The “how do you define a web component?” question, on a more abstract level, is the one that we have been debating/dealing with.
In the simplest, non-extended, component compositions, imagine just having an input element, in a repeater, with a bind to its “type” property, class and value passing properties; i.e:
<template-repeater items=“{{whateverPagesThereAreInMyFormsForThisApi}}” as=“form” index-as=“formPageIndex">

In this collection pseudo-form pages, what is the element?  What is the component?  What is the class that we apply?  At the “element-level”, the input-element could be a check-box, a number input, a radio-button, a date-time, a search, or even —with a little more sugar(as we implemented)—a searchable, animated input with a animated dropdown menu of search options based on the property being inputted.
What constitutes the component “class” or type of the inner template’s page?
Is it a set of 8 inputs with dropdowns? (A common implementation for us.)
Is it a one page check box form?
What “elements” will be there?  Who will know?
In our implementation, we had no idea ahead of time.  Whatever prototypes of users, work-schedules, questions, calendars, or events, w/e were being used in the “input interface”, we just sliced up the properties on the proto constructor and--based on data-structure and property names with specific uses of underscores and camel case—automatically created labels, local property names, and baskets of property names to fill value objects handled in our multi-page pseudo-forms.
This model, which was hyper fast, extremely portable, low-overhead, and super re-usable seems beyond, at least our ability, to recreate in new polymer or the v1 spec.
For example, how do we define the class and its attributes without factories, or the ability to talk to child elements prior to load?
How, in any of these instances, do we even begin to answer the question What is the “component”?
If the above is laid-out as follows:
<template-repeater items=“{{whateverPagesThereAreInMyFormsForThisApi}}” as=“form” index-as=“formPageIndex">

               {{_setUtfSymbol(dropdownItems, localPropertyValue)}}

@jfrazzano , did your comment have a particular point you wanted to get across? I saw a few points here and there, but I'm not sure if there was an overarching concept you were trying to get across.

I just think we should be frank about changes and not gloss over some important technical and legal hurdles that v1 and related standards have created.
Things will be different in a few years but livelihoods depend on a lot of the advice. I believed the response a gloss and felt an example of performance differences would be an easier and less confrontational way of sending out a word of caution to an earnest inquirer.
If I was misguided in the attempt, I apologize.
Sent from my iPhone

On Sep 29, 2016, at 10:13 PM, Bernie Telles<EMAIL_ADDRESS>wrote:
@jfrazzano , did your comment have a particular point you wanted to get across? I saw a few points here and there, but I'm not sure if there was an overarching concept you were trying to get across.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

Is there anything that can be done with Polymer 2.0 syntax but not with 1.0 syntax? I chose to use Polymer because of its ease of use and expressive syntax. If we are moving to a class based and verbose version, I see it's losing its advantage. How long will the new versions keep compatibility with 1.0? If the 1.0 syntax will finally be deprecated, then we will have to switch to the new syntax from now.

I come at this from a slightly different perspective.   For a long time now, the norm has been that whenever you want to do something to a web page you add some javascript to do it.
With web components, and particularly the data binding system introduced with Polymer, this moved from an imperative approach to much much more a declarative approach.  The more I use Polymer the more I find this to be a good thing..
This syntax for Polymer 2 seems a small step back towards the use of code rather than declaration to achieve things.  What was a static is: 'my-element' has become  a line of codestatic get is() {return 'my-element';}  and similarly for the config.  What was a declarative list of listeners now has to be added by code..
It maybe a small step, but it seems to be the wrong way.

there's already a proposal for an alternative syntax for that. you can already use it with babel.
class MyElement extends HTMLElement {
  static is = 'my-element'
  static config = {
    properties: {
      foo: {type: String, value: 'bar'},
    },
    observers: [
      'onFooChanged(foo)',
    ],
  }
}

How about this?
Removes the is and promotes properties and observers to static getters instead of being nested in gonfig. I'm still iffy about the inheritance model. I have lots of components that inherit from 3 or more behaviors, and inheriting from them would be messy with this API.
class MyElement extends HTMLElement {
  // unnecessary "is" if it is automatically computed
  static properties = {
    foo: {
      type: String,
      value: 'bar'},
    }
  static observers = [
      'onFooChanged(foo)'
    ]
  }
}

@azakus @ebidel @kevinpschaaf any thoughts?

Personally, I think the config makes it a little clearer what this thing is. Calling it properties, you occasionally get people trying to access this.properties.<whatever>.
I think the team is trying to stick to the standard here, so I doubt they'd be willing to recommend class fields until the proposal becomes part of spec. But I agree it looks nicer, and hopefully we'll get there.
It's not immediately clear from the README how inheritance works with the config object. I poked around and it appers that at initialization time the element walks the prototype chain to collect and collate all of the config objects. So that shouldn't be a problem. Unless you're just talking about the actual appearance of:
MyEl extends Three(Two(One(Polymer.Element))) { ... }
... Which I agree can look a little funky. There are probably some ways to sugar that if you don't like the looks.

@arthurevans that would actually be very easy.
Define your base element in a file:
let MyElement = Three(Two(One(Polymer.Element)));

And import this definition into your element definition you can do
class MyCustomElement extends MyElement {}

So instead of importing polymer/polymer-element.html (as replacement for polymer/polymer.html in 1.0) you import your own definition.

@btelles I totally agree with your proposal of:

If not provided, a default is property is computed, based on the element name (if the trick is possible)
properties and observers are available at the root level

class MyElement extends HTMLElement {
  static properties = {
    foo: {
      type: String,
      value: 'bar'
    }
  },
  static observers = [
    'onFooChanged(foo)'
  ]
}

It is concise and elegant.

In the future we could take it even further and use decorators for that, so that this:
import {Element, is, observe, prop, readOnly, notify} from 'Polymer'

@is('string-length-counter')
class StringLengthCounter extends Element {

  @prop(String) input = ''
  @prop(Number) @readOnly @notify length = 0

  @observe('input')
  onInputChanged() {
    this.length = this.input.length
  }

}

...is equivalent to:
class StringLengthCounter extends Polymer.Element {

  static get is() { return 'string-length-counter' }

  static get config() { return {
    properties: {
      input: {type: String, value: ''},
      length: {type: Number, value: 0, readOnly: true, notifies: true},
    },
    observers: [
      'onInputChanged(input)',
    ],
  }}

  onInputChanged() {
    this.length = this.input.length
  }

}

The code for the simplest decorators on the Polymer side would be just:
function is(name) {
  return function (proto) {
    proto.is = name
  }
}
function observe(...props) {
  return function (proto, method) {
    proto.observers = proto.observers || []
    proto.observers.push(method + '(' + props.join(', ') + ')')
  }
}

This should already work with following babel plugins:

babel-plugin-transform-decorators-legacy
babel-plugin-transform-class-properties

Why do we need even need a static is?
Polymer({}) needed it because it defined the class and registered the custom element in one go.
I can't find any part of polymer that interacts with this.is before the dom element is fully created. ie: It should be possible for the class portion to infer is from the tagName without needing a pre-defined value for it.
Sure it's needed to register a custom element, but the base dom api for that is customElements.define(is, class). So I'm fully in favour of patterns like:
class MyElement extends Polymer.Element {
  // ... stuff, but no `is` definition ...
}
Polymer.define('my-element', MyElement);
// or
Polymer.define('my-element', class extends Polymer.Element {
});

Some people seem to be complaining about the boilerplate of defining a class and calling a function. But making class definition implicitly register that class somewhere sounds like a horrible abuse of the class syntax. So as long as class Foo is being used I don't believe there is a reasonable way of eliminating the separate function call boilerplate.

@dantman separate function call is not a Polymer stuff but Custom Elements v1 API:
https://developer.mozilla.org/en-US/docs/Web/Web_Components/Custom_Elements
Makingis optional will require something other naming convention, won't it?

@web-padawan From everything I understand, at this point is is pretty much now just a lower case version of the tag name. The is="x-foo" attribute has even been deprecated. And is in the context of customElements.define just tells the DOM what tagName to apply the class to.
So a getter on Polymer.Element like get is() { return this.tagName.toLowerCase(); } seems like it would be enough.

@dantman it is most likely used to tie dom-module instances into the element definition. a dom-module with an id="foo-bar" will be tied up with a get is() { return 'foo-bar'; }.
As you already said, too, it is used for registration.
Seems the best you can do is try figure out the element name from the class name, but not sure how reliable that would be and how difficult it is to get hold of the class name (From inside the base class).

@43081j But that only matters if the dom-module reference needs to be done before document.createElement('foo-bar') goes and creates an instance of your FooBar class with tagName set on it.
I did a search for usage of is within the codebase and I can't find anything to suggest that polymer needs to know the value of is early on.
And registration is separate, that is part of customElement.define which is not going to go away; there's no reason that the class needs to statically know what is being passed as the custom element name.

@dantman as per README.md this is what I was referring to:

Implement a static template getter to provide a template to stamp inside the element. By default the first

Without is, you don't know the tag name just by knowing the class (you can only guess it by convention... MyElement -> my-element).

@43081j Sure, in the current unfinished API template() is static, but the finalization process that uses it is only triggered once the non-static _initializeProperties() when a document.createElement('foo-bar') triggers it.
There's no reason the class finalization has to be done statically. template() could just as easily be part of the prototype with a per-is cache.

ah now i see what you're saying, you think we only need it after creating an instance (so we just this.tagName). if you're completely certain it is only ever used after instantiating, it could be there for legacy reasons possibly.
I'm not sure beyond that without reading through the source.

We've landed on what we intend to be the final Polymer 2.x class-based syntax based on much of the feedback here.
A major benefit of moving to ES6 class based syntax is standard JavaScript-based support for subclassing and super calls; that said, native ES6 classes have restrictions that make the more declarative "property"-baed approach not possible (without some of the speculative transpilation described above), hence the need for getters.  We think this is a reasonable tradeoff.
Please see the diffs in the README here, which explain a lot of the questions regarding why is is required, etc. https://github.com/Polymer/polymer/pull/4332/commits/e2118aa4d7f81dfed2d5c1e96903d6c0bdacdce0?short_path=04c6e90#diff-04c6e90faac2675aa89e2176d2eec7d8

In general, there is a retraction in concept from a state aware,  component-based, layered build, that encourages extensibility and a higher degree of mpolymorphism/app like browser like behavior l in the 1.0 spec and related tech
These limits are unfortunate and while many of the limits can be patched or glossed in numerous ways, the highest end performance, as well as international wai aria  legal standards for authors and vendors present an unfortunate, and often debilitating development, legal, and contract garnering development path.  These issues cannot be glossed
And, as a result, Some Larger development entities are shifting toward shard doms for a variety of the above stated reasons: no liability, better performance, polymorphism and just avoidance of an altogether unfortunate situation.
My point, which I preferred  to imply rather than state, was the same point made at this year's io, a point far too often NOT PRESSED by advocates:
We are all big boys and girls here; we engage in large scale private and public business and even the most novice of developers can be the proverbial nail that "lost a kingdom" but for a...
In these dynamic often turbulent times, it would seem
comfort or a confidence game  is the last reason any one of us is here.
We are here it's to build "awesome", to participate in ventures that can and will change the world.
The start, and I believe only respectful and reasonable way to pursue such "do no harm and do some awesome" set of  goals is to be straight up with one another about the shifts in tech.
Refrain from any whining or complaint about change.  Change is good. (For example, I think it's awesome, we got a chance to really invest in string literals, template strings, iterative binding, fragmented doms assembled with partial char codes....)
Native has so much power and speed, if one is willing to handle the dev responsibility.
It's not for everyone. But it's also not something a "use the platform" motto would seem to encourage.
In the thread, I saw someone asking an earnest question, and I didn't believe it  fair to recast that earnest question, explained via simple example, and gloss the over-arching issues above(speed, next Dom shift, legitimate contracting issues). This is a livelihood for many. Futures depend on clear open discourse. I believed someone was getting a "gloss" and real world more complex but still simple examples could illustrate the danger I perceived
I could be way off here. It's not my place perhaps to speak. And it's not the nineties anymore, when I was young and q comment like "did u have a point" would have been just well silly To me.  Now it actually matters.  What we do here matters
We can share and build an as of yet I unimaginable future.
With change world  as option one, other choices just seem lame
And, to me at least, being frank with one another seems just what the whole experience and community work is all about
I didn't think the advice was frank
I offered a counter example
That was the point.
You cool now with the comment? I already regret even thinking of sending this, but I just don't believe we can all do our best here if we can't be frank, honest and even sometimes a little surly.
I hope you took no offense and if I am totally off base here. Let's share code.  You know a lot more than I do and I am always eager to learn and help.
Sincerely,
Jason
Sent from my iPhone
On Sep 29, 2016, at 10:13 PM, Bernie Telles<EMAIL_ADDRESS>wrote:

@jfrazzano , did your comment have a particular point you wanted to get across? I saw a few points here and there, but I'm not sure if there was an overarching concept you were trying to get across.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

Sent from my iPhone

On Sep 29, 2016, at 10:13 PM, Bernie Telles<EMAIL_ADDRESS>wrote:
@jfrazzano , did your comment have a particular point you wanted to get across? I saw a few points here and there, but I'm not sure if there was an overarching concept you were trying to get across.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.


convert test to data_test

resolves #8699
Problem
With the addition of unit_tests the config for tests is confusing as it currently does not include unit_tests, only data_tests.
Solution
Explicitly define data_tests as data_tests in both schema files and in dbt_project.yml.
Continue to support the tests config for backwards compatibility but add a deprecation warning for it.
Checklist

[ ] I have read the contributing guide and understand what's expected of me
[ ] I have run this code in development and it appears to resolve the stated issue
[ ] This PR includes tests, or tests are not required/relevant for this PR
[ ] This PR has no interface changes (e.g. macros, cli, logs, json artifacts, config files, adapter interface, etc) or this PR has already received feedback and approval from Product or DX
[ ] This PR includes type annotations for new and modified functions

@graciegoheen The ticket that's referenced is contradictory about whether the config key in yaml should be "data-tests" or "data_tests".  Which do you want in schema.yml?

My understanding was that it had to have _ in the schema yml files and - in the dbt_project.yml file (similar to how we handle semantic models - semantic_models in schema yml, semantic-models in dbt_project.yml).
Let me know if that understanding was incorrect.

Using dash in the dbt_project.yml and underscore in the schema files is also the pattern used elsewhere.  semantic-models are another config we uses dashes in one place and underscores in another.  It was also decided to do this for unit-tests as implemented in #8988

@graciegoheen yes!  Underscored everywhere for unit_tests and data_tests!
Nothing else was modified that's called out in #9235.


Pub:  'install' command missing from help

If you type 'pub' or 'pub help' you get a help message.  In that help message, a list of available commands is displayed.  It doesn't show the 'install' command.

I  never used install myself. AFAIK this is a deprecated alias for get and therefore not listed.

Yup pub get --help


PANIC generated into public-facing documentation

What happened?
Currently as spotted by @VenelinMartinov RandomInteger docs generate a PANIC into Java code, where other languages work fine. This is using pulumi convert to perform the translation.
Example

# The following example shows how to generate a random priority
# between 1 and 50000 for a aws_alb_listener_rule resource:

resource "random_integer" "priority" {
  min = 1
  max = 50000
  keepers = {
    # Generate a new integer each time we switch to a new listener ARN
    listener_arn = var.listener_arn
  }
}

resource "aws_alb_listener_rule" "main" {
  listener_arn = random_integer.priority.keepers.listener_arn
  priority     = random_integer.priority.result

  action {
    type             = "forward"
    target_group_arn = var.target_group_arn
  }
  # ... (other aws_alb_listener_rule arguments) ...
}

Getting this rendered:

package generated_program;

import com.pulumi.Context;
import com.pulumi.Pulumi;
import com.pulumi.core.Output;
import com.pulumi.random.RandomInteger;
import com.pulumi.random.RandomIntegerArgs;
import com.pulumi.aws.albListenerRule;
import com.pulumi.aws.AlbListenerRuleArgs;
import java.util.List;
import java.util.ArrayList;
import java.util.Map;
import java.io.File;
import java.nio.file.Files;
import java.nio.file.Paths;

public class App {
    public static void main(String[] args) {
        Pulumi.run(App::stack);
    }

    public static void stack(Context ctx) {
        // The following example shows how to generate a random priority
        // between 1 and 50000 for a aws_alb_listener_rule resource:
        var priority = new RandomInteger("priority", RandomIntegerArgs.builder()
            .min(1)
            .max(50000)
            .keepers(Map.of("listener_arn", listenerArn))
            .build());

        var main = new AlbListenerRule("main", AlbListenerRuleArgs.builder()
            .listenerArn(priority.keepers().applyValue(keepers -> keepers.listenerArn()))
            .priority(priority.result())
            .action(%!v(PANIC=Format method: runtime error: invalid memory address or nil pointer dereference))
            .build());

    }
}

Python translation:
import pulumi
import pulumi_aws as aws
import pulumi_random as random

# The following example shows how to generate a random priority
# between 1 and 50000 for a aws_alb_listener_rule resource:
priority = random.RandomInteger("priority",
    min=1,
    max=50000,
    keepers={
        "listener_arn": listener_arn,
    })
main = aws.index.AlbListenerRule("main",
    listener_arn=priority.keepers.listener_arn,
    priority=priority.result,
    action=[{
        type: forward,
        targetGroupArn: target_group_arn,
    }])

Output of pulumi about
N/A
Additional context
N/A
Contributing
Vote on this issue by adding a 👍 reaction.
To contribute a fix for this issue, leave a comment (and link to your pull request, if you've opened one already).

Since the page https://www.pulumi.com/registry/packages/random/api-docs/randominteger/ does not have this problem yet, this must be a new issue generated by the converter rollout.

@t0yv0 I've been investigating this issue. I am using the following:

Pulumi CLI v3.114.0
pulumi-converter-terraform v1.0.16

Running pulumi convert --from terraform --language python --out py against the example above, gives me different results:
import pulumi
import pulumi_aws as aws
import pulumi_random as random

priority = random.RandomInteger("priority",
    min=1,
    max=50000,
    keepers={
        "listener_arn": listener_arn,
    })
main = aws.alb.ListenerRule("main",
    listener_arn=priority.keepers["listenerArn"],
    priority=priority.result,
    actions=[aws.alb.ListenerRuleActionArgs(
        type="forward",
        target_group_arn=target_group_arn,
    )])

Notice the subtle difference in actions where the only element in the array is a typed object aws.alb.ListenerRuleActionArgs(...) not just {...}. This to me suggests that the PCL binder couldn't load the schema of aws while generating examples docs for random 🤔 That would be the case if you are disabling automatic plugin acquisition during this phase (i.e. only schema of random being available)
The specific java issue is that when it tries load the schema type of an object and it can't find it, it panics. That means program-gen here needs to be more resilient with these cases.
That said, when we do have access to the schema of aws, program generation for java works fine. Running:
pulumi convert --from terraform --language java --out java

Gives:
package generated_program;

// imports ...

public class App {
    public static void main(String[] args) {
        Pulumi.run(App::stack);
    }

    public static void stack(Context ctx) {
        var priority = new RandomInteger("priority", RandomIntegerArgs.builder()
            .min(1)
            .max(50000)
            .keepers(Map.of("listener_arn", listenerArn))
            .build());

        var main = new ListenerRule("main", ListenerRuleArgs.builder()
            .listenerArn(priority.keepers().applyValue(keepers -> keepers.listenerArn()))
            .priority(priority.result())
            .actions(ListenerRuleActionArgs.builder()
                .type("forward")
                .targetGroupArn(targetGroupArn)
                .build())
            .build());

    }
}

That's a brilliant suggestion, let me go ahead and do a pass at fixing this in pulumi-random.

that would be the case if you are disabling automatic plugin acquisition during this phase

We do try to run with disabled plugin acquisition indeed as much as possible.
QQ: is there a chance we can make a switch to fail hard and fast when a schema for something is not available, or perhaps not listed in a config file ? In this provider build scenario, we would very much rather have that, so that'd guide us quickly in the direction of pinning and making available all the required dependencies.

Similar issue in https://github.com/pulumi/pulumi-aws/issues/3125 - still a problem, I reopened it; checking up on it as well.

Random provider is unblocked, good news. Still struggling with completely closing out the issues in AWS, I opened a few more tickets with concrete examples.

You can close this one as no-repro (once the AWS dependency in random is updated to 6.x).

@lunaris, does https://github.com/pulumi/pulumi-java/pull/1357 address this issue as well?

FWIW since we updated the dependencies in Random it no longer reproduces.

I'm going to go ahead and close this as fixed by https://github.com/pulumi/pulumi-java/pull/1357 (and no longer repos anyway given updating the deps in Random).


Make Span Autocloseable

Updated interface to make it possible for Span to be used in try-with-resource blocks to reduce some of the standard boilerplate code that's required to ensure that the finish method is called.  Treating Span as a resource allows for close (previously finish) to be closed in an automated way.

Using AutoClosable is a good idea.
Do you mind if we wait until https://github.com/opentracing/opentracing-java/pull/20 is agreed upon before we finally merge this? #20 contains project refactoring that easily throws up conflicts when rebasing it.

I can wait for #20 I have added it in my local implementation which I'm coding my implementation of Span against.

implemented in https://github.com/opentracing/opentracing-java/commit/01025fc8c0beab93484420c333e43f014da60d2b