Producer failover

I've a Kafka cluster with 3 brokers. But I've faced a problem while one broker was falled down (ex., upgrading or failure).
The producer continues trying to ProduceSync() to fallen broker infinitely. Sometimes producer switches to other workable broker.
I've investigated how the ProduceSync() works and found out that it uses Sinc.produce() and as a consequence, it use Sinc.doSequenced(). Is it correct?
Sinc.doSequenced() uses only one broker, fetched by Client.brokerOrErr(). And doesn't changed it after errors.
Is it correct behaviour?
How can I limit the producing loop by time? I want to drop an error if ProduceSync cannot to produce after 10s, example.
<134>1 14:36:46.810145 beginning transaction transactional_id=http-kafka-28692
<135>1 14:36:46.810351 opening connection to broker addr=<IP_ADDRESS>:9093 broker=3
<135>1 14:36:46.817657 connection opened to broker broker=3 addr=<IP_ADDRESS>:9093
<135>1 14:36:46.817770 connection initialized successfully addr=<IP_ADDRESS>:9093 broker=3
<135>1 14:36:46.817821 wrote AddPartitionsToTxn v3 time_to_write=29.227µs err=<nil> broker=3 bytes_written=83 write_wait=7.403375ms
<135>1 14:36:46.823620 read AddPartitionsToTxn v3 err=<nil> broker=3 bytes_read=50 read_wait=78.86µs time_to_read=5.755618ms
<135>1 14:36:46.823723 retrying request tries=1 backoff=230.298076ms request_error=<nil> response_error=COORDINATOR_NOT_AVAILABLE: The coordinator is not available.
<135>1 14:36:47.057487 wrote FindCoordinator v4 broker=3 bytes_written=42 write_wait=185.586µs time_to_write=42.689µs err=<nil>
<135>1 14:36:47.058197 read FindCoordinator v4 broker=3 bytes_read=62 read_wait=145.794µs time_to_read=611.298µs err=<nil>
<135>1 14:36:47.058400 wrote AddPartitionsToTxn v3 write_wait=51.985µs time_to_write=36.932µs err=<nil> broker=3 bytes_written=83
<135>1 14:36:47.059458 read AddPartitionsToTxn v3 broker=3 bytes_read=50 read_wait=143.05µs time_to_read=910.882µs err=<nil>
<135>1 14:36:47.059522 retrying request tries=2 backoff=457.460797ms request_error=<nil> response_error=COORDINATOR_NOT_AVAILABLE: The coordinator is not available.
<135>1 14:36:47.520361 opening connection to broker addr=<IP_ADDRESS>:9093 broker=seed 0
<132>1 14:36:57.523937 unable to open connection to broker addr=<IP_ADDRESS>:9093 broker=seed 0 err=dial tcp <IP_ADDRESS>:9093: i/o timeout
<135>1 14:36:57.524082 retrying request tries=1 backoff=284.533848ms request_error=unable to dial: dial tcp <IP_ADDRESS>:9093: i/o timeout response_error=<nil>
<135>1 14:36:57.824323 opening connection to broker addr=<IP_ADDRESS>:9093 broker=1
<132>1 14:37:07.826475 unable to open connection to broker addr=<IP_ADDRESS>:9093 broker=1 err=dial tcp <IP_ADDRESS>:9093: i/o timeout
<135>1 14:37:07.826858 retrying request request_error=unable to dial: dial tcp <IP_ADDRESS>:9093: i/o timeout response_error=<nil> tries=2 backoff=586.29262ms
<135>1 14:37:08.416674 wrote FindCoordinator v4 time_to_write=44.76µs err=<nil> broker=3 bytes_written=42 write_wait=85.71µs
<135>1 14:37:08.417393 read FindCoordinator v4 broker=3 bytes_read=62 read_wait=127.606µs time_to_read=635.265µs err=<nil>
<135>1 14:37:08.417536 wrote AddPartitionsToTxn v3 bytes_written=83 write_wait=36.114µs time_to_write=29.627µs err=<nil> broker=3
<135>1 14:37:08.418749 read AddPartitionsToTxn v3 broker=3 bytes_read=50 read_wait=86.14µs time_to_read=1.111242ms err=<nil>
<135>1 14:37:08.418806 retrying request request_error=<nil> response_error=COORDINATOR_NOT_AVAILABLE: The coordinator is not available. tries=3 backoff=1.108865437s
<135>1 14:37:09.535911 opening connection to broker addr=<IP_ADDRESS>:9093 broker=seed 1
<132>1 14:37:19.536643 unable to open connection to broker broker=seed 1 err=dial tcp <IP_ADDRESS>:9093: i/o timeout addr=<IP_ADDRESS>:9093
<135>1 14:37:19.536786 retrying request tries=1 backoff=231.021421ms request_error=unable to dial: dial tcp <IP_ADDRESS>:9093: i/o timeout response_error=<nil>
<135>1 14:37:19.771543 opening connection to broker addr=<IP_ADDRESS>:9093 broker=1
<132>1 14:37:29.775081 unable to open connection to broker addr=<IP_ADDRESS>:9093 broker=1 err=dial tcp <IP_ADDRESS>:9093: i/o timeout
<135>1 14:37:29.775508 retrying request tries=2 backoff=434.104674ms request_error=unable to dial: dial tcp <IP_ADDRESS>:9093: i/o timeout response_error=<nil>
<135>1 14:37:30.210920 wrote FindCoordinator v4 write_wait=71.458µs time_to_write=47.876µs err=<nil> broker=3 bytes_written=42
<135>1 14:37:30.211422 read FindCoordinator v4 bytes_read=62 read_wait=151.959µs time_to_read=377.955µs err=<nil> broker=3
<135>1 14:37:30.211613 wrote AddPartitionsToTxn v3 broker=3 bytes_written=83 write_wait=51.084µs time_to_write=30.96µs err=<nil>
<135>1 14:37:30.212745 read AddPartitionsToTxn v3 broker=3 bytes_read=50 read_wait=120.874µs time_to_read=1.021783ms err=<nil>
<134>1 14:37:30.212836 metadata update triggered why=opportunistic load during sink backoff
<135>1 14:37:30.212905 opening connection to broker addr=<IP_ADDRESS>:9093 broker=seed 2
<135>1 14:37:30.220655 connection opened to broker addr=<IP_ADDRESS>:9093 broker=seed 2
<135>1 14:37:30.220725 connection initialized successfully addr=<IP_ADDRESS>:9093 broker=seed 2
<135>1 14:37:30.220782 wrote Metadata v11 broker=seed 2 bytes_written=65 write_wait=7.822396ms time_to_write=21.885µs err=<nil>
<135>1 14:37:30.224335 read Metadata v11 broker=seed 2 bytes_read=286 read_wait=48.847µs time_to_read=3.497792ms err=<nil>
<135>1 14:37:30.224395 metadata refresh topic partition data changed partition=0 new_leader=3 new_leader_epoch=29 old_leader=3 old_leader_epoch=28 topic=test-topic
<135>1 14:37:30.224448 metadata refresh topic partition data changed topic=test-topic partition=1 new_leader=3 new_leader_epoch=27 old_leader=3 old_leader_epoch=26
<135>1 14:37:30.224497 metadata refresh topic partition data changed topic=test-topic partition=2 new_leader=3 new_leader_epoch=35 old_leader=1 old_leader_epoch=34
<135>1 14:37:30.224541 metadata refresh topic partition data changed old_leader=1 old_leader_epoch=28 topic=test-topic partition=3 new_leader=3 new_leader_epoch=29
<135>1 14:37:30.224643 wrote FindCoordinator v4 err=<nil> broker=3 bytes_written=42 write_wait=23.683µs time_to_write=20.286µs
<135>1 14:37:30.225128 read FindCoordinator v4 broker=3 bytes_read=62 read_wait=91.079µs time_to_read=395.637µs err=<nil>
<135>1 14:37:30.225263 wrote AddPartitionsToTxn v3 bytes_written=83 write_wait=29.977µs time_to_write=27.46µs err=<nil> broker=3
<135>1 14:37:30.226259 read AddPartitionsToTxn v3 broker=3 bytes_read=50 read_wait=94.474µs time_to_read=894.645µs err=<nil>
<135>1 14:37:30.226318 retrying request tries=1 backoff=243.469586ms request_error=<nil> response_error=COORDINATOR_NOT_AVAILABLE: The coordinator is not available.
<135>1 14:37:30.481937 opening connection to broker addr=<IP_ADDRESS>:9093 broker=seed 0
<132>1 14:37:40.485280 unable to open connection to broker addr=<IP_ADDRESS>:9093 broker=seed 0 err=dial tcp <IP_ADDRESS>:9093: i/o timeout
<135>1 14:37:40.485443 retrying request tries=1 backoff=216.634833ms request_error=unable to dial: dial tcp <IP_ADDRESS>:9093: i/o timeout response_error=<nil>
<135>1 14:37:40.708462 wrote FindCoordinator v4 broker=3 bytes_written=42 write_wait=102.446µs time_to_write=36.821µs err=<nil>
<135>1 14:37:40.709121 read FindCoordinator v4 broker=3 bytes_read=62 read_wait=172.093µs time_to_read=511.864µs err=<nil>
...
<135>1 14:43:38.429327 wrote AddPartitionsToTxn v3 broker=3 bytes_written=83 write_wait=46.453µs time_to_write=34.388µs err=<nil>
<135>1 14:43:38.430795 read AddPartitionsToTxn v3 time_to_read=1.371719ms err=<nil> broker=3 bytes_read=50 read_wait=91.482µs
<134>1 14:43:38.430855 metadata update triggered why=opportunistic load during sink backoff
<135>1 14:43:38.431034 wrote Metadata v11 broker=3 bytes_written=65 write_wait=47.974µs time_to_write=27.359µs err=<nil>
<135>1 14:43:38.431955 read Metadata v11 time_to_read=842.77µs err=<nil> broker=3 bytes_read=294 read_wait=81.705µs
<135>1 14:43:38.432040 metadata refresh has identical topic partition data topic=test-topic partition=0 leader=3 leader_epoch=29
<135>1 14:43:38.432119 metadata refresh has identical topic partition data leader=3 leader_epoch=27 topic=test-topic partition=1
<135>1 14:43:38.432199 metadata refresh has identical topic partition data topic=test-topic partition=2 leader=3 leader_epoch=35
<135>1 14:43:38.432285 metadata refresh has identical topic partition data partition=3 leader=3 leader_epoch=29 topic=test-topic
<135>1 14:43:40.937708 wrote FindCoordinator v4 err=<nil> broker=3 bytes_written=42 write_wait=116.952µs time_to_write=64.928µs
<135>1 14:43:40.938280 read FindCoordinator v4 broker=3 bytes_read=62 read_wait=143.222µs time_to_read=463.45µs err=<nil>
<135>1 14:43:40.938462 wrote AddPartitionsToTxn v3 write_wait=39.842µs time_to_write=34.013µs err=<nil> broker=3 bytes_written=83
<135>1 14:43:40.962693 read AddPartitionsToTxn v3 bytes_read=50 read_wait=115.381µs time_to_read=24.075232ms err=<nil> broker=3
<135>1 14:43:40.962784 opening connection to broker addr=<IP_ADDRESS>:9093 broker=3
<135>1 14:43:40.970550 connection opened to broker addr=<IP_ADDRESS>:9093 broker=3
<135>1 14:43:40.970672 connection initialized successfully addr=<IP_ADDRESS>:9093 broker=3
<135>1 14:43:40.971699 wrote Produce v9 broker=3 bytes_written=702 write_wait=8.879035ms time_to_write=40.176µs err=<nil>
<135>1 14:43:41.043202 read Produce v9 err=<nil> broker=3 bytes_read=76 read_wait=188.858µs time_to_read=71.2313ms
<135>1 14:43:41.043333 produced broker=3 to=test-topic[3{115=>116}]
<134>1 14:43:41.043384 flushing
<135>1 14:43:41.043432 flushed
<135>1 14:43:41.043475 transaction ending, no group loaded; this must be a producer-only transaction, not consume-modify-produce EOS
<134>1 14:43:41.043522 ending transaction epoch=0 commit=true transactional_id=http-kafka-28692 producer_id=281000
<135>1 14:43:41.043570 wrote EndTxn v3 bytes_written=51 write_wait=46.112µs time_to_write=35.409µs err=<nil> broker=3
<135>1 14:43:41.070314 read EndTxn v3 broker=3 bytes_read=16 read_wait=70.508µs time_to_read=26.590678ms err=<nil>

Metadata updates can actually move a partition from one sink to another, it's a bit tricky: https://github.com/twmb/franz-go/blob/master/pkg/kgo/topics_and_partitions.go#L465-L492
So, the client is continually trying to produce to one broker. A failing produce request triggers an occasional metadata refresh; metadata will eventually see that the leader for the partition has move to another broker, and the client will then send the records to the other broker.
I only see one produce request in your logs, though. The thing that actually looks stuck is AddPartitionsToTxn. In this case, the request must go to a single specific broker (the coordinator for the transaction). The client is unable to begin a transaction until this request is successful, and the client is unable to produce until the transaction has begun.
There are a few options you can use to cause records to eventually fail:

use RecordRetries, I don't recommend this option, but it allows you to bound the number of retries (and AddPartitionsToTxn failing counts as a try)
call AbortTransaction, which will fail all records
use RecordDeliveryTimeout to have a bounded e2e time of attempts

One last caveat: the client does not allow failing records that are in an "unknown" state -- i.e., the request was sent and we do not know if the broker handled the request or not. This shouldn't happen much.

Closing the issue per the above reply, lmk if there's more to it :)

@twmb, thx for the answer.

call AbortTransaction, which will fail all records

I cannot call Client.EndTransaction(context.Background(), kgo.TryAbort) while it's a synchronous produce. I don't get an error from Client.ProduceSync() at the issue.
As I see in debug Sinc.produce() always returns true while broker is down on sink.doTxnReq(req, txnReq) returned as isRetriableBrokerErr(err) or as isDialErr(err).

@drTr0jan you might be running into the client does not allow failing records that are in an "unknown" state. Do you happen to have logs for what you're running into?

@twmb, I only have these logs:
[11:31:18.488]  INFO kafka-client: beginning transaction transactional_id=developer-2-36962
[11:31:18.488] DEBUG kafka-client: opening connection to broker addr=<IP_ADDRESS>:9093 broker=1
[11:31:28.490]  WARN kafka-client: unable to open connection to broker addr=<IP_ADDRESS>:9093 broker=1 err=dial tcp <IP_ADDRESS>:9093: i/o timeout
[11:31:28.491] DEBUG kafka-client: retrying request backoff=293.675427ms request_error=unable to dial: dial tcp <IP_ADDRESS>:9093: i/o timeout response_error=<nil> tries=1
[11:31:28.803] DEBUG kafka-client: opening connection to broker addr=<IP_ADDRESS>:9093 broker=1
[11:31:38.931]  WARN kafka-client: unable to open connection to broker addr=<IP_ADDRESS>:9093 broker=1 err=dial tcp <IP_ADDRESS>:9093: i/o timeout
[11:31:38.931] DEBUG kafka-client: retrying request backoff=594.31167ms request_error=unable to dial: dial tcp <IP_ADDRESS>:9093: i/o timeout response_error=<nil> tries=2
[11:31:39.550] DEBUG kafka-client: opening connection to broker addr=<IP_ADDRESS>:9093 broker=1
[11:31:49.708]  WARN kafka-client: unable to open connection to broker addr=<IP_ADDRESS>:9093 broker=1 err=dial tcp <IP_ADDRESS>:9093: i/o timeout
[11:31:49.708]  WARN kafka-client: produce partition load error, bumping error count on first stored batch broker=1 err=unable to dial: dial tcp <IP_ADDRESS>:9093: i/o timeout partition=1 topic=test-topic
[11:31:49.709]  WARN kafka-client: unable to AddPartitionsToTxn due to retriable broker err, bumping client's buffered record load errors by 1 and retrying err=unable to dial: dial tcp <IP_ADDRESS>:9093: i/o timeout
[11:31:49.709] DEBUG kafka-client: opening connection to broker addr=<IP_ADDRESS>:9093 broker=1
[11:31:59.717]  WARN kafka-client: unable to open connection to broker addr=<IP_ADDRESS>:9093 broker=1 err=dial tcp <IP_ADDRESS>:9093: i/o timeout
[11:31:59.717] DEBUG kafka-client: retrying request backoff=290.914257ms request_error=unable to dial: dial tcp <IP_ADDRESS>:9093: i/o timeout response_error=<nil> tries=1
[11:32:00.027] DEBUG kafka-client: opening connection to broker addr=<IP_ADDRESS>:9093 broker=1
[11:32:10.039]  WARN kafka-client: unable to open connection to broker addr=<IP_ADDRESS>:9093 broker=1 err=dial tcp <IP_ADDRESS>:9093: i/o timeout
[11:32:10.040] DEBUG kafka-client: retrying request backoff=487.451277ms request_error=unable to dial: dial tcp <IP_ADDRESS>:9093: i/o timeout response_error=<nil> tries=2
[11:32:10.536] DEBUG kafka-client: opening connection to broker addr=<IP_ADDRESS>:9093 broker=1
[11:32:20.566]  WARN kafka-client: unable to open connection to broker addr=<IP_ADDRESS>:9093 broker=1 err=dial tcp <IP_ADDRESS>:9093: i/o timeout
[11:32:20.566]  WARN kafka-client: produce partition load error, bumping error count on first stored batch broker=1 err=unable to dial: dial tcp <IP_ADDRESS>:9093: i/o timeout partition=1 topic=test-topic
[11:32:20.566]  WARN kafka-client: unable to AddPartitionsToTxn due to retriable broker err, bumping client's buffered record load errors by 1 and retrying err=unable to dial: dial tcp <IP_ADDRESS>:9093: i/o timeout
[11:32:20.566] DEBUG kafka-client: opening connection to broker addr=<IP_ADDRESS>:9093 broker=1

Can you help to get more detail logs if you need?

The AddPartitionsToTxn request needs to go to the transaction coordinator, my guess is that the txn coordinator is broker 1, which was taken down.
Currently, when AddPartitionsToTxn fails, the metadata is not refreshed. Perhaps I should add an opportunistic refresh. Do you happen to know if this issue auto-resolves after 5 minutes (when metadata expires and is automatically refreshed)?

Also, are you actively calling AbortBufferedRecords(ctx)? The log you are seeing (produce partition load err) falls into aborting all records if it is safe (canFailFromLoadErrs): https://github.com/twmb/franz-go/blob/master/pkg/kgo/sink.go#L1257-L1266, where maybeFailErr returns true if you are aborting.

use RecordDeliveryTimeout to have a bounded e2e time of attempts

I've tried the option, but the problem hasn't resolved.

Do you happen to know if this issue auto-resolves after 5 minutes (when metadata expires and is automatically refreshed)?

Yep, the issue often auto-resolves while 5 minutes timeout (after metadata refresh).

Also, are you actively calling AbortBufferedRecords(ctx)?

Nope, I don't call AbortBufferedRecords(ctx) explicitly.
I think, it must be a timeout option where ProduceSync() should returns an error if message hasn't produced before timeout is expired.

What RecordDeliveryTimeout did you use? The only reason RecordDeliveryTimeout would not apply is if a produce request is outstanding (and cannot know whether the broker has written the request or not). You would be able to see that in the logs if you see a wrote Produce... without a corresponding read.
The reason this auto-resolves after 5min is because after 5min, a metadata update is triggered which moves the partition to another broker.
What I need to add to the client: add a metadata trigger if AddPartitionsToTxn fails. That would cause the controller-move to be seen much more quickly.
So, the yet-unknown problem is why RecordDeliveryTimeout is not working for you.

What timeout are you using?
Can you recreate this and capture debug logs from the produce through after the delivery timeout?

This commit: https://github.com/twmb/franz-go/commit/9ee5efa3a7b300be3fa8b68e1aeb6ad63d0b268a
should address your AddPartitionsToTxn issue,
and this commit: https://github.com/twmb/franz-go/commit/56fcfb45b882802ce103d25b228f4e0282a6e4eb
will make some aspect of the retrying clearer.
I'm still not sure why the delivery timeout is not kicking in (the latter commit can help there), but given the first commit, I'm going to close this request. Please try 1.10.1 and lmk if that fixes what you're running into.

@twmb, first of all, I want to thank you for quickly help with the issue.
I've tried 1.10.1 and got old behavior:
[16:07:06.758] DEBUG server: Produce message to topic='test-topic' with key='bla-bla-bla'
[16:07:06.758]  INFO kafka-client: beginning transaction transactional_id=developer-1-7886
[16:07:06.758] DEBUG kafka-client: opening connection to broker addr=<IP_ADDRESS>:9093 broker=2
[16:07:16.762]  WARN kafka-client: unable to open connection to broker addr=<IP_ADDRESS>:9093 broker=2 err=dial tcp <IP_ADDRESS>:9093: i/o timeout
[16:07:16.762] DEBUG kafka-client: opening connection to broker addr=<IP_ADDRESS>:9093 broker=2
[16:07:26.765]  WARN kafka-client: unable to open connection to broker addr=<IP_ADDRESS>:9093 broker=2 err=dial tcp <IP_ADDRESS>:9093: i/o timeout
[16:07:26.765] DEBUG kafka-client: retrying request backoff=228.950458ms request_error=unable to dial: dial tcp <IP_ADDRESS>:9093: i/o timeout response_error=<nil> tries=1
[16:07:27.004] DEBUG kafka-client: opening connection to broker addr=<IP_ADDRESS>:9093 broker=2
[16:07:37.061]  WARN kafka-client: unable to open connection to broker addr=<IP_ADDRESS>:9093 broker=2 err=dial tcp <IP_ADDRESS>:9093: i/o timeout
[16:07:37.061] DEBUG kafka-client: opening connection to broker addr=<IP_ADDRESS>:9093 broker=2
[16:07:47.071]  WARN kafka-client: unable to open connection to broker addr=<IP_ADDRESS>:9093 broker=2 err=dial tcp <IP_ADDRESS>:9093: i/o timeout
[16:07:47.071]  WARN kafka-client: produce partition load error, bumping error count on first stored batch batch0_should_fail=false broker=1 can_fail=false err=unable to dial: dial tcp <IP_ADDRESS>:9093: i/o timeout is_network_err=true is_retriable_kerr=false is_unknown_limit=false partition=2 topic=test-topic will_fail=false
[16:07:47.071]  WARN kafka-client: unable to AddPartitionsToTxn due to retriable broker err, bumping client's buffered record load errors by 1 and retrying err=unable to dial: dial tcp <IP_ADDRESS>:9093: i/o timeout
[16:07:47.071]  INFO kafka-client: metadata update triggered why=attempting to refresh transaction coordinator due to failed AddPartitionsToTxn requests
[16:07:47.071] DEBUG kafka-client: opening connection to broker addr=<IP_ADDRESS>:9093 broker=2
[16:07:57.074]  WARN kafka-client: unable to open connection to broker addr=<IP_ADDRESS>:9093 broker=2 err=dial tcp <IP_ADDRESS>:9093: i/o timeout
[16:07:57.074] DEBUG kafka-client: opening connection to broker addr=<IP_ADDRESS>:9093 broker=2
[16:08:07.085]  WARN kafka-client: unable to open connection to broker addr=<IP_ADDRESS>:9093 broker=2 err=dial tcp <IP_ADDRESS>:9093: i/o timeout
[16:08:07.085] DEBUG kafka-client: opening connection to broker addr=<IP_ADDRESS>:9093 broker=2
[16:08:07.085] DEBUG kafka-client: retrying request backoff=240.118451ms request_error=unable to dial: dial tcp <IP_ADDRESS>:9093: i/o timeout response_error=<nil> tries=1
[16:08:17.088]  WARN kafka-client: unable to open connection to broker addr=<IP_ADDRESS>:9093 broker=2 err=dial tcp <IP_ADDRESS>:9093: i/o timeout
[16:08:17.088] DEBUG kafka-client: opening connection to broker addr=<IP_ADDRESS>:9093 broker=2
[16:08:27.108]  WARN kafka-client: unable to open connection to broker addr=<IP_ADDRESS>:9093 broker=2 err=dial tcp <IP_ADDRESS>:9093: i/o timeout
[16:08:27.108] DEBUG kafka-client: opening connection to broker addr=<IP_ADDRESS>:9093 broker=2
[16:08:27.108]  WARN kafka-client: produce partition load error, bumping error count on first stored batch batch0_should_fail=false broker=1 can_fail=false err=unable to dial: dial tcp <IP_ADDRESS>:9093: i/o timeout is_network_err=true is_retriable_kerr=false is_unknown_limit=false partition=2 topic=test-topic will_fail=false
[16:08:27.357]  INFO kafka-client: metadata update triggered why=re-updating metadata due to err: unable to dial: dial tcp <IP_ADDRESS>:9093: i/o timeout
[16:08:27.357] DEBUG kafka-client: opening connection to broker addr=<IP_ADDRESS>:9093 broker=3
[16:08:27.385] DEBUG kafka-client: connection opened to broker addr=<IP_ADDRESS>:9093 broker=3
[16:08:27.385] DEBUG kafka-client: issuing api versions request broker=3 version=3
[16:08:27.385] DEBUG kafka-client: wrote ApiVersions v3 broker=3 bytes_written=31 err=<nil> time_to_write=10.8µs write_wait=8.576µs
[16:08:27.401] DEBUG kafka-client: read ApiVersions v3 broker=3 bytes_read=439 err=<nil> read_wait=21.932µs time_to_read=16.001381ms
[16:08:27.401] DEBUG kafka-client: connection initialized successfully addr=<IP_ADDRESS>:9093 broker=3
[16:08:27.401] DEBUG kafka-client: wrote Metadata v12 broker=3 bytes_written=64 err=<nil> time_to_write=14.658µs write_wait=43.478204ms
[16:08:27.412] DEBUG kafka-client: read Metadata v12 broker=3 bytes_read=309 err=<nil> read_wait=27.541µs time_to_read=10.920828ms
[16:08:27.412] DEBUG kafka-client: metadata refresh topic partition data changed new_leader=3 new_leader_epoch=55 old_leader=2 old_leader_epoch=54 partition=0 topic=test-topic
[16:08:27.412] DEBUG kafka-client: metadata refresh topic partition data changed new_leader=3 new_leader_epoch=51 old_leader=3 old_leader_epoch=50 partition=1 topic=test-topic
[16:08:27.412] DEBUG kafka-client: metadata refresh topic partition data changed new_leader=1 new_leader_epoch=65 old_leader=1 old_leader_epoch=64 partition=2 topic=test-topic
[16:08:27.412] DEBUG kafka-client: metadata refresh topic partition data changed new_leader=1 new_leader_epoch=57 old_leader=2 old_leader_epoch=56 partition=3 topic=test-topic
[16:08:37.110]  WARN kafka-client: unable to open connection to broker addr=<IP_ADDRESS>:9093 broker=2 err=dial tcp <IP_ADDRESS>:9093: i/o timeout
[16:08:37.110] DEBUG kafka-client: opening connection to broker addr=<IP_ADDRESS>:9093 broker=2
[16:08:47.115]  WARN kafka-client: unable to open connection to broker addr=<IP_ADDRESS>:9093 broker=2 err=dial tcp <IP_ADDRESS>:9093: i/o timeout
[16:08:47.115]  WARN kafka-client: produce partition load error, bumping error count on first stored batch batch0_should_fail=false broker=1 can_fail=false err=unable to dial: dial tcp <IP_ADDRESS>:9093: i/o timeout is_network_err=true is_retriable_kerr=false is_unknown_limit=false partition=2 topic=test-topic will_fail=false
[16:08:47.115]  WARN kafka-client: unable to AddPartitionsToTxn due to retriable broker err, bumping client's buffered record load errors by 1 and retrying err=unable to dial: dial tcp <IP_ADDRESS>:9093: i/o timeout
[16:08:47.115]  INFO kafka-client: metadata update triggered why=attempting to refresh transaction coordinator due to failed AddPartitionsToTxn requests
[16:08:47.115] DEBUG kafka-client: opening connection to broker addr=<IP_ADDRESS>:9093 broker=seed 2
[16:08:47.115] DEBUG kafka-client: wrote Metadata v12 broker=3 bytes_written=64 err=<nil> time_to_write=23.153µs write_wait=24.286µs
[16:08:47.126] DEBUG kafka-client: read Metadata v12 broker=3 bytes_read=309 err=<nil> read_wait=55.024µs time_to_read=10.929734ms
[16:08:47.126] DEBUG kafka-client: metadata refresh has identical topic partition data leader=3 leader_epoch=55 partition=0 topic=test-topic
[16:08:47.126] DEBUG kafka-client: metadata refresh has identical topic partition data leader=3 leader_epoch=51 partition=1 topic=test-topic
[16:08:47.127] DEBUG kafka-client: metadata refresh has identical topic partition data leader=1 leader_epoch=65 partition=2 topic=test-topic
[16:08:47.127] DEBUG kafka-client: metadata refresh has identical topic partition data leader=1 leader_epoch=57 partition=3 topic=test-topic
[16:08:47.141] DEBUG kafka-client: connection opened to broker addr=<IP_ADDRESS>:9093 broker=seed 2
[16:08:47.141] DEBUG kafka-client: issuing api versions request broker=seed 2 version=3
[16:08:47.141] DEBUG kafka-client: wrote ApiVersions v3 broker=seed 2 bytes_written=31 err=<nil> time_to_write=12.303µs write_wait=11.702µs
[16:08:47.155] DEBUG kafka-client: read ApiVersions v3 broker=seed 2 bytes_read=439 err=<nil> read_wait=24.045µs time_to_read=13.565245ms
[16:08:47.155] DEBUG kafka-client: connection initialized successfully addr=<IP_ADDRESS>:9093 broker=seed 2
[16:08:47.155] DEBUG kafka-client: wrote Metadata v12 broker=seed 2 bytes_written=22 err=<nil> time_to_write=11.141µs write_wait=39.749886ms
[16:08:47.167] DEBUG kafka-client: read Metadata v12 broker=seed 2 bytes_read=8598 err=<nil> read_wait=26.66µs time_to_read=11.53288ms
[16:08:47.167] DEBUG kafka-client: opening connection to broker addr=<IP_ADDRESS>:9093 broker=seed 0
[16:08:47.193] DEBUG kafka-client: connection opened to broker addr=<IP_ADDRESS>:9093 broker=seed 0
[16:08:47.193] DEBUG kafka-client: connection initialized successfully addr=<IP_ADDRESS>:9093 broker=seed 0
[16:08:47.193] DEBUG kafka-client: wrote Metadata v12 broker=seed 0 bytes_written=22 err=<nil> time_to_write=10.209µs write_wait=26.627624ms
[16:08:47.208] DEBUG kafka-client: read Metadata v12 broker=seed 0 bytes_read=8598 err=<nil> read_wait=28.273µs time_to_read=14.377755ms
[16:08:47.208] DEBUG kafka-client: sharded request destinations=[any]
[16:08:47.208] DEBUG kafka-client: opening connection to broker addr=<IP_ADDRESS>:9093 broker=1
[16:08:47.235] DEBUG kafka-client: connection opened to broker addr=<IP_ADDRESS>:9093 broker=1
[16:08:47.236] DEBUG kafka-client: connection initialized successfully addr=<IP_ADDRESS>:9093 broker=1
[16:08:47.236] DEBUG kafka-client: wrote FindCoordinator v4 broker=1 bytes_written=38 err=<nil> time_to_write=11.993µs write_wait=27.568856ms
[16:08:47.249] DEBUG kafka-client: read FindCoordinator v4 broker=1 bytes_read=58 err=<nil> read_wait=33.052µs time_to_read=13.747659ms
[16:08:47.249] DEBUG kafka-client: wrote AddPartitionsToTxn v3 broker=3 bytes_written=78 err=<nil> time_to_write=14.427µs write_wait=12.755µs
[16:08:47.264] DEBUG kafka-client: read AddPartitionsToTxn v3 broker=3 bytes_read=49 err=<nil> read_wait=38.763µs time_to_read=15.00238ms
[16:08:47.265] DEBUG kafka-client: opening connection to broker addr=<IP_ADDRESS>:9093 broker=1
[16:08:47.291] DEBUG kafka-client: connection opened to broker addr=<IP_ADDRESS>:9093 broker=1
[16:08:47.291] DEBUG kafka-client: connection initialized successfully addr=<IP_ADDRESS>:9093 broker=1
[16:08:47.292] DEBUG kafka-client: wrote Produce v9 broker=1 bytes_written=283 err=<nil> time_to_write=18.245µs write_wait=27.643396ms
[16:08:47.316] DEBUG kafka-client: read Produce v9 broker=1 bytes_read=75 err=<nil> read_wait=46.417µs time_to_read=23.328805ms
[16:08:47.316] DEBUG kafka-client: produced broker=1 to=test-topic[2{52=>53}]
[16:08:47.316]  INFO kafka-client: flushing
[16:08:47.316] DEBUG kafka-client: flushed
[16:08:47.316] DEBUG kafka-client: transaction ending, no group loaded; this must be a producer-only transaction, not consume-modify-produce EOS
[16:08:47.316]  INFO kafka-client: ending transaction commit=true epoch=0 producer_id=298002 transactional_id=developer-1-7886
[16:08:47.316] DEBUG kafka-client: wrote EndTxn v3 broker=3 bytes_written=47 err=<nil> time_to_write=18.084µs write_wait=26.44µs

Also, I've added kgo.RecordDeliveryTimeout(time.Duration(5)*time.Second)) and got:
[16:15:20.745] DEBUG server: Produce message to topic='test-topic' with key='bla-bla-bla'
[16:15:20.745]  INFO kafka-client: beginning transaction transactional_id=developer-1-8046
[16:15:20.745] DEBUG kafka-client: opening connection to broker addr=<IP_ADDRESS>:9093 broker=1
[16:15:30.752]  WARN kafka-client: unable to open connection to broker addr=<IP_ADDRESS>:9093 broker=1 err=dial tcp <IP_ADDRESS>:9093: i/o timeout
[16:15:30.752] DEBUG kafka-client: opening connection to broker addr=<IP_ADDRESS>:9093 broker=1
[16:15:40.763]  WARN kafka-client: unable to open connection to broker addr=<IP_ADDRESS>:9093 broker=1 err=dial tcp <IP_ADDRESS>:9093: i/o timeout
[16:15:40.763] DEBUG kafka-client: retrying request backoff=215.555737ms request_error=unable to dial: dial tcp <IP_ADDRESS>:9093: i/o timeout response_error=<nil> tries=1
[16:15:40.993] DEBUG kafka-client: opening connection to broker addr=<IP_ADDRESS>:9093 broker=1
[16:15:51.003]  WARN kafka-client: unable to open connection to broker addr=<IP_ADDRESS>:9093 broker=1 err=dial tcp <IP_ADDRESS>:9093: i/o timeout
[16:15:51.003] DEBUG kafka-client: opening connection to broker addr=<IP_ADDRESS>:9093 broker=1
[16:16:01.034]  WARN kafka-client: unable to open connection to broker addr=<IP_ADDRESS>:9093 broker=1 err=dial tcp <IP_ADDRESS>:9093: i/o timeout
[16:16:01.034]  WARN kafka-client: produce partition load error, bumping error count on first stored batch batch0_should_fail=true broker=1 can_fail=false err=unable to dial: dial tcp <IP_ADDRESS>:9093: i/o timeout is_network_err=true is_retriable_kerr=false is_unknown_limit=false partition=2 topic=test-topic will_fail=false
[16:16:01.034]  WARN kafka-client: unable to AddPartitionsToTxn due to retriable broker err, bumping client's buffered record load errors by 1 and retrying err=unable to dial: dial tcp <IP_ADDRESS>:9093: i/o timeout
[16:16:01.034]  INFO kafka-client: metadata update triggered why=attempting to refresh transaction coordinator due to failed AddPartitionsToTxn requests
[16:16:01.034] DEBUG kafka-client: opening connection to broker addr=<IP_ADDRESS>:9093 broker=1
[16:16:01.034] DEBUG kafka-client: opening connection to broker addr=<IP_ADDRESS>:9093 broker=2
[16:16:01.063] DEBUG kafka-client: connection opened to broker addr=<IP_ADDRESS>:9093 broker=2
[16:16:01.063] DEBUG kafka-client: issuing api versions request broker=2 version=3
[16:16:01.063] DEBUG kafka-client: wrote ApiVersions v3 broker=2 bytes_written=31 err=<nil> time_to_write=21.941µs write_wait=10.38µs
[16:16:01.080] DEBUG kafka-client: read ApiVersions v3 broker=2 bytes_read=439 err=<nil> read_wait=32.732µs time_to_read=16.942052ms
[16:16:01.080] DEBUG kafka-client: connection initialized successfully addr=<IP_ADDRESS>:9093 broker=2
[16:16:01.080] DEBUG kafka-client: wrote Metadata v12 broker=2 bytes_written=64 err=<nil> time_to_write=25.047µs write_wait=45.699045ms
[16:16:01.092] DEBUG kafka-client: read Metadata v12 broker=2 bytes_read=309 err=<nil> read_wait=47.339µs time_to_read=12.099436ms
[16:16:01.092] DEBUG kafka-client: metadata refresh topic partition data changed new_leader=3 new_leader_epoch=56 old_leader=3 old_leader_epoch=55 partition=0 topic=test-topic
[16:16:01.092] DEBUG kafka-client: metadata refresh topic partition data changed new_leader=3 new_leader_epoch=52 old_leader=3 old_leader_epoch=51 partition=1 topic=test-topic
[16:16:01.092] DEBUG kafka-client: metadata refresh topic partition data changed new_leader=2 new_leader_epoch=66 old_leader=1 old_leader_epoch=65 partition=2 topic=test-topic
[16:16:01.092] DEBUG kafka-client: metadata refresh topic partition data changed new_leader=2 new_leader_epoch=58 old_leader=1 old_leader_epoch=57 partition=3 topic=test-topic
[16:16:11.076]  WARN kafka-client: unable to open connection to broker addr=<IP_ADDRESS>:9093 broker=1 err=dial tcp <IP_ADDRESS>:9093: i/o timeout
[16:16:11.076] DEBUG kafka-client: opening connection to broker addr=<IP_ADDRESS>:9093 broker=1
[16:16:21.113]  WARN kafka-client: unable to open connection to broker addr=<IP_ADDRESS>:9093 broker=1 err=dial tcp <IP_ADDRESS>:9093: i/o timeout
[16:16:21.113] DEBUG kafka-client: retrying request backoff=209.01685ms request_error=unable to dial: dial tcp <IP_ADDRESS>:9093: i/o timeout response_error=<nil> tries=1
[16:16:21.330] DEBUG kafka-client: opening connection to broker addr=<IP_ADDRESS>:9093 broker=seed 2
[16:16:21.357] DEBUG kafka-client: connection opened to broker addr=<IP_ADDRESS>:9093 broker=seed 2
[16:16:21.357] DEBUG kafka-client: issuing api versions request broker=seed 2 version=3
[16:16:21.357] DEBUG kafka-client: wrote ApiVersions v3 broker=seed 2 bytes_written=31 err=<nil> time_to_write=13.145µs write_wait=10.83µs
[16:16:21.370] DEBUG kafka-client: read ApiVersions v3 broker=seed 2 bytes_read=439 err=<nil> read_wait=28.453µs time_to_read=13.442064ms
[16:16:21.370] DEBUG kafka-client: connection initialized successfully addr=<IP_ADDRESS>:9093 broker=seed 2
[16:16:21.370] DEBUG kafka-client: wrote Metadata v12 broker=seed 2 bytes_written=22 err=<nil> time_to_write=13.516µs write_wait=40.023922ms
[16:16:21.382] DEBUG kafka-client: read Metadata v12 broker=seed 2 bytes_read=8598 err=<nil> read_wait=26.62µs time_to_read=11.435035ms
[16:16:21.382] DEBUG kafka-client: wrote Metadata v12 broker=2 bytes_written=22 err=<nil> time_to_write=11.632µs write_wait=11.422µs
[16:16:21.397] DEBUG kafka-client: read Metadata v12 broker=2 bytes_read=8598 err=<nil> read_wait=32.531µs time_to_read=14.591277ms
[16:16:21.397] DEBUG kafka-client: sharded request destinations=[any]
[16:16:21.397] DEBUG kafka-client: opening connection to broker addr=<IP_ADDRESS>:9093 broker=3
[16:16:21.423] DEBUG kafka-client: connection opened to broker addr=<IP_ADDRESS>:9093 broker=3
[16:16:21.423] DEBUG kafka-client: issuing api versions request broker=3 version=3
[16:16:21.423] DEBUG kafka-client: wrote ApiVersions v3 broker=3 bytes_written=31 err=<nil> time_to_write=9.719µs write_wait=9.227µs
[16:16:21.436] DEBUG kafka-client: read ApiVersions v3 broker=3 bytes_read=439 err=<nil> read_wait=23.744µs time_to_read=13.513579ms
[16:16:21.436] DEBUG kafka-client: connection initialized successfully addr=<IP_ADDRESS>:9093 broker=3
[16:16:21.436] DEBUG kafka-client: wrote FindCoordinator v4 broker=3 bytes_written=38 err=<nil> time_to_write=13.606µs write_wait=39.609572ms
[16:16:21.448] DEBUG kafka-client: read FindCoordinator v4 broker=3 bytes_read=58 err=<nil> read_wait=34.625µs time_to_read=11.328895ms
[16:16:21.448] DEBUG kafka-client: wrote AddPartitionsToTxn v3 broker=2 bytes_written=78 err=<nil> time_to_write=13.205µs write_wait=13.065µs
[16:16:21.482] DEBUG kafka-client: read AddPartitionsToTxn v3 broker=2 bytes_read=49 err=<nil> read_wait=34.945µs time_to_read=33.581214ms
[16:16:21.482] DEBUG kafka-client: opening connection to broker addr=<IP_ADDRESS>:9093 broker=seed 0
[16:16:31.490]  WARN kafka-client: unable to open connection to broker addr=<IP_ADDRESS>:9093 broker=seed 0 err=dial tcp <IP_ADDRESS>:9093: i/o timeout
[16:16:31.490] DEBUG kafka-client: opening connection to broker addr=<IP_ADDRESS>:9093 broker=seed 0
[16:16:41.529]  WARN kafka-client: unable to open connection to broker addr=<IP_ADDRESS>:9093 broker=seed 0 err=dial tcp <IP_ADDRESS>:9093: i/o timeout
[16:16:41.529] DEBUG kafka-client: retrying request backoff=201.587039ms request_error=unable to dial: dial tcp <IP_ADDRESS>:9093: i/o timeout response_error=<nil> tries=1
[16:16:41.731] DEBUG kafka-client: wrote Metadata v12 broker=2 bytes_written=22 err=<nil> time_to_write=31.389µs write_wait=33.953µs
[16:16:41.745] DEBUG kafka-client: read Metadata v12 broker=2 bytes_read=8598 err=<nil> read_wait=77.066µs time_to_read=13.455518ms
[16:16:41.745] DEBUG kafka-client: wrote Metadata v12 broker=3 bytes_written=22 err=<nil> time_to_write=22.041µs write_wait=15.91µs
[16:16:41.757] DEBUG kafka-client: read Metadata v12 broker=3 bytes_read=8598 err=<nil> read_wait=37.11µs time_to_read=12.198373ms
[16:16:41.757]  INFO kafka-client: produce request failed triggering metadata update broker=1 err=unknown broker
[16:16:41.757] DEBUG kafka-client: retry batches processed should_backoff=false triggering_metadata_update=true wanted_metadata_update=true
[16:16:41.757]  INFO kafka-client: metadata update triggered why=failed produce request triggering metadata update
[16:16:41.757] DEBUG kafka-client: opening connection to broker addr=<IP_ADDRESS>:9093 broker=seed 1
[16:16:41.785] DEBUG kafka-client: connection opened to broker addr=<IP_ADDRESS>:9093 broker=seed 1
[16:16:41.785] DEBUG kafka-client: connection initialized successfully addr=<IP_ADDRESS>:9093 broker=seed 1
[16:16:41.785] DEBUG kafka-client: wrote Metadata v12 broker=seed 1 bytes_written=64 err=<nil> time_to_write=11.201µs write_wait=27.543268ms
[16:16:41.800] DEBUG kafka-client: read Metadata v12 broker=seed 1 bytes_read=309 err=<nil> read_wait=29.366µs time_to_read=15.659948ms
[16:16:41.800] DEBUG kafka-client: metadata refresh has identical topic partition data leader=3 leader_epoch=56 partition=0 topic=test-topic
[16:16:41.800] DEBUG kafka-client: metadata refresh has identical topic partition data leader=3 leader_epoch=52 partition=1 topic=test-topic
[16:16:41.801] DEBUG kafka-client: metadata refresh has identical topic partition data leader=2 leader_epoch=66 partition=2 topic=test-topic
[16:16:41.801] DEBUG kafka-client: metadata refresh has identical topic partition data leader=2 leader_epoch=58 partition=3 topic=test-topic
[16:16:41.801] DEBUG kafka-client: opening connection to broker addr=<IP_ADDRESS>:9093 broker=2
[16:16:41.829] DEBUG kafka-client: connection opened to broker addr=<IP_ADDRESS>:9093 broker=2
[16:16:41.829] DEBUG kafka-client: connection initialized successfully addr=<IP_ADDRESS>:9093 broker=2
[16:16:41.829] DEBUG kafka-client: wrote Produce v9 broker=2 bytes_written=283 err=<nil> time_to_write=12.323µs write_wait=28.500721ms
[16:16:41.911] DEBUG kafka-client: read Produce v9 broker=2 bytes_read=75 err=<nil> read_wait=34.354µs time_to_read=81.755789ms
[16:16:41.911] DEBUG kafka-client: produced broker=2 to=test-topic[2{56=>57}]
[16:16:41.911]  INFO kafka-client: flushing
[16:16:41.911] DEBUG kafka-client: flushed
[16:16:41.911] DEBUG kafka-client: transaction ending, no group loaded; this must be a producer-only transaction, not consume-modify-produce EOS
[16:16:41.911]  INFO kafka-client: ending transaction commit=true epoch=0 producer_id=299000 transactional_id=developer-1-8046
[16:16:41.911] DEBUG kafka-client: wrote EndTxn v3 broker=2 bytes_written=47 err=<nil> time_to_write=26.981µs write_wait=22.121µs
[16:16:41.934] DEBUG kafka-client: read EndTxn v3 broker=2 bytes_read=16 err=<nil> read_wait=50.706µs time_to_read=22.751648ms

I see it now, the canFailFromLoadErrs is set too early -- the batch is unable to be failed even before it is sent.

@drTr0jan can you try v1.10.2? I think the commit that references this ticket should fix the non-failing records issue.

@twmb, I've tried v1.10.2 and got old behavior likewise.
[15:46:17.808] DEBUG server: Produce message to topic='test-topic' with key='bla-bla-bla'
[15:46:17.808]  INFO kafka-client: beginning transaction transactional_id=developer-1-7818
[15:46:17.808] DEBUG kafka-client: opening connection to broker addr=<IP_ADDRESS>:9093 broker=2
[15:46:27.812]  WARN kafka-client: unable to open connection to broker addr=<IP_ADDRESS>:9093 broker=2 err=dial tcp <IP_ADDRESS>:9093: i/o timeout
[15:46:27.812] DEBUG kafka-client: opening connection to broker addr=<IP_ADDRESS>:9093 broker=2
[15:46:37.823]  WARN kafka-client: unable to open connection to broker addr=<IP_ADDRESS>:9093 broker=2 err=dial tcp <IP_ADDRESS>:9093: i/o timeout
[15:46:37.823] DEBUG kafka-client: retrying request backoff=247.540545ms request_error=unable to dial: dial tcp <IP_ADDRESS>:9093: i/o timeout response_error=<nil> tries=1
[15:46:38.076] DEBUG kafka-client: opening connection to broker addr=<IP_ADDRESS>:9093 broker=2
[15:46:48.125]  WARN kafka-client: unable to open connection to broker addr=<IP_ADDRESS>:9093 broker=2 err=dial tcp <IP_ADDRESS>:9093: i/o timeout
[15:46:48.125] DEBUG kafka-client: opening connection to broker addr=<IP_ADDRESS>:9093 broker=2
[15:46:58.127]  WARN kafka-client: unable to open connection to broker addr=<IP_ADDRESS>:9093 broker=2 err=dial tcp <IP_ADDRESS>:9093: i/o timeout
[15:46:58.127]  WARN kafka-client: produce partition load error, bumping error count on first stored batch batch0_should_fail=false broker=2 can_fail=true err=unable to dial: dial tcp <IP_ADDRESS>:9093: i/o timeout is_network_err=true is_retriable_kerr=false is_unknown_limit=false partition=2 topic=test-topic will_fail=false
[15:46:58.127]  WARN kafka-client: unable to AddPartitionsToTxn due to retriable broker err, bumping client's buffered record load errors by 1 and retrying err=unable to dial: dial tcp <IP_ADDRESS>:9093: i/o timeout
[15:46:58.127] DEBUG kafka-client: opening connection to broker addr=<IP_ADDRESS>:9093 broker=2
[15:46:58.127]  INFO kafka-client: metadata update triggered why=attempting to refresh transaction coordinator due to failed AddPartitionsToTxn requests
[15:47:08.132]  WARN kafka-client: unable to open connection to broker addr=<IP_ADDRESS>:9093 broker=2 err=dial tcp <IP_ADDRESS>:9093: i/o timeout
[15:47:08.132] DEBUG kafka-client: opening connection to broker addr=<IP_ADDRESS>:9093 broker=2
[15:47:18.186]  WARN kafka-client: unable to open connection to broker addr=<IP_ADDRESS>:9093 broker=2 err=dial tcp <IP_ADDRESS>:9093: i/o timeout
[15:47:18.186] DEBUG kafka-client: opening connection to broker addr=<IP_ADDRESS>:9093 broker=2
[15:47:18.186] DEBUG kafka-client: retrying request backoff=213.761315ms request_error=unable to dial: dial tcp <IP_ADDRESS>:9093: i/o timeout response_error=<nil> tries=1
[15:47:28.233]  WARN kafka-client: unable to open connection to broker addr=<IP_ADDRESS>:9093 broker=2 err=dial tcp <IP_ADDRESS>:9093: i/o timeout
[15:47:28.233] DEBUG kafka-client: opening connection to broker addr=<IP_ADDRESS>:9093 broker=2
[15:47:38.233]  WARN kafka-client: unable to open connection to broker addr=<IP_ADDRESS>:9093 broker=2 err=dial tcp <IP_ADDRESS>:9093: i/o timeout
[15:47:38.233] DEBUG kafka-client: opening connection to broker addr=<IP_ADDRESS>:9093 broker=2
[15:47:38.233]  WARN kafka-client: produce partition load error, bumping error count on first stored batch batch0_should_fail=false broker=2 can_fail=true err=unable to dial: dial tcp <IP_ADDRESS>:9093: i/o timeout is_network_err=true is_retriable_kerr=false is_unknown_limit=false partition=2 topic=test-topic will_fail=false
[15:47:38.483]  INFO kafka-client: metadata update triggered why=re-updating metadata due to err: unable to dial: dial tcp <IP_ADDRESS>:9093: i/o timeout
[15:47:38.483] DEBUG kafka-client: opening connection to broker addr=<IP_ADDRESS>:9093 broker=3
[15:47:38.509] DEBUG kafka-client: connection opened to broker addr=<IP_ADDRESS>:9093 broker=3
[15:47:38.509] DEBUG kafka-client: issuing api versions request broker=3 version=3
[15:47:38.509] DEBUG kafka-client: wrote ApiVersions v3 broker=3 bytes_written=31 err=<nil> time_to_write=12.844µs write_wait=10.971µs
[15:47:38.525] DEBUG kafka-client: read ApiVersions v3 broker=3 bytes_read=439 err=<nil> read_wait=25.498µs time_to_read=15.792371ms
[15:47:38.525] DEBUG kafka-client: connection initialized successfully addr=<IP_ADDRESS>:9093 broker=3
[15:47:38.525] DEBUG kafka-client: wrote Metadata v12 broker=3 bytes_written=64 err=<nil> time_to_write=14.187µs write_wait=41.709682ms
[15:47:38.536] DEBUG kafka-client: read Metadata v12 broker=3 bytes_read=309 err=<nil> read_wait=27.972µs time_to_read=11.14928ms
[15:47:38.536] DEBUG kafka-client: metadata refresh topic partition data changed new_leader=3 new_leader_epoch=58 old_leader=2 old_leader_epoch=57 partition=0 topic=test-topic
[15:47:38.536] DEBUG kafka-client: metadata refresh topic partition data changed new_leader=3 new_leader_epoch=53 old_leader=3 old_leader_epoch=52 partition=1 topic=test-topic
[15:47:38.536] DEBUG kafka-client: metadata refresh topic partition data changed new_leader=1 new_leader_epoch=67 old_leader=2 old_leader_epoch=66 partition=2 topic=test-topic
[15:47:38.536] DEBUG kafka-client: metadata refresh topic partition data changed new_leader=1 new_leader_epoch=59 old_leader=2 old_leader_epoch=58 partition=3 topic=test-topic
[15:47:48.251]  WARN kafka-client: unable to open connection to broker addr=<IP_ADDRESS>:9093 broker=2 err=dial tcp <IP_ADDRESS>:9093: i/o timeout
[15:47:48.251] DEBUG kafka-client: opening connection to broker addr=<IP_ADDRESS>:9093 broker=2
[15:47:58.311]  WARN kafka-client: unable to open connection to broker addr=<IP_ADDRESS>:9093 broker=2 err=dial tcp <IP_ADDRESS>:9093: i/o timeout
[15:47:58.311]  WARN kafka-client: produce partition load error, bumping error count on first stored batch batch0_should_fail=false broker=1 can_fail=true err=unable to dial: dial tcp <IP_ADDRESS>:9093: i/o timeout is_network_err=true is_retriable_kerr=false is_unknown_limit=false partition=2 topic=test-topic will_fail=false
[15:47:58.311]  WARN kafka-client: unable to AddPartitionsToTxn due to retriable broker err, bumping client's buffered record load errors by 1 and retrying err=unable to dial: dial tcp <IP_ADDRESS>:9093: i/o timeout
[15:47:58.311]  INFO kafka-client: metadata update triggered why=attempting to refresh transaction coordinator due to failed AddPartitionsToTxn requests
[15:47:58.311] DEBUG kafka-client: opening connection to broker addr=<IP_ADDRESS>:9093 broker=seed 2
[15:47:58.312] DEBUG kafka-client: wrote Metadata v12 broker=3 bytes_written=22 err=<nil> time_to_write=19.266µs write_wait=21µs
[15:47:58.323] DEBUG kafka-client: read Metadata v12 broker=3 bytes_read=8598 err=<nil> read_wait=47.499µs time_to_read=11.735804ms
[15:47:58.323] DEBUG kafka-client: opening connection to broker addr=<IP_ADDRESS>:9093 broker=seed 0
[15:47:58.339] DEBUG kafka-client: connection opened to broker addr=<IP_ADDRESS>:9093 broker=seed 2
[15:47:58.339] DEBUG kafka-client: issuing api versions request broker=seed 2 version=3
[15:47:58.339] DEBUG kafka-client: wrote ApiVersions v3 broker=seed 2 bytes_written=31 err=<nil> time_to_write=11.251µs write_wait=8.076µs
[15:47:58.353] DEBUG kafka-client: read ApiVersions v3 broker=seed 2 bytes_read=439 err=<nil> read_wait=23.234µs time_to_read=13.819917ms
[15:47:58.353] DEBUG kafka-client: connection initialized successfully addr=<IP_ADDRESS>:9093 broker=seed 2
[15:47:58.353] DEBUG kafka-client: wrote Metadata v12 broker=seed 2 bytes_written=64 err=<nil> time_to_write=14.868µs write_wait=41.178332ms
[15:47:58.355] DEBUG kafka-client: connection opened to broker addr=<IP_ADDRESS>:9093 broker=seed 0
[15:47:58.355] DEBUG kafka-client: connection initialized successfully addr=<IP_ADDRESS>:9093 broker=seed 0
[15:47:58.355] DEBUG kafka-client: wrote Metadata v12 broker=seed 0 bytes_written=22 err=<nil> time_to_write=10.109µs write_wait=31.324041ms
[15:47:58.364] DEBUG kafka-client: read Metadata v12 broker=seed 2 bytes_read=309 err=<nil> read_wait=31.98µs time_to_read=11.34619ms
[15:47:58.364] DEBUG kafka-client: metadata refresh has identical topic partition data leader=3 leader_epoch=58 partition=0 topic=test-topic
[15:47:58.364] DEBUG kafka-client: metadata refresh has identical topic partition data leader=3 leader_epoch=53 partition=1 topic=test-topic
[15:47:58.364] DEBUG kafka-client: metadata refresh has identical topic partition data leader=1 leader_epoch=67 partition=2 topic=test-topic
[15:47:58.364] DEBUG kafka-client: metadata refresh has identical topic partition data leader=1 leader_epoch=59 partition=3 topic=test-topic
[15:47:58.378] DEBUG kafka-client: read Metadata v12 broker=seed 0 bytes_read=8598 err=<nil> read_wait=28.343µs time_to_read=23.619045ms
[15:47:58.379] DEBUG kafka-client: sharded request destinations=[any]
[15:47:58.379] DEBUG kafka-client: opening connection to broker addr=<IP_ADDRESS>:9093 broker=1
[15:47:58.407] DEBUG kafka-client: connection opened to broker addr=<IP_ADDRESS>:9093 broker=1
[15:47:58.407] DEBUG kafka-client: connection initialized successfully addr=<IP_ADDRESS>:9093 broker=1
[15:47:58.407] DEBUG kafka-client: wrote FindCoordinator v4 broker=1 bytes_written=38 err=<nil> time_to_write=11.872µs write_wait=28.532686ms
[15:47:58.423] DEBUG kafka-client: read FindCoordinator v4 broker=1 bytes_read=58 err=<nil> read_wait=28.925µs time_to_read=16.271442ms
[15:47:58.424] DEBUG kafka-client: wrote AddPartitionsToTxn v3 broker=1 bytes_written=78 err=<nil> time_to_write=9.619µs write_wait=13.565µs
[15:47:58.466] DEBUG kafka-client: read AddPartitionsToTxn v3 broker=1 bytes_read=49 err=<nil> read_wait=34.174µs time_to_read=42.056004ms
[15:47:58.466] DEBUG kafka-client: opening connection to broker addr=<IP_ADDRESS>:9093 broker=1
[15:47:58.493] DEBUG kafka-client: connection opened to broker addr=<IP_ADDRESS>:9093 broker=1
[15:47:58.493] DEBUG kafka-client: connection initialized successfully addr=<IP_ADDRESS>:9093 broker=1
[15:47:58.493] DEBUG kafka-client: wrote Produce v9 broker=1 bytes_written=283 err=<nil> time_to_write=173.957µs write_wait=27.439357ms
[15:47:58.678] DEBUG kafka-client: read Produce v9 broker=1 bytes_read=75 err=<nil> read_wait=83.678µs time_to_read=184.521949ms
[15:47:58.678] DEBUG kafka-client: produced broker=1 to=test-topic[2{60=>61}]
[15:47:58.678]  INFO kafka-client: flushing
[15:47:58.678] DEBUG kafka-client: flushed
[15:47:58.678] DEBUG kafka-client: transaction ending, no group loaded; this must be a producer-only transaction, not consume-modify-produce EOS
[15:47:58.678]  INFO kafka-client: ending transaction commit=true epoch=0 producer_id=300000 transactional_id=developer-1-7818
[15:47:58.678] DEBUG kafka-client: wrote EndTxn v3 broker=1 bytes_written=47 err=<nil> time_to_write=27.522µs write_wait=26.299µs
[15:47:58.704] DEBUG kafka-client: read EndTxn v3 broker=1 bytes_read=16 err=<nil> read_wait=59.121µs time_to_read=25.785233ms

But, if I add kgo.RecordDeliveryTimeout(time.Duration(5)*time.Second)), I've got Rollback after 40 sec:
[15:50:28.530] DEBUG server: Produce message to topic='test-topic' with key='bla-bla-bla'
[15:50:28.530]  INFO kafka-client: beginning transaction transactional_id=developer-1-7929
[15:50:28.530] DEBUG kafka-client: opening connection to broker addr=<IP_ADDRESS>:9093 broker=3
[15:50:38.544]  WARN kafka-client: unable to open connection to broker addr=<IP_ADDRESS>:9093 broker=3 err=dial tcp <IP_ADDRESS>:9093: i/o timeout
[15:50:38.544] DEBUG kafka-client: opening connection to broker addr=<IP_ADDRESS>:9093 broker=3
[15:50:48.555]  WARN kafka-client: unable to open connection to broker addr=<IP_ADDRESS>:9093 broker=3 err=dial tcp <IP_ADDRESS>:9093: i/o timeout
[15:50:48.555] DEBUG kafka-client: retrying request backoff=254.693435ms request_error=unable to dial: dial tcp <IP_ADDRESS>:9093: i/o timeout response_error=<nil> tries=1
[15:50:48.827] DEBUG kafka-client: opening connection to broker addr=<IP_ADDRESS>:9093 broker=3
[15:50:58.833]  WARN kafka-client: unable to open connection to broker addr=<IP_ADDRESS>:9093 broker=3 err=dial tcp <IP_ADDRESS>:9093: i/o timeout
[15:50:58.833] DEBUG kafka-client: opening connection to broker addr=<IP_ADDRESS>:9093 broker=3
[15:51:08.889]  WARN kafka-client: unable to open connection to broker addr=<IP_ADDRESS>:9093 broker=3 err=dial tcp <IP_ADDRESS>:9093: i/o timeout
[15:51:08.889]  WARN kafka-client: produce partition load error, bumping error count on first stored batch batch0_should_fail=true broker=1 can_fail=true err=unable to dial: dial tcp <IP_ADDRESS>:9093: i/o timeout is_network_err=true is_retriable_kerr=false is_unknown_limit=false partition=2 topic=test-topic will_fail=true
[15:51:08.889]  WARN kafka-client: unable to AddPartitionsToTxn due to retriable broker err, bumping client's buffered record load errors by 1 and retrying err=unable to dial: dial tcp <IP_ADDRESS>:9093: i/o timeout
[15:51:08.889]  INFO kafka-client: metadata update triggered why=attempting to refresh transaction coordinator due to failed AddPartitionsToTxn requests
[15:51:08.889]  INFO kafka-client: producer state set to aborting; continuing to wait via flushing
[15:51:08.889]  INFO kafka-client: flushing
[15:51:08.889] DEBUG kafka-client: opening connection to broker addr=<IP_ADDRESS>:9093 broker=2
[15:51:08.889] DEBUG kafka-client: flushed
[15:51:08.890] DEBUG kafka-client: aborted buffered records
[15:51:08.890] DEBUG kafka-client: transaction ending, no group loaded; this must be a producer-only transaction, not consume-modify-produce EOS
[15:51:08.890] DEBUG kafka-client: no records were produced during the commit; thus no transaction was began; ending without doing anything
[15:51:08.890]  INFO kafka-producer: Transaction rolled back

This is going to be a fun bug to repeatedly investigate 😬
I know what's happening now, but I don't know why things recovered in your first batch of logs. In your first batch of logs, did you do anything between here:
[15:47:58.311]  WARN kafka-client: unable to AddPartitionsToTxn due to retriable broker err, bumping client's buffered record load errors by 1 and retrying err=unable to dial: dial tcp <IP_ADDRESS>:9093: i/o timeout
[15:47:58.311]  INFO kafka-client: metadata update triggered why=attempting to refresh transaction coordinator due to failed AddPartitionsToTxn requests
[15:47:58.311] DEBUG kafka-client: opening connection to broker addr=<IP_ADDRESS>:9093 broker=seed 2
[15:47:58.312] DEBUG kafka-client: wrote Metadata v12 broker=3 bytes_written=22 err=<nil> time_to_write=19.266µs write_wait=21µs
[15:47:58.323] DEBUG kafka-client: read Metadata v12 broker=3 bytes_read=8598 err=<nil> read_wait=47.499µs time_to_read=11.735804ms
[15:47:58.323] DEBUG kafka-client: opening connection to broker addr=<IP_ADDRESS>:9093 broker=seed 0
[15:47:58.339] DEBUG kafka-client: connection opened to broker addr=<IP_ADDRESS>:9093 broker=seed 2
[15:47:58.339] DEBUG kafka-client: issuing api versions request broker=seed 2 version=3
[15:47:58.339] DEBUG kafka-client: wrote ApiVersions v3 broker=seed 2 bytes_written=31 err=<nil> time_to_write=11.251µs write_wait=8.076µs
[15:47:58.353] DEBUG kafka-client: read ApiVersions v3 broker=seed 2 bytes_read=439 err=<nil> read_wait=23.234µs time_to_read=13.819917ms
[15:47:58.353] DEBUG kafka-client: connection initialized successfully addr=<IP_ADDRESS>:9093 broker=seed 2
[15:47:58.353] DEBUG kafka-client: wrote Metadata v12 broker=seed 2 bytes_written=64 err=<nil> time_to_write=14.868µs write_wait=41.178332ms
[15:47:58.355] DEBUG kafka-client: connection opened to broker addr=<IP_ADDRESS>:9093 broker=seed 0
[15:47:58.355] DEBUG kafka-client: connection initialized successfully addr=<IP_ADDRESS>:9093 broker=seed 0
[15:47:58.355] DEBUG kafka-client: wrote Metadata v12 broker=seed 0 bytes_written=22 err=<nil> time_to_write=10.109µs write_wait=31.324041ms
[15:47:58.364] DEBUG kafka-client: read Metadata v12 broker=seed 2 bytes_read=309 err=<nil> read_wait=31.98µs time_to_read=11.34619ms
[15:47:58.364] DEBUG kafka-client: metadata refresh has identical topic partition data leader=3 leader_epoch=58 partition=0 topic=test-topic
[15:47:58.364] DEBUG kafka-client: metadata refresh has identical topic partition data leader=3 leader_epoch=53 partition=1 topic=test-topic
[15:47:58.364] DEBUG kafka-client: metadata refresh has identical topic partition data leader=1 leader_epoch=67 partition=2 topic=test-topic
[15:47:58.364] DEBUG kafka-client: metadata refresh has identical topic partition data leader=1 leader_epoch=59 partition=3 topic=test-topic
[15:47:58.378] DEBUG kafka-client: read Metadata v12 broker=seed 0 bytes_read=8598 err=<nil> read_wait=28.343µs time_to_read=23.619045ms
[15:47:58.379] DEBUG kafka-client: sharded request destinations=[any]
[15:47:58.379] DEBUG kafka-client: opening connection to broker addr=<IP_ADDRESS>:9093 broker=1
[15:47:58.407] DEBUG kafka-client: connection opened to broker addr=<IP_ADDRESS>:9093 broker=1
[15:47:58.407] DEBUG kafka-client: connection initialized successfully addr=<IP_ADDRESS>:9093 broker=1
[15:47:58.407] DEBUG kafka-client: wrote FindCoordinator v4 broker=1 bytes_written=38 err=<nil> time_to_write=11.872µs write_wait=28.532686ms
[15:47:58.423] DEBUG kafka-client: read FindCoordinator v4 broker=1 bytes_read=58 err=<nil> read_wait=28.925µs time_to_read=16.271442ms
[15:47:58.424] DEBUG kafka-client: wrote AddPartitionsToTxn v3 broker=1 bytes_written=78 err=<nil> time_to_write=9.619µs write_wait=13.565µs
[15:47:58.466] DEBUG kafka-client: read AddPartitionsToTxn v3 broker=1 bytes_read=49 err=<nil> read_wait=34.174µs time_to_read=42.056004ms

?
The problem is that the coordinator for your transaction is cached internally, and the cache is not cleared if the coordinator is unreachable. I can fix that -- but I'm not sure why the cache cleared in your logs. Internally, the cache is only cleared if we receive a response indicated CoordinatorNotAvailable, CoordinatorLoadInProgress, or NotCoordinator. All requests that return these errors must go to the coordinator ... which in your case, was down. Did you turn the coordinator back on?

This should be addressed with v1.10.3.


Update submitted pages

Updates to our submitted pages to:

Introduce headings to help make timescales more obvious
Promote a feedback survey rather than adding a record
Be more consistent between each other

After:

Before:

Assume there's no /survey-trn or /survey-qualification to link to.

Yep.  The hope it to later bring them in-service.


[html] auto indentation is different if the closing tag is followed by any character or whitespace.

VSCode Version: Code 1.18.0 (dcee2202709a4f223185514b9275aa4229841aa7, 2017-11-08T12:44:48.751Z)
OS Version: Linux x64 4.13.0-16-generic (also tested on Windows 10 x64).
Extensions:

Extension
Author (truncated)
Version

bracket-pair-colorizer
Coe
0.10.13

vsc-material-theme
Equ
1.1.1

beautify
Hoo
1.1.1

material-icon-theme
PKi
2.2.4

code-settings-sync
Sha
2.8.5

atom-keybindings
ms-
3.0.2

color-highlight
nau
2.3.0

stylelint
shi
0.30.0

ayu
tea
0.8.0

highlight-matching-tag
vin
0.4.4

(5 theme extensions excluded)

I ran into this bug after configuring emmet to include a comment on the same line immediately after closing tags, such as when expanding something like ".example" (using $1 to represent the cursor position):

$1

And then normally you'd hit enter and continue on, but in this case it gives the following:

    $1

Instead the expected outcome of:

    $1

After trying out a few other scenarios, it turns out the formatting will break in any situation where a closing tag has any characters after it whatsoever. Even a single trailing space after a

  will cause it to format/indent incorrectly - and not just while manually editing after expanding an abbreviation, but also when using the built-in Format Document function.
Reproduces without extensions: Yes

Verified that this works as described. However, it's also limited to this situation only as soon as there is anything
here
 the onEnter rule does not catch it.


Error after upgrade

Upgraded:
  tls_certificate_check 1.16.0 => 1.17.2

After running the app
17:02:40.766 [info] Loading 166 CA(s) from :otp store
17:02:40.878 [error] GenServer #PID<0.761.0> terminating
** (stop) {:unexpected_info, {:EXIT, #Port<0.7>, :normal}}
Last message: {:EXIT, #Port<0.7>, :normal}
State: {:state, true}
17:02:40.884 [info] Loading 166 CA(s) from :otp store

Interesting... I wonder if #Port<0.7> is the port opened to read the OS-trusted CAs.

(And thanks for reporting!)

Great! I will test and let you know.

Looks like it's working alright


Add Istanbul University

file.zip
İstanbul Üniversitesi, Türkiye
Istanbul University, Turkey

@ozlem-turk Please fork SWOT repository, copy file.zip in the root folder of your forked SWOT repository. Then unzip file.zip there with no changes to the directory structure. Then make a new pull request. If you are not able to make the pull request according the instructions, please send us an email to<EMAIL_ADDRESS>Please mention this request URL in the message. I have to close this request without merging. Thank you for your understanding.


test: Extend testautomation timeout to match classic SDL2

With the 40-second limit it times out on Debian armel (ARMv5 softfloat) autobuilders, and on some older/unsupported "ports" architectures.

I don't know for sure that this will pass on all reasonable armel machines, but the version in SDL 2.29.1 took about 1 minute on an official Debian autobuilder, so 2 minutes will probably be enough.
Of course, I would encourage anyone who is interested in actually playing a game to get better hardware - Raspberry Pi version 2 or better can run Debian armhf, which is ARMv7 hardfloat, a much more reasonable thing to be playing games on. But continuing to compile SDL on armel gives us a convenient example of an architecture where atomic instructions aren't available, so it's probably a useful stand-in for some of the embedded/console architectures that SDL can target.


where is setSwipeToDismissCallback method?

I cannot find this method in UltimateRecyclerView despite it is mentioned in wiki. I've tried to search it in github with "This repository search" and found only one mention of it at "UpcomingChanges.md". In other words it was not found in code.

found out another issue with explanation. You DO need to change wiki documentation(((


Clarify the setup with virtualenv and machida

I've added some prose after. I could copy what we have in other tutorials and just have the sink setup first followed by machida and then the source data ... but this is not for a specific example so it's unclear if we should document the entire setup (we can't assume much about the pipeline).

A first pass on #2128.

@strmpnk this looks good to me. Did you want both me and @aturley to review, or is one approval enough?
Also don't forget to include closes #2128 in the body of your commit, so the issue is closed automatically!


Persist modules bytecode to disk

Closes #1234.

@jonatanklosko Does this PR autorun doctests as mentioned in #1234?

Not yet. But that’s at the top of our todo list.

So excited!!!! This is going to be a huge feature for the academy 🙏


Migrated from an umbrel 0.5.1 testnode to 1.8, and found the following 2 hic-ups

Not sure if it's related to the umbrel move, or a general 1.8 issue
1) no output logging into /mnt/hdd/bitcoin/debug.log
admin@<IP_ADDRESS>:~ ₿ sudo systemctl status bitcoind.service
* bitcoind.service - Bitcoin daemon
     Loaded: loaded (/etc/systemd/system/bitcoind.service; enabled; vendor preset: enabled)
     Active: active (running) since Fri 2022-07-29 19:22:29 BST; 5min ago
    Process: 2032 ExecStart=/usr/local/bin/bitcoind -daemonwait -conf=/mnt/hdd/bitcoin/bitcoin.conf -datadir=/mnt/hdd/bitcoin -debuglogfile=/mnt/hdd/bitcoin/debug.log (code=exited, status=0/SUCCESS)q

I've restarted bitcoind and the node several times, but can't get bitcoin to write the log
admin@<IP_ADDRESS>:~ ₿ sudo tail -n 30 -f /mnt/hdd/bitcoin/debug.log
tail: cannot open '/mnt/hdd/bitcoin/debug.log' for reading: No such file or directory
tail: no files remaining
admin@<IP_ADDRESS>:~ ₿ ls -la /mnt/hdd/bitcoin/
total 14844
drwxrwxr-x  5 bitcoin bitcoin    4096 Jul 29 19:22 .
drwxr-xr-x 13 root    root       4096 Jul 29 19:18 ..
-rw-rw-r--  1 bitcoin bitcoin       0 Jan 19  2021 .gitkeep
-rw-------  1 bitcoin bitcoin  224355 May 26  2021 banlist.dat
-rw-------  1 bitcoin bitcoin      34 May 26 22:21 banlist.json
-rw-r--r--  1 bitcoin bitcoin     745 Jul 29 13:25 bitcoin.conf
drwx------  3 bitcoin bitcoin  184320 Jul 29 17:07 blocks
drwx------  2 bitcoin bitcoin  114688 Jul 29 19:29 chainstate
-rw-------  1 bitcoin bitcoin       0 Feb 25  2021 db.log
-rw-------  1 bitcoin bitcoin  247985 Jul 29 19:18 fee_estimates.dat
drwx------  4 bitcoin bitcoin    4096 Feb 25  2021 indexes
-rw-------  1 bitcoin bitcoin 8754466 Jul 29 19:18 mempool.dat
-rw-------  1 bitcoin bitcoin      99 Jul 29 19:22 onion_v3_private_key
-rw-------  1 bitcoin bitcoin 4137648 Jul 29 19:18 peers.dat
-rw-r--r--  1 bitcoin bitcoin       4 Jul 29 19:20 settings.json
-rw-------  1 bitcoin bitcoin 1490944 Feb 24 11:55 wallet.old.bak

2) auto-unlock shows cleartext in the menu

then I get prompted to enter PASSWORD C, but it's in cleartext

and I'm uncertain why a node-reboot is necessary after activating auto-unlock. Shouldn't it be sufficient to sudo systemctl restart lnd.service?

It's 3 hic-ups:
Auto-unlock doesn't work
Apparently the cleartext password entry and reboot didn't work out properly. Will dig in further but here's a first screenshot after the reboot

Thanks for the report. The auto-unlock is basically storing your wallet password c in cleartext on the HDD - thats the security compromise. So displaying it in cleartext in the SSH menu was a design choice - its quicker to spot a typo.
Autounlock funxction is a task on our to fix list for next release - see #2356
Will keep open this issue until we have the first release candidates of next version to test if I can reproduce the "no output logging into /mnt/hdd/bitcoin/debug.log" on migration test umbrel -> raspiblitz
thx for the report.


Method to check subtitles support of playback

Maybe it is worth to add a new method to check if playback supports subtitles thus other playbacks can override it.
Currently, it can be done by overriding isHTML5Video, but I think it should have a more appropriate name for this, e.g. isSupportSubtitles.
And for html5 video playback this code will be:
get isSupportSubtitles () {
  return this.isHTML5Video
}

_checkForClosedCaptions () {
  if (this.isSupportSubtitles && !this._ccIsSetup) {
    ...
  }
}

@andrefilimono just to be sure, do you need to know  : if a playback can "maybe" have some subtitles ? or if there are some subtitles with  source ?
For subtitle availability, there is a PLAYBACK_SUBTITLE_AVAILABLE event. (listen by internal CC plugin).
This is because for some source, playback do not know immediatly if there are subtitles, but only after video has started to play (for example captions embeded in hls source).
Also a method could be added in Playback base class (override by playback class) which return a boolean to indicate if playback handle closed caption. (for example: canHandleSubtitles() )

@kslimani Thanks for your answer!
I was talking about a method that indicates if playback can handle closed captions.


Exported PDF does not display images from the public directory

Describe the bug
A slidev export command does not insert local images from the public directory in the generated PDF file.
To Reproduce
Steps to reproduce the behavior:

Create a file test.md with the following content:

---
theme: default
class: 'text-center'
highlighter: shiki
lineNumbers: false
drawings:
  persist: false
css: unocss
---

# TEST

---
layout: center
---

<img src="/test.jpg" />

Add an arbitrary image file public/test.jpg.
Export slides to PDF:

$ slidev export test.md

Expected Result
A file test-export.pdf contains two pages:

A page with the title "TEST".
A page with an image public/test.jpg.

Actual Result
A file test-export.pdf contains two pages:

A page with a title "TEST".
A blank page.

Desktop (please complete the following information):

OS: macOS 13.1
Browser: Brave Version 1.46.144 Chromium: 108.0.5359.128 (Official Build) (x86_64)
Slidev version: 0.38.3

I Just tried and I don't have any issue with public images in export.
Can you check your image does not overflow the slide (the print feature of browsers will try to render the image in a new "page" if the image is overflowing).
Or maybe can you provide a concrete example ?

@tonai, thanks for your suggestion!
Indeed, my image in question appeared to be too big. After I resized my JPG file, the generated PDF file has a picture on the second slide.


upgrade classification to beta7

When you added a new program / programs , put a cross on the  OS that you have test it on

(Example: [ X ] Windows  )
[ X ] Windows
[  ] Linux Ubuntu
[  ] Mac
[  ] Others  (State here -> xxx )
Assign a reviewer to review your code.

File: dl4j-cv-labs/src/main/java/ai/certifai/solution/classification/transferlearning/EditLastLayerOthersFrozen.java
After the training ended, this error occured.


Run commands with options

Right now, with the feature introduced by #56 we can't run commands that have options without using the -- separator.
$ dock-cli run -s authenticator app/console doctrine:schema:update --dump-sql

  [RuntimeException]
  The "--dump-sql" option does not exist.

run [-s|--service SERVICE] [--] [<service_command>]...

While this command will work:
$ dock-cli run -s authenticator -- app/console doctrine:schema:update --dump-sql

We may want to be able to run commands even without the --.

Tweaking the Symfony's Console component for that is maybe to much, the -- usage is not a big problem for now.


[FEATURE] Edit this page

Describe the feature you want

Feature 1: It would be great to add a link or button where clicking on the source code file is linked so that it can be edited similar to what is shown in readthedocs.io:

It should go in the bottom section where it says "Read Markdown" or next to the commit hash:

The url should be configurable in config.toml:
edit_url = "https://github.com/HEIGE-PCloud/DoIt"

Also you might need more information to generate the url, for example mkdocs adds the edit_uri parameter: https://www.mkdocs.org/user-guide/configuration/#edit_uri
For example for the post: https://hugodoit.pages.dev/basic-markdown-syntax the link should be https://github.com/HEIGE-PCloud/DoIt/edit/main/exampleSite/content/posts/basic-markdown-syntax/index.en.md from which it follows that 3 parameters are needed:

repo_url: https://github.com/HEIGE-PCloud/DoIt
edit path: edit/main
relative path: exampleSite/content/posts/basic-markdown-syntax/index.en.md

FORMAT: {repo_url}/{edit_path}/{relative_path}
In bitbucket the format is: https://bitbucket.org/user/repo/src/master/{filename}?mode=edit
so the most generic thing should be:
FORMAT: {repo_url}/{pre}/{relative_path}/{pos}
Maybe you should use the "gitRepo" field and add the extra fields under "params":
https://github.com/HEIGE-PCloud/DoIt/blob/731d671d5532b21e2d2556984aa9a2d9f1a58d53/exampleSite/config.toml#L505-L531
Useful reference

https://discourse.gohugo.io/t/how-to-implement-edit-this-page-on-github/1166
https://docs.readthedocs.io/en/stable/guides/remove-edit-buttons.html
https://www.mkdocs.org/user-guide/configuration/#edit_uri

I think I can use the same approach as Template in social.yml
https://github.com/HEIGE-PCloud/DoIt/blob/95f0401aa6e87d0f0fb972b0c3fbfc0d4e7ca98d/assets/data/social.yml#L89-L95
The user sets up one field
edit_path = https://github.com/HEIGE-PCloud/DoIt/edit/main/%v
# https://bitbucket.org/user/repo/src/master/%v?mode=edit
# https://gitlab.com/user/repo/-/edit/master/%v

and %v will be replaced by relative_path using printf.

@HEIGE-PCloud You are great, I love your idea


Generate the XRDs using Go structs with KubeBuilder

Context
Problem:
The XRD spec contains an API scheme (parameters, status etc) that is pretty much native Kubernetes OpenAPI scheme. Manually maintaining this scheme is error prone. I've looked around and didn't find a tool in https://openapi.tools/ that covers the case at hand.
Idea:
Kubernetes Operators today are built with Kubebuilder, a code generator for building CRDs. The CRDs also follow the OpenAPI scheme.
We could setup some boilerplate and setup the Types and Fields in Go structs (see https://github.com/vshn/provider-cloudscale/blob/f68758cc396358852ba09a0c9ff3b5a3ad877521/apis/cloudscale/v1/bucket_types.go) and let KubeBuilder/go generate generate the API.
That creates a CRD though, but with some yq/Go/jsonnet magic we can basically copy the generated scheme from the CRD into the XRD.
Alternatives

Maybe there are already existing tools that I missed?

Go-Swagger can create openapi from code: https://goswagger.io/use/spec/model.html
But it will also generate a lot of other stuff we don't need. So going through kubebuilder seems the better option IMHO.

I would only consider KubeBuilder, as that's the only generator that pretty much guarantees a scheme that Kubernetes understands. (for example, special flags for type handling, see https://book.kubebuilder.io/reference/markers/crd-processing.html)
As we've built a bunch of Operators by now, we have plenty of experience with Kubebuilder, so the initial setup should be fairly easy.

First implementation done, see https://github.com/vshn/component-appcat/blob/cef1e368fd00d0b848052b904066c43b4ad2ad69/apis/v1/objectstorage_types.go as an example


Change transaction handling on scanning to avoid running out DB datapool connections

Situation
We have often problems with database datapool connections (Hikari Pool problems).
One of the follow up problems is, that the running state of some SecHub jobs is not updated correctly!
So we got sometimes "Zombie" jobs which are still in running state while the executed product has still finished the scan
So admins need to restart the job which will fetch the results from product and handle the running state again.
Wanted
We do not want to have such problems at all - there should be no problems with database transaction pooling.
Hypotheses
Hypothese 1: Scan service transaction handling
The scan service does currently uses "normal" spring boot transaction handling - so when the service has been called, the transaction will be used as long as the service call does not return the result.
Hypothese 2: Spring Boot Batch framework
Another idea would be that spring boot batch does block transactions while "spring batch job" is running.
(But this is not so realistic)
Solution
We concentrate on Hyptheses 1 and use no longer Spring Boot standard transaction handling but instead use the entity manager from JPA directly and do only very short transaction handling inside scan thread.

For Postgres, you can checlk the used connections, you can use this snippet to get a live view of the used connections
watch -n 10 "psql -c \"select count(*),client_addr from pg_stat_activity where application_name like '%JDBC Driver' group by client_addr order by client_addr;\""

Hmm... ScanExecutionTasklet.java executeSafe() method is running in transaction of Spring Batch job... If we would simply create a new Thread here and directly return RepeatStatus.FINISHED this should close the batch job transaction.
All other parts seem to use @Transactional(propagation = Propagation.REQUIRES_NEW) and do only short operations - so the transactions will be closed very soon.

Some additional SQL scripts

Show all virtualxid entries - means running transactions in PostgreSQL
select * from pg_locks pl where pl.locktype like '%virtualxid%'

...

Because testcontainer do always start with IP <IP_ADDRESS> everybody inside the same network can have access to the database when the default test credentials are used (testcontainer do always have user test and password test!
There are workarounds possible to mitigate

local firewalls or
set default IP from <IP_ADDRESS> to <IP_ADDRESS> - see https://forums.docker.com/t/can-i-change-the-default-ip-from-0-0-0-0-when-binding/30358/3
turn off the ryuk sidecar container (but database shutdown would be not so simple)

All of these solutions do not automatically protect a developer who wants to simply test a postgresql connection or are cumbersome workarounds. Hopefully this will be fixed in future inside the testcontainer project.
But to prevent security problems when somebody uses this for development and does not think about the situation (so doing no preventions ) we will do following:

insist on a strong password when password is defined
create a randomized passsword for integration tests when no password is defined -
the password will be available in info files, which will can be used in #716 to setup variables, so generated credentials are known at execution time
warn inside test container logs about the problem

Hmm.. i have concerns about the usage of <IP_ADDRESS> at all. Maybe we should remove testcontainer and  support just a docker file with alpine and preconfigured postgres instead by a bash script and call this by the Java wrapper instead. The script will only expose <IP_ADDRESS>:$exposedPort.
So we

would have a secure solution
can remove the warning parts in logs
could easily access/change postgresql configuration


For Autosar classic platform release R4.2.0 and R4.2.1, I am not getting the schema version of it. Can anyone help?

There are specific schema version for each classic platform versions for example:
Classic platform release       Schema versions
R4.3.0                                    AUTOSAR_00042
In the same way, I am not getting schema version of R4.2.0

this is the refernce for the issue

as far as I am aware, for the functionality relevant to cantools there is basically no difference between any of the AUTOSAR 4.x (and newer) releases. It seems that AUTOSAR redesigned their website which lead to them currently not providing the documents for AUTOSAR classic versions older than 4.3.1. But as said, any of the versions which they currently still provide should be fine regarding all cantools functionality.


Reproducible benchmark code?

Is the code used to produce the numbers in the readme available somewhere? Based on the methodology described, it seems likely that triehash is benefiting significantly from (unrealistically favourable) branch prediction:

... each hash function was run 1,000,000 times for each word

See https://github.com/julian-klode/hashbench

Needs access to the Debian porter boxes, and probably updates for changes there, to run the entire thing; but can also run locally (make run).

Not sure how you'd test that differently, though, you do need to run the function a lot to get usable results.

Thanks for the pointers. I just wanted to see how unpredictable inputs would change the results.
To make it fair and avoid adding overhead to the loop, I was thinking the best way would be to pre-compute an array of randomly selected (known) words and use words[iteration % ARRAY_SIZE(words)] as the input. Otherwise the branch predictor is getting perfect conditions for most of the 1,000,000 iterations.

Won't that be affected too much by data caches?

It'll increase cache pressure I guess, but not by much for a small array.


Headless builds: No support for error popups/dialogs

Things like EditorNode::immediate_confirmation_dialog:
https://github.com/godotengine/godot/blob/34f6572bdf0cd2d16d3ee9d265a4bc9e7acfb76f/editor/editor_node.cpp#L4877
...currently don't handle headless mode at all, which is problematic as they are in some cases used for critical information, errors and even to confirm required editor restarts.
Currently, in headless mode, this just leads to that information being quietly supressed.
(One example is the popup for restarting/quitting the editor if new GDExtensions are detected: https://github.com/godotengine/godot/issues/53163)

Should a compile-time define be able to handle this by using ERR_PRINT() instead of displaying a message in the editor?

Should a compile-time define be able to handle this by using ERR_PRINT() instead of displaying a message in the editor?

Headless builds are no longer separate builds in 4.0, it's just a --headless flag. So a compile-time define wouldn't be so nice, it should indeed rely on something like Engine::get_singleton()->is_headless() (or an equivalent check via DisplayServer?).

One open question is what to do when there are multiple choices possible. I think the dialog should always be confirmed in headless mode. This is likely done by pressing the get_ok() button by code.

I wonder whether we should do that by default or exit with an error unless an additional CLI arg is given (--headless-confirm?) to avoid nasty surprises?

I am concerned about adding a different mode that needs to be tested.
Headless is a separate mode and gets less amounts of testing already.

This issue bit me today. I spent several hours trying to figure out how to accept a dialog prompt when running in headless mode in CI (otherwise it hangs indefinitely). Eventually I tracked it down to the .godot/extension_list.cfg being missing (adding it works around the dialog prompt issue). It would be nice if there were some sort of "accept-all" option to go with headless mode or if it were implicit in headless mode (there could be a logged message about the acceptance for traceability).

I think this is causing an issue with a --headless godot export I'm doing in a CI flow. The main thread seems to be blocked on this dialog:
(gdb) bt
#0  0x0000746881607385 in __GI___clock_nanosleep (clock_id=clock_id@entry=0, flags=flags@entry=0, req=0x7ffcca642640, rem=0x7ffcca642650) at ../sysdeps/unix/sysv/linux/clock_nanosleep.c:48
#1  0x000074688160bc93 in __GI___nanosleep (req=<optimized out>, rem=<optimized out>) at ../sysdeps/unix/sysv/linux/nanosleep.c:25
#2  0x00005eb47b367f90 in OS_Unix::delay_usec (this=<optimized out>, p_usec=<optimized out>) at drivers/unix/os_unix.cpp:283
#3  0x00005eb47dd87a3e in OS::add_frame_delay (this=this@entry=0x7ffcca642c60, p_can_draw=<optimized out>) at core/os/os.cpp:591
#4  0x00005eb47a59a9a2 in Main::iteration () at main/main.cpp:3717
#5  0x00005eb47b616b88 in EditorNode::immediate_confirmation_dialog (p_text=..., p_ok_text=..., p_cancel_text=..., p_wrap_width=p_wrap_width@entry=0) at editor/editor_node.cpp:5589
#6  0x00005eb47b572ffe in EditorFileSystem::_update_scan_actions (this=this@entry=0x5eb481d81db0) at editor/editor_file_system.cpp:675
#7  0x00005eb47b574114 in EditorFileSystem::_notification (this=0x5eb481d81db0, p_what=<optimized out>) at editor/editor_file_system.cpp:1282
#8  0x00005eb47e2440a0 in Object::notification (this=0x5eb481d81db0, p_notification=17, p_reversed=<optimized out>) at core/object/object.cpp:837
#9  0x00005eb47c495bbf in SceneTree::_process_group (this=0x5eb481cabe70, p_group=0x5eb481cac0c8, p_physics=false) at scene/main/scene_tree.cpp:951
#10 0x00005eb47c4962c8 in SceneTree::_process (this=this@entry=0x5eb481cabe70, p_physics=p_physics@entry=false) at scene/main/scene_tree.cpp:1028
#11 0x00005eb47c4968c2 in SceneTree::process (this=0x5eb481cabe70, p_time=0.0055555555555555549) at scene/main/scene_tree.cpp:508
#12 0x00005eb47a59a5d5 in Main::iteration () at main/main.cpp:3634
#13 0x00005eb47a530131 in OS_LinuxBSD::run (this=this@entry=0x7ffcca642c60) at platform/linuxbsd/os_linuxbsd.cpp:933
#14 0x00005eb47a51f78b in main (argc=<optimized out>, argv=0x7ffcca643238) at platform/linuxbsd/godot_linuxbsd.cpp:74

The trouble with auto-confirming a restart prompt is that in a typical headless scenario like a CI script, there's now a new orphan editor process you have to find and wait for, which is pretty awkward (unless there's an easy solution I'm missing).
It might be better to simply exit with a certain error code rather than restarting when headless.

It might be better to simply exit with a certain error code rather than restarting when headless.

The issue is, we need to define an universal solution for all AcceptDialogs and ConfirmationDialogs. I don't see a way to provide more granular behavior that would allow simply exiting the editor (without restarting it) when there's a ConfirmationDialog that proposes quitting and restarting the editor.

Agreed, currently I have to handle a fresh git clone of the project in the build script by running godot-mono --headless --import-only, waiting 60 seconds, sending it a SIGTERM, and writing a marker file (to check on subsequent runs to avoid doing this each time). Then the script carries out the export as usual. This will give the server enough time to "show" the confirmation dialog, at which point it has already stored the necessary information to start up properly next time, so killing it and restarting manually (even without clicking the dialog) works.
This is obviously not a desired workflow...


Add support for importing email templates

🔧 Changes
This adds support for importing email templates into terraform from an existing auth0 install.
This is helpful because if you are onboarding your terraform, you don't have to manually create the resources for the email templates.
🔬 Testing
Go into your auth0 install and set a custom template for one of the templates (for this example, I'm doing reset email)
Run the auth0 cli terraform import to create the auth0_generated.tf file
Note that in the auth0_generated.tf, you have the following block with the pasrameters you set in the auth0 portal populates correctly
resource "auth0_email_template" "reset_email" {
  body                      = "the contents of the email you set up"
  enabled                   = true
  from                      = "Foo<EMAIL_ADDRESS>  include_email_in_redirect = false
  result_url                = null
  subject                   = ""
  syntax                    = "liquid"
  template                  = "reset_email"
  url_lifetime_in_seconds   = 432000
}

📝 Checklist

[x] All new/changed/fixed functionality is covered by tests (or N/A)
[x] I have added documentation for all new/changed functionality (or N/A)

Hi @weirdian2k3,
I hope you're having a nice day! I'm looking through your PR, but it requires test cases. If you can add test cases or need help with that, please let me know.
Thank you for the contribution!

Hi @weirdian2k3,
I hope you are having a great day.
I have added the necessary documentation and test cases. Could you please merge this branch with yours or open a new PR with these changes?
Here's the link to the branch: GitHub Branch
Thank you!


Cannot find an overload for "TryParce" and the argument count: "4"

After upgrading from 5.0.0 to 5.1.0 the following code is failing, and wasn't failing before:
$Error.Clear()

Workflow Test-HomeDriveAvailableHC {
    Param (
        [String[]]$ComputerName
    )
    Foreach -parallel($C in $ComputerName) {
        InlineScript {
            $Result = Invoke-Command -ComputerName $Using:C -ScriptBlock {
                Test-Path -Path E:/*HOME* -PathType Container
            } -EA Stop
        }
    }
}

Test-HomeDriveAvailableHC -ComputerName NotExisting

$Error.Exception | Export-Excel -Path "$env:TEMP.xlsx"

Failed exporting data to worksheet 'Sheet1' to 'C:\Temp\3.xlsx': Cannot find an overload for "TryParse" and the argument count: "4".

However, when changing it too $Error.Exception.Message | Export-Excel -Path "$env:TEMP.xlsx" the problem is fixed.

Hi I've just tried
1/0                                                                                del  notthere
Invoke-Command -ComputerName "Notexisiting" -Credential (get-credential) -ScriptBlock {Test-Path "E:\" }
$error.exception  | Export-Excel

And that processes as expected.
Can you try this with the error you're trying to export ; All one line, if it works, export should also work.
$number = $null ; foreach ($e in $Error.exception)  {"------" ; foreach ($p in $e.psobject.properties.name) {if ( $e.$P -is [system.valueType] -and $e.$p -is [System.DateTime])    {"Property  $p is a value or date"} else   {"Property $p becomes number: " +  [Double]::TryParse($e.$p, [System.Globalization.NumberStyles]::Any, [System.Globalization.NumberFormatInfo]::CurrentInfo, [Ref]$number)}  }}

I tried Invoke-Command on its own, and that isn't a problem. It only happens whit that specific Workflow and the error it generates.

If there is only one error record you're trying to process, can you put this in before the if
$p ; $e.$p.getType().fullname.
That should show what in that error record which causes tryparse to throw.  It might be as simple as doing $error.exception | export-excel -excludeProperty <>

Thanks for the help. When I try this:
$Error.Clear()
Test-HomeDriveAvailableHC -ComputerName NotExisting

$number = $null
foreach ($e in $Error[0].exception) {
    "------"
    foreach ($p in $e.psobject.properties.name) {
        $p
        $e.$p.getType().fullname
        if ($e.$P -is [system.valueType] -and $e.$p -is [System.DateTime]) {
            "Property $p is a value or date"
        }
        else {
            "Property $p becomes number: " + [Double]::TryParse($e.$p, [System.Globalization.NumberStyles]::Any, [System.Globalization.NumberFormatInfo]::CurrentInfo, [Ref]$number)
        }
    }
}

It looks the problem is not in error[0] when you did that last one.  Can you just try with $error.Exception

The problem is with the SerializedRemoteException   and SerializedRemoteInvocationInfo properties so for now run Export-excel with
-ExcludeProperty "SerializedRemoteInvocationInfo", "SerializedRemoteException"
I've added a trap properties which cause errors and rather than throwing an error (and potentially losing data) it now sends the user a warning and tries to carry on.  It's my latest PR and on my branch if you want to see if it works  (without excludeProperty)

That seems logical. Thanks for sharing the problem and a workaround. It would be great if you could submit your PR to @dfinke his repo. For now, as a workaround, I just use $Error.Exception.Message.

That commit goes into an existing PR :-)


Add Estimated transaction fee to order ticket

https://www.figma.com/file/fLWVwmanAwetVZbujQquEi/Market-Page?node-id=3187%3A19884
See any notes from Chwy below

Make sure Estimated fee and TX fee are not deducted from profit (currently estimated fee is deducted)

Currently discussing all fees....design might change...dont work till i ok

notes:
from order form perspective, ZeroX trading Summary:
create open order (no transaction/gas fees)
make trade (0xfee/transaction fee/gas fee)
cancel open order (has transaction/gas feee)
order expiration (no transaction/gas fees)
closing a position (market settlement fee and transaction/gas fee/0x fee)
0xfee is 150kgas * gasPrice -- so our estimate can have that tacked on for display
use this gas amount for transaction fee.

@bthaile for comments or questions how this will work


Accept hex string instead of individual bytes in protect transform config

Closes #510

Yup agreed something like base64 would be good in this case

Just base64 orr the ability to accept both base64 and hex?

I havent looked closely at this but in general I would prefer to only support a single format, otherwise we have to maintain both formats forever.

i think base64 is probably the way to go... please double check how you get keys out of AWS + whether openssl supports key export in that format (as the swiss army knife of working with crypto) and if that looks right lets go with that

i think base64 is probably the way to go... please double check how you get keys out of AWS + whether openssl supports key export in that format (as the swiss army knife of working with crypto) and if that looks right lets go with that

AWS uses base64 in places where binary won't work: (needs to be printed, or in JSON)
https://docs.aws.amazon.com/kms/latest/APIReference/API_GenerateDataKeyPair.html

When you use the HTTP API or the AWS CLI, the value is Base64-encoded. Otherwise, it is not Base64-encoded.

BTW, the base64 crate is already a dependency.


Vagrant Test Fails

I didn't try installing via NPM but followed instructions to test with vagrant.  Got an error, also tried installing nodegit inside the vagrant vb, both before and after install nodegit I got the following error:
vagrant@vagrant-ubuntu-trusty-64:~/bootstrap$ git hours
module.js:338
    throw err;
          ^
Error: Cannot find module '../build/Debug/nodegit.node'
    at Function.Module._resolveFilename (module.js:336:15)
    at Function.Module._load (module.js:278:25)
    at Module.require (module.js:365:17)
    at require (module.js:384:17)
    at Object.<anonymous> (/usr/lib/node_modules/git-hours/node_modules/nodegit/dist/nodegit.js:18:12)
    at Module._compile (module.js:460:26)
    at Object.Module._extensions..js (module.js:478:10)
    at Module.load (module.js:355:32)
    at Function.Module._load (module.js:310:12)
    at Module.require (module.js:365:17)
    at require (module.js:384:17)
    at Object.<anonymous> (/usr/lib/node_modules/git-hours/src/index.js:4:11)
    at Module._compile (module.js:460:26)
    at Object.Module._extensions..js (module.js:478:10)
    at Module.load (module.js:355:32)
    at Function.Module._load (module.js:310:12)

+1

I installed via npm v4.2.0 on OSX 10.12.4 and got the same.

Same happens to me as well
macOS Sierra (10.12.5)
npm 5.0.3
node v8.0.0

Had the same problem, and have found a work around:

Install nodegit manually (run npm install -g nodegit [as an administrator / i.e. sudo or cmd with admin privileges])

Locate the node_modules root directory (should now include both nodegit and git-hours). Navigate into nodegit's build folder and copy the release folder. Now navigate to the node_modules/git-hours folder, and then to git-hour's node_modules folder (which will contain a nodegit folder). Replace the git-hours\node_modules\nodegit\build\Release folder with the Release folder from node_modules\nodegit\build\Release. Furthermore, copy the folder again to the same directory, but this time name it Debug, not Release.

3). Try running git hours again, from within your chosen git repo.

@PhilAlton Many thanks, this works for me as well! (not using Vagrant, simply the npm install for git-hours and nodegit)

Vagrant setup is now out of scope for this repo, updated the instructions.