text:
Added listener on escape key to close tooltips

Description

As per issue #39692 I added a listener for all tooltips to close on keyup event of the escape key
Motivation & Context

Type of changes

[ ] Bug fix (non-breaking change which fixes an issue)
[x] New feature (non-breaking change which adds functionality)
[ ] Refactoring (non-breaking change)
[ ] Breaking change (fix or feature that would change existing functionality)

Checklist

[x] I have read the contributing guidelines
[x] My code follows the code style of the project (using npm run lint)
[ ] My change introduces changes to the documentation
[ ] I have updated the documentation accordingly
[x] I have added tests to cover my changes
[x] All new and existing tests passed

Live previews

https://deploy-preview-39753--twbs-bootstrap.netlify.app/

Related issues
Closes #39692

@TommasoAllegretti please make sure tests pass locally.

Also, what if there is another component open that closes with the Escape key too like a Modal?

@XhmikosR yes, all 804 tests pass locally when running npm run test, is there something I could be doing wrong?
To answer your question, in case a Tooltip and a Modal are open at the same time I would expect both of them to to be dismissed by pressing the Escape key.

To answer your question, in case a Tooltip and a Modal are open at the same time I would expect both of them to to be dismissed by pressing the Escape key.

ideally, that should not happen. only the tooltip should close at that point

Closing due to lack of response and due to the above comments.
Feel free to make a new PR that addresses the above comments.


text:
Create a semi-automated release script

Because this really shouldn't be manual ideally.
This script was used for guidance with the https://hackage.haskell.org/package/webauthn-0.2.0.0 release

I think just running the commands cabal sdist and cabal haddock --haddock-for-hackage and inspecting the results is good enough for that, which just checks that it builds, which CI should do already. And things like the release commit, branch push, tag, cabal version field should be updated by the same person doing the release.

Sounds good, I called it release-candidate instead (we should keep the word "release" in there)

source: gharchive/pull-request

repo: tweag/webauthn

license_type: permissive

license_source: github-api


text:
Modems broken by Create contraptions

Description
Modems broken by Create contraptions. Modems break by being turned into the entity / block state from the Create mod contraptions.
This issue has been reported and experience by a lot of other players. See thoses posts :
https://github.com/Creators-of-Create/Create/issues/4959
https://github.com/cc-tweaked/CC-Tweaked/issues/948
To Reproduce

Make a contraption with modem glued to it.
Move or turn the contraption so that it becomes an entity.
Turn the contraption back into blocks.

Result : Modems broke
Expected behavior
Modems not breaking off contraptions.
To resolve issue
Ok, so I have a pretty clear idea on why this is happening. Create uses the block tag "create:brittle" to indicate to it's contraption that objects such as redstone links or Valve handle should be placed last when the contraption converts back into blocks. That way blocks with the "create:brittle" have something to attach to.
Since CC:T modems (ender or wireless) don't have that "create:brittle" tag but also need to be attached to a solid block, I believe the contraption tries to place them first, therefore making them insta break / pop.
Adding this tag to modems may fix the issue. Since CCC:Bridge adds compatibility between Create and CC:T, I thought it would be a good idea to report it here.
Hope you can help,
MintTee
Software :

Minecraft Version 1.20.1
Mod Version v1.6.2b
ModLoader Fabric

Hey, thank you for this issue!
This sounds like a great idea, I didn't know about that actually.
I will look into this.

Thanks for the acknowledgment.
There is also this "create:safe_nbt" block tag which I guess tells the contraption to keep the nbt data of the blocks in order to place them with the same state. Not 100% sure though.

I found a workaround to this issue.
It's possible to use turtles on contraptions. Since they are considered a solid block, they dont need a support block (they can float mid air). Therefore, unlike modems, they wont break when turned into a contraption form or back into the block form. They will, however, shutdown and restart.
If you create a program called "startup" in the default directory and have the "shell.run("program_name")" inside it, it is possible to run any program automatically as soon as a computer / turtle restarts.
Maybe this temporary workaround can help a few people experimenting with Computer Craft on Create contraptions.

Create:safe_nbt seems to tell create that the block can have its nbt saved in a schematic without duplicating items, so not related as far as I can tell.
https://github.com/Plite7067/CreateCCModemFix I made this datapack which seems to solve the problem by adding the brittle tag as the original poster suggested. It should work for all versions necessary - I have tested that it applies the tag correctly on 1.18.2+

source: gharchive/issue

repo: tweaked-programs/cccbridge


text:
Serialization of Document and Resource level meta and link objects

The Challenge
The specification states that both the top level document and any resource may contain meta and links members. However, the deserialization here will nuke any resource specified meta or links members via the top level document's data attribute when deserializing a single resource. (e.g. jsonApi.get('posts', 1))
example 1:
data: {
  attributes:{
    someAttribute: 'a'
  },
  type: 'posts',
  id: '1'
  meta: {
    postMeta: 'some meta data for this individual post'
  }
},
meta: {
  docMeta: 'document meta'
}

Note how both the document and resource have meta members.
As of this PR: https://github.com/twg/devour/pull/24
resources are deserialized with an understanding of meta and links members. This works fine when handing a collection of resources or resources in included.
However, when defining meta data on a single resource response as shown in example 1 above,
the res-deserialize middleware will replace any resource level meta data with top level meta, or undefined no top level meta data is specified.
https://github.com/twg/devour/blob/master/src/middleware/json-api/res-deserialize.js#L35
The payload from example 1 above deserializes to the following object:
{
  id: '1',
  someAttribute: 'a',
  meta: {
    docMeta: 'document meta'
  }
}

Note how the resource level meta is replaced with the document level meta data.
example 2
data: {
  attributes:{
    someAttribute: 'a'
  },
  type: 'posts',
  id: '1'
  meta: {
    postMeta: 'some meta data for this individual post'
  }
}

The payload for example 2 deserialized to the following object:
{
  id: '1',
  someAttribute: 'a'
  meta: undefined
}

The examples above also apply to resource/document level links members.
Possible Solutions?
Change the deserialized data structure
This is a non-backwards compatible change. While it does provide an arguably more accurate data structure I would be cautious of forcing existing users to rewrite their applications.
{
  resource: {
    attributes: {},
    meta: {},
    links: {}
  },
  meta: {},
  links: {}
}

collections would continue to add meta and links attributes to the array of resources.
Use docMeta and docLinks attributes on the deserialized object
This allows backwards compatibility and help to highlight that there are document level meta and links members.
{
  attributes: {},
  meta: {},
  links: {}
  docMeta: {},
  docLinks: {}
}

collections would add docMeta and docLinks attributes to the array of resources.
Merge the meta/links for single resource documents.
Too risky as there could easily be meta or link members with identical names.
I'm currently working off a fork that utilizes docMeta and docLinks, but before considering a PR I'd like to get some feedback or alternative proposals from the maintainers.

Sorry for the delay responding to this – really appreciate the well thought out issue. We're seeing some problems around this as well (somewhat related to #27).
I'm wondering if we could do something like:

/*
*   `meta` contains the document wide meta...
*/
jsonApi.all('posts').then((posts, meta)=> {

})

/*
*   Meta on individual resources is deserialized into a `_meta` property...
*/
{
  id: '5',
  title: 'Some Post Title',
  _meta: {
    links: {...},
    page: {...}
  }
}

I'm not necessarily opposed to the notion of docMeta – would love to hear feedback from some other folks.

I've been using docMeta in our application for the time being and it certainly solves the problem, however having named attributes on an array definitely feels weird to me as a developer.
I think keeping JSONAPI's wrapper object around responses is another avenue that could be explored:
jsonApi.findAll('posts').then((doc) => {
  // doc => {
  //   data: [ ... ],
  //   meta: { ... },
  //   links: { ... }
  // }
})

jsonApi.findOne('posts', 1).then((doc) => {
  // doc => {
  //   data: { ... },
  //   meta: { ... },
  //   links: { ... }
  // }
})

It avoids renaming JSON-API fields completely, supports resource-level and document-level meta/links etc. with the expected names.
The big downside is backward compatibility and verbosity - it's a fairly significant design change from what devour currently does.

@glsignal – Love this in some ways, but also agree about the verbosity. It's so nice to just get back a simple array of flattened objects.
We're running into issues with attaching named attributes on arrays. Just simple stuff, like when you clone an object it will clear the named attributes.

Hi, guys!
What is the status of this issue?
I have similar problems, but with relationship members.
The payload that I get from the server looks something like this:
{
  "data": {
    "type": "post",
    "id": "1",
    "attributes": {
      // ... this post's attributes
    },
    "relationships": {
      "comments": {
          "links": {
            "self": "http://example.com/post/1/relationships/comments"
          }
        }
    }
  }
}

Any ideas how to include comments links in deserialized object?

Still haven't made a decision on this yet, I'll start giving it some thought this week. Tough because we ideally don't want to break the existing API.

I've been casually thinking about this one for a while since first seeing it.
This approach jsonApi.all('posts').then((posts, meta, links) => { ... - adding additional arguments for meta, links, etc. seems like the best option in here at the moment.
Taking it further, if we're shooting for full spec coverage, in what way might it make sense to add support for other possible top level fields like errors, jsonapi? (spec)

Are people still using devour or have you all moved onto another jsonapi library?
@Emerson any update on a decision moving forward for serializing meta data using devour?
I'd like to continue using devour, so my workaround for now to leverage the serializer for something like a jsonApi.update is to put the meta data in the attributes for now and let the backend handle it from there but it feels like a hack. I'd like to have it on the same level as it is in the spec.

I think people are for sure still using it – just had another PR merged and released today. I've moved jobs since I wrote this library and we're all in on Ember, so I haven't really needed it. I've just been keeping an eye on PR's and merging the ones that seam reasonable.
It's hard for me to make a definitive call on something when I'm not actually dog fooding it. If there was a consensus and pull request here I'd be happy to hit the merge button. As for this specific issue, I'm pretty open as long as it's reasonable.
Note: just looked at the NPM stats:

Thanks @Emerson I need to implement pagination as defined in the spec:
HTTP/1.1 200 OK
Content-Type: application/vnd.api+json

{
  "meta": {
    "total-pages": 13
  },
  "data": [
    {
      "type": "articles",
      "id": "3",
      "attributes": {
        "title": "JSON API paints my bikeshed!",
        "body": "The shortest article. Ever.",
        "created": "2015-05-22T14:56:29.000Z",
        "updated": "2015-05-22T14:56:28.000Z"
      }
    }
  ],
  "links": {
    "self": "http://example.com/articles?page[number]=3&page[size]=1",
    "first": "http://example.com/articles?page[number]=1&page[size]=1",
    "prev": "http://example.com/articles?page[number]=2&page[size]=1",
    "next": "http://example.com/articles?page[number]=4&page[size]=1",
    "last": "http://example.com/articles?page[number]=13&page[size]=1"
  }
}

It's a blocking problem for me, so I'll fork the repo for now and contribute back what I come up with unless there's another PR around that already solves this problem.

I've completed the updates to support top-level document errors, meta, and links on my fork of the repo, but I won't submit a PR since it required breaking changes to make it happen. If there's a way I can contribute back to the repo let me know.

I'm open to a 2.0 release and this is definitely an issue that needed to be addressed. Would love if you could throw up a quick PR so I could take a look.

Thanks @Emerson I went ahead and submitted a quick PR for you. I look forward to your feedback.

authors: Emerson danwarner glsignal isBatak randym

repo: twg/devour

license: ISC


text:
block function ignores second parameter

Asume you have a file foo.twig

  {% block product_info_1 %}
    Some stuff
  {% endblock %}

In file bar.twig you want just to output the block product_info_1

  {{ block('product_info_1', 'foo.twig') }}

Nothing will be outputed. Trying {{ block('product_info_1', 'foo.twig') is defined }} also returns false.
It seems the second argument is ignored.

Nice catch, twig.js doesn't support passing a custom template to the block() function.
For reference, it was introduced to Twig in https://github.com/twigphp/Twig/pull/2245

Reference in TwigPHP docs
TwigPHP example
twig.js example

authors: Nielio olets willrowe

license_source: bigquery


text:
Missing lodash?

I just installed this library but receive the following errors when requireing the package.

NPM v 3.10.9
My package.json file

Imported like so import { VelocityComponent } from 'velocity-react';
ERROR in ./~/velocity-react/velocity-helpers.js
Module not found: Error: Cannot resolve module 'lodash/lang/isObject' in C:\xampp\htdocs\Wizer\tools\node_modules\velocity-react
 @ ./~/velocity-react/velocity-helpers.js 4:12-43

ERROR in ./~/velocity-react/velocity-component.js
Module not found: Error: Cannot resolve module 'lodash/collection/forEach' in C:\xampp\htdocs\Wizer\tools\node_modules\velocity-react
 @ ./~/velocity-react/velocity-component.js 37:11-47

ERROR in ./~/velocity-react/velocity-transition-group.js
Module not found: Error: Cannot resolve module 'lodash/collection/forEach' in C:\xampp\htdocs\Wizer\tools\node_modules\velocity-react
 @ ./~/velocity-react/velocity-transition-group.js 46:11-47

ERROR in ./~/velocity-react/velocity-component.js
Module not found: Error: Cannot resolve module 'lodash/lang/isEqual' in C:\xampp\htdocs\Wizer\tools\node_modules\velocity-react
 @ ./~/velocity-react/velocity-component.js 38:11-41

ERROR in ./~/velocity-react/velocity-transition-group.js
Module not found: Error: Cannot resolve module 'lodash/lang/isEqual' in C:\xampp\htdocs\Wizer\tools\node_modules\velocity-react
 @ ./~/velocity-react/velocity-transition-group.js 47:11-41

ERROR in ./~/velocity-react/velocity-component.js
Module not found: Error: Cannot resolve module 'lodash/object/keys' in C:\xampp\htdocs\Wizer\tools\node_modules\velocity-react
 @ ./~/velocity-react/velocity-component.js 39:8-37

ERROR in ./~/velocity-react/velocity-transition-group.js
Module not found: Error: Cannot resolve module 'lodash/object/keys' in C:\xampp\htdocs\Wizer\tools\node_modules\velocity-react
 @ ./~/velocity-react/velocity-transition-group.js 48:8-37

ERROR in ./~/velocity-react/velocity-component.js
Module not found: Error: Cannot resolve module 'lodash/object/omit' in C:\xampp\htdocs\Wizer\tools\node_modules\velocity-react
 @ ./~/velocity-react/velocity-component.js 40:8-37

ERROR in ./~/velocity-react/velocity-transition-group.js
Module not found: Error: Cannot resolve module 'lodash/object/omit' in C:\xampp\htdocs\Wizer\tools\node_modules\velocity-react
 @ ./~/velocity-react/velocity-transition-group.js 49:8-37

ERROR in ./~/velocity-react/velocity-transition-group.js
Module not found: Error: Cannot resolve module 'lodash/collection/each' in C:\xampp\htdocs\Wizer\tools\node_modules\velocity-react
 @ ./~/velocity-react/velocity-transition-group.js 44:8-41

ERROR in ./~/velocity-react/velocity-transition-group.js
Module not found: Error: Cannot resolve module 'lodash/object/extend' in C:\xampp\htdocs\Wizer\tools\node_modules\velocity-react
 @ ./~/velocity-react/velocity-transition-group.js 45:10-41

ERROR in ./~/velocity-react/velocity-transition-group.js
Module not found: Error: Cannot resolve module 'lodash/collection/pluck' in C:\xampp\htdocs\Wizer\tools\node_modules\velocity-react
 @ ./~/velocity-react/velocity-transition-group.js 50:9-43

Check velocity-react inside your node_modules folder. A copy of lodash v3
should be in there.
On Tue, Jan 24, 2017 at 4:59 AM, Neal van der Valk <notifications@github.com

wrote:

I just installed this library but receive the following errors when
requireing the package.

NPM v 3.10.9
My package.json file
https://gist.github.com/nealoke/9911fd0ecc538ee4d964542205be31d6

Imported like so import VelocityComponent from 'velocity-react';
ERROR in ./~/velocity-react/velocity-helpers.js
Module not found: Error: Cannot resolve module 'lodash/lang/isObject' in C:\xampp\htdocs\Wizer\tools\node_modules\velocity-react
@ ./~/velocity-react/velocity-helpers.js 4:12-43
ERROR in ./~/velocity-react/velocity-component.js
Module not found: Error: Cannot resolve module 'lodash/collection/forEach' in C:\xampp\htdocs\Wizer\tools\node_modules\velocity-react
@ ./~/velocity-react/velocity-component.js 37:11-47
ERROR in ./~/velocity-react/velocity-transition-group.js
Module not found: Error: Cannot resolve module 'lodash/collection/forEach' in C:\xampp\htdocs\Wizer\tools\node_modules\velocity-react
@ ./~/velocity-react/velocity-transition-group.js 46:11-47
ERROR in ./~/velocity-react/velocity-component.js
Module not found: Error: Cannot resolve module 'lodash/lang/isEqual' in C:\xampp\htdocs\Wizer\tools\node_modules\velocity-react
@ ./~/velocity-react/velocity-component.js 38:11-41
ERROR in ./~/velocity-react/velocity-transition-group.js
Module not found: Error: Cannot resolve module 'lodash/lang/isEqual' in C:\xampp\htdocs\Wizer\tools\node_modules\velocity-react
@ ./~/velocity-react/velocity-transition-group.js 47:11-41
ERROR in ./~/velocity-react/velocity-component.js
Module not found: Error: Cannot resolve module 'lodash/object/keys' in C:\xampp\htdocs\Wizer\tools\node_modules\velocity-react
@ ./~/velocity-react/velocity-component.js 39:8-37
ERROR in ./~/velocity-react/velocity-transition-group.js
Module not found: Error: Cannot resolve module 'lodash/object/keys' in C:\xampp\htdocs\Wizer\tools\node_modules\velocity-react
@ ./~/velocity-react/velocity-transition-group.js 48:8-37
ERROR in ./~/velocity-react/velocity-component.js
Module not found: Error: Cannot resolve module 'lodash/object/omit' in C:\xampp\htdocs\Wizer\tools\node_modules\velocity-react
@ ./~/velocity-react/velocity-component.js 40:8-37
ERROR in ./~/velocity-react/velocity-transition-group.js
Module not found: Error: Cannot resolve module 'lodash/object/omit' in C:\xampp\htdocs\Wizer\tools\node_modules\velocity-react
@ ./~/velocity-react/velocity-transition-group.js 49:8-37
ERROR in ./~/velocity-react/velocity-transition-group.js
Module not found: Error: Cannot resolve module 'lodash/collection/each' in C:\xampp\htdocs\Wizer\tools\node_modules\velocity-react
@ ./~/velocity-react/velocity-transition-group.js 44:8-41
ERROR in ./~/velocity-react/velocity-transition-group.js
Module not found: Error: Cannot resolve module 'lodash/object/extend' in C:\xampp\htdocs\Wizer\tools\node_modules\velocity-react
@ ./~/velocity-react/velocity-transition-group.js 45:10-41
ERROR in ./~/velocity-react/velocity-transition-group.js
Module not found: Error: Cannot resolve module 'lodash/collection/pluck' in C:\xampp\htdocs\Wizer\tools\node_modules\velocity-react
@ ./~/velocity-react/velocity-transition-group.js 50:9-43
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/twitter-fabric/velocity-react/issues/160, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAP65aXW7PBxlY3k9hgWvidZ6zAzU85oks5rVctkgaJpZM4LsEHb
.

@finneganh it is, but still doesn't resolve the error though? :/

Are you bundling with something like webpack? Are there any plugins or
transforms running that would affect lodash?
On Tue, Jan 24, 2017 at 10:36 AM Neal van der Valk notifications@github.com
wrote:

@finneganh https://github.com/finneganh it is, but still doesn't
resolve the error though? :/
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/twitter-fabric/velocity-react/issues/160#issuecomment-274838711,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAP65XXR5VaCVJFv-LrPsDFlUJ5T0BXvks5rVhptgaJpZM4LsEHb
.

@finneganh yes I am using webpack but haven't ran into this sort of issue with my other imported libraries. This is a gist of my webpack, be aware that my folder structure is a bit different.
Root

app
src
tools (here are my webpack / gulp / node_modules / bower /...)

My guess is that the resolveLoader is overriding the default relative
node_modules resolution. So webpack is forcing velocity-react to import
from your base node_modules rather than starting at its internal
node_modules.
On Tue, Jan 24, 2017 at 12:03 PM, Neal van der Valk <
notifications@github.com> wrote:

@finneganh https://github.com/finneganh yes I am using webpack but
haven't ran into this sort of issue with my other imported libraries. This
is a gist of my webpack
https://gist.github.com/nealoke/814acb32fcca8645bf21d1214c6f8fb3, be
aware that my folder structure is a bit different.
Root

app
src
tools (here are my webpack / gulp / node_modules / bower /...)

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/twitter-fabric/velocity-react/issues/160#issuecomment-274867898,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAP65bL21HQAxzX0psaYa6bvV1lEAJKRks5rVi7fgaJpZM4LsEHb
.

@finneganh aah that could be. Any ideas on how to solve this? (thanks for your time btw!)

Not sure. I guess I'd try to avoid setting a resolveLoader at all, but you'd know better what led you to using it.

Managed to fix it using the following configuration in webpack.config.js.
resolve: {
	root: ['../tools/node_modules', '../tools/node_modules/babel'],
},

resolveLoader: {
	root: path.resolve('..', 'tools', 'node_modules')
}

authors: finneganh nealoke

repo: twitter-fabric/velocity-react

license: mit


text:
IllegalArgumentException when computing HLL intersection size

I suspect this is a sort of edge case in the HLL approximation algo, but it seems there should be a better way to surface this than this exception.
I've reconstructed the case as reported, coming up with two sets with sizes 428 & 395 and intersection size 67:
val set1 = Set(645, 892, 1501, 809, 629, 18360, 760, 1633, 4899, 1729, 1083, 1982, 5205, 30675, 3566, 12507, 88, 411188, 212124, 481, 1158, 762, 63015, 2062, 6463, 1544, 13707, 6830, 4326, 655, 269, 11724, 5967, 385, 4418, 1310, 533, 142, 3044, 31359, 1164, 5146, 814, 2901, 5636, 153, 16456, 2985, 709, 7136, 7235, 1645, 257, 389, 2916, 3425, 1430, 9828, 1298, 2339, 10865, 7683, 7771, 9315, 6662, 817, 21394, 1379, 9480, 10516, 5127, 421, 1479, 2520, 5746, 2158, 3708, 4460, 57, 1362, 1847, 2178, 1489, 492, 164, 9283, 591, 443, 321, 1418, 3983, 5680, 514, 2291, 5985, 5360, 5448, 2833, 2523, 2371, 2137, 11490, 2002, 998, 9236, 18656, 5489, 24794, 1242, 14654, 16858, 507, 7170, 1564, 33823, 4604, 380, 439, 678, 6482, 11032, 108925, 714, 1868, 2061, 5281, 11698, 2264, 44824, 1676, 1487, 192, 3371, 5470, 275, 33, 10721, 1837, 625, 2433, 38539, 522, 3546, 2112, 456, 1740, 6709, 239586, 3105, 7329, 317, 650, 2841, 725, 403, 1878, 53, 5919, 356, 14840, 3746, 5081, 783, 471, 256, 225, 15523, 5496, 3407, 669, 27356, 2080, 33332, 547, 1825, 393, 6752, 647, 1150, 1539, 3059, 1192, 911, 3115, 41, 779, 2140, 2756, 3083, 503, 1333, 2749, 5544, 15121, 792, 1086, 266, 7721, 2208, 1695, 10069, 2057, 1286, 17250, 11769, 1026, 586, 718, 888, 750, 1764, 2176, 513, 166, 3079, 3289, 180, 2376, 42819, 58760, 3319, 402, 772, 24649, 1652, 4926, 17964, 958, 1403, 6019, 18863, 641, 391, 5185, 3051, 3077, 29029, 4099, 11423, 8059, 1090, 804, 10953, 187, 45307, 3996, 219, 2383, 1574, 1048, 4914, 362, 451, 76, 1439, 863, 3456, 10265, 16090, 2182, 758, 535, 21686, 91, 483, 1460, 3150, 2842, 462, 2710, 41638, 69300, 23062, 2752, 1435, 10063, 1090714, 80, 1694, 167, 658, 11887, 5548, 1948, 8965, 1304, 6225, 7650, 9069, 15797, 4859, 1472, 2597, 355, 98071, 707, 954, 1753, 1267, 3058, 4630, 310, 3114, 370, 840, 9358, 8391, 3623, 359, 1285, 9690, 643, 544, 1543, 1257, 613, 154, 1353, 5809, 3224, 1427, 3520, 270470, 1255208, 4217, 845, 231, 63084, 10241, 1084, 4606, 363, 931, 2696, 87, 6835, 4078, 4006, 6882, 1575, 1807, 771, 2591, 6230, 963, 2283, 319, 3484, 1639, 14079, 2532, 4250, 258, 632, 171, 786, 113855, 914, 246, 8649, 7399, 9421, 1513, 12805, 2494, 214, 287, 4125, 15974, 11447, 5728, 31880, 4254, 1097, 405, 183, 373, 603, 5700, 8790, 10064, 126, 341, 3347, 5990, 358, 19212, 195, 4427, 3716, 1561, 9795, 532, 1346, 9441, 860, 1582, 2265, 102960, 723, 5046, 4936, 163, 4330, 16412, 93129, 45095, 2754, 9838, 55878, 3580, 7776, 11286, 204276, 8245, 52371, 33358, 1463, 5183, 1565, 6767, 4423, 676, 1449, 496, 16046, 2655, 1417)

val set2 = Set(645, 3021, 4201, 5469, 138, 479, 30638, 1083, 1982, 6074, 3566, 5141, 192684, 276, 6463, 3377, 6830, 873, 1173, 4543, 6401, 1310, 3942, 23251, 4294, 5782, 538, 6877, 670, 404, 4371, 1645, 142252, 5903, 4198, 3140, 53919, 1803, 2654, 24192, 52, 1709, 4348, 1430, 21794, 1298, 3046, 110, 8022, 1132, 3855, 11760, 7835, 853, 189, 20, 93, 284, 2929, 325, 12864, 2158, 3602, 1232, 1847, 6002, 492, 1418, 1383, 2555, 1183, 6204, 2833, 2190, 6740, 11413, 660, 9236, 5489, 116, 6616, 10523, 6, 270, 85, 205787, 17363, 4312, 1868, 1387, 894, 12613, 18820, 302, 137962, 598, 12247, 70, 192, 407, 429, 1370, 3207, 33, 19980, 2433, 879, 1555, 97, 830, 10794, 1836, 8964, 4417, 3028, 1407, 1291, 974, 8238, 6413, 1234, 15761, 2840, 1762, 36729, 15456, 2841, 6375, 1328, 403, 28279, 1878, 3386, 356, 159807, 3237, 989, 857, 471, 256, 4049, 17890, 3407, 3210, 7111, 2830, 8743, 4545, 1214, 547, 3573, 212, 3242, 13081, 6752, 5273, 4384, 1539, 1456, 3059, 42620, 18044, 21146, 3115, 82280, 4902, 1246, 21775, 41, 2140, 3083, 503, 605, 1393, 2749, 128, 1086, 633, 7721, 805, 674, 6038, 4308, 1732, 2235, 750, 1251, 3130, 2292, 4354, 1103, 166, 21919, 64, 7953, 7382, 180, 689, 17, 7118, 149, 1631, 601, 819, 176, 423, 1884, 2657, 5067, 2393, 577, 291, 11729, 1403, 28059, 204, 295471, 641, 391, 3023, 5595, 8059, 3641, 87099, 10505, 1356, 540, 672, 764, 1194, 26171, 1209, 831, 2383, 2624, 1117, 7, 599, 1439, 3456, 494, 2605, 858, 367, 609, 621, 1325, 3298, 8372, 1177, 462, 1820, 78147, 1044, 20660, 223, 2752, 299, 3512, 2005, 1948, 1203, 162, 531, 83773, 2652, 28084, 112, 1145, 754, 1547, 640, 295, 7801, 95, 55485, 43943, 1252, 16579, 4630, 2850, 310, 30352, 5731, 1452, 1637, 1188, 3475, 127, 2219, 359, 656, 1702, 1749, 727, 978, 11349, 34347, 3256, 3156, 14518, 250, 2458, 3401, 99, 363, 21088, 104, 17772, 16575, 10072, 1385, 2174, 319, 1508, 351, 3336, 24365, 6023, 5368, 171, 139, 1523, 5828, 8, 290, 2041, 6118, 207, 2066, 272, 6569, 12567, 4098, 4619, 716, 7093, 1578, 1395, 49950, 31786, 1986, 183, 3337, 790, 14278, 11009, 59324, 242, 4, 294, 1989, 6169, 341, 2186, 4281, 29507, 437, 3716, 897, 767, 635, 955, 395, 839, 1236, 6190, 140568, 1582, 7071, 131, 6452, 200, 1597, 178, 1902, 442, 57287, 607, 3526, 1606, 3580, 1944, 5494, 309, 2059, 6767, 189885, 639, 4863, 2170, 2106, 496, 16046, 1912)

Using the default hasher and 9 bits:
val hll1 = m.sum(set1.map(m.toHLL(_)))
val hll2 = m.sum(set2.map(m.toHLL(_)))
m.intersectionSize(Seq(hll1, hll2))
java.lang.IllegalArgumentException: requirement failed
  at scala.Predef$.require(Predef.scala:207)
  at com.twitter.algebird.Approximate.withMin(Approximate.scala:131)
  at com.twitter.algebird.HyperLogLogMonoid$$anonfun$intersectionSize$2.apply(HyperLogLog.scala:611)
  at com.twitter.algebird.HyperLogLogMonoid$$anonfun$intersectionSize$2.apply(HyperLogLog.scala:611)
  at scala.Option.map(Option.scala:146)
  at com.twitter.algebird.HyperLogLogMonoid.intersectionSize(HyperLogLog.scala:611)
  ... 39 elided

The size approximations illustrate why our intersection algorithm doesn't work: the min value for the union is larger than the sum of max values for the individual HLLs:
hll1.approximateSize
com.twitter.algebird.Approximate[Long] = Approximate(797,925,1054,0.9972)

hll2.approximateSize
com.twitter.algebird.Approximate[Long] = Approximate(651,755,861,0.9972)

m.plus(hll1, hll2).approximateSize
com.twitter.algebird.Approximate[Long] = Approximate(1917,2223,2531,0.9972)

I don't know why this require is there:
https://github.com/twitter/algebird/blame/develop/algebird-core/src/main/scala/com/twitter/algebird/Approximate.scala#L143
but I wrote it. :/
What is happening is that we have some range: [a, b] and with prob >= p we are inside that range. Now, we say we know it is at least as large as m but m > b, so clearly the event m in [a, b] didn't happen, so we only know something like: [m, m] is the new range with probability > 0.
The HLL intersection algorithm is correct, I think, it is just that the noise is so large we don't know what the true value is.
I think, we want to fix .withMin to just return (m, m, m, 0.0) in this case, which hopefully consumers see as very uninformed.
Any other ideas?

authors: jnievelt johnynek

repo: twitter/algebird


text:
Wrap stuff in components.mustache

I can feel my copypastin' skill increasing :P

beast mode! thanks bro :hearts:

authors: fat pokonski

repo: twitter/bootstrap

license: MIT


text:
Topic autocreation stalls producer for 10 seconds

We are using topic autocreation with franz-go and we experience noticeable delay when producing first message to non-existing topic with ProduceSync method. After some debugging I found that reducing MetadataMinAge reduces this delay as well. Is that expected behavior?
Relevant client configuration:
opts := []kgo.Opt{
  kgo.ProduceRequestTimeout(2 * time.Second),
  kgo.RetryTimeout(6 * time.Second),
  kgo.MetadataMaxAge(2 * time.Minute),
  kgo.AllowAutoTopicCreation(),
}

franz-go version: v1.2.3

Click to expand log file
time=2021-12-06T20:01:04+01:00 level=info msg=producing to a new topic for the first time, fetching metadata to learn its partitions[topic local_8800ab87-b192-4b8c-b755-7a0d37c343b2] reporter=job-producer topic=local_8800ab87-b192-4b8c-b755-7a0d37c343b2
time=2021-12-06T20:01:04+01:00 level=info msg=immediate metadata update triggered[why forced load due to unknown produce topic] reporter=job-producer why=forced load due to unknown produce topic
time=2021-12-06T20:01:04+01:00 level=debug msg=opening connection to broker[addr 127.0.0.1:9092 broker seed 0] addr=127.0.0.1:9092 broker=seed 0 reporter=job-producer
time=2021-12-06T20:01:04+01:00 level=debug msg=connection opened to broker[addr 127.0.0.1:9092 broker seed 0] addr=127.0.0.1:9092 broker=seed 0 reporter=job-producer
time=2021-12-06T20:01:04+01:00 level=debug msg=issuing api versions request[broker seed 0 version 3] broker=seed 0 reporter=job-producer version=3
time=2021-12-06T20:01:04+01:00 level=debug msg=wrote ApiVersions v3[broker seed 0 bytes_written 31 write_wait 165.368µs time_to_write 39.661µs err <nil>] broker=seed 0 bytes_written=31 err=<nil> reporter=job-producer time_to_write=39.661µs write_wait=165.368µs
time=2021-12-06T20:01:04+01:00 level=debug msg=read ApiVersions v3[broker seed 0 bytes_read 404 read_wait 460.982µs time_to_read 2.669408ms err <nil>] broker=seed 0 bytes_read=404 err=<nil> read_wait=460.982µs reporter=job-producer time_to_read=2.669408ms
time=2021-12-06T20:01:04+01:00 level=debug msg=connection initialized successfully[addr 127.0.0.1:9092 broker seed 0] addr=127.0.0.1:9092 broker=seed 0 reporter=job-producer
time=2021-12-06T20:01:04+01:00 level=debug msg=wrote Metadata v9[broker seed 0 bytes_written 67 write_wait 5.06139ms time_to_write 30.492µs err <nil>] broker=seed 0 bytes_written=67 err=<nil> reporter=job-producer time_to_write=30.492µs write_wait=5.06139ms
time=2021-12-06T20:01:04+01:00 level=debug msg=read Metadata v9[broker seed 0 bytes_read 119 read_wait 410.821µs time_to_read 17.599878ms err <nil>] broker=seed 0 bytes_read=119 err=<nil> read_wait=410.821µs reporter=job-producer time_to_read=17.599878ms
time=2021-12-06T20:01:04+01:00 level=info msg=new topic metadata wait failed, retrying wait[topic local_8800ab87-b192-4b8c-b755-7a0d37c343b2 err LEADER_NOT_AVAILABLE: There is no leader for this topic-partition as we are in the middle of a leadership election.] err=LEADER_NOT_AVAILABLE: There is no leader for this topic-partition as we are in the middle of a leadership election. reporter=job-producer topic=local_8800ab87-b192-4b8c-b755-7a0d37c343b2
time=2021-12-06T20:01:04+01:00 level=debug msg=opening connection to broker[addr 127.0.0.1:9092 broker 1] addr=127.0.0.1:9092 broker=1 reporter=job-producer
time=2021-12-06T20:01:04+01:00 level=debug msg=connection opened to broker[addr 127.0.0.1:9092 broker 1] addr=127.0.0.1:9092 broker=1 reporter=job-producer
time=2021-12-06T20:01:04+01:00 level=debug msg=issuing api versions request[broker 1 version 3] broker=1 reporter=job-producer version=3
time=2021-12-06T20:01:04+01:00 level=debug msg=wrote ApiVersions v3[broker 1 bytes_written 31 write_wait 106.234µs time_to_write 28.198µs err <nil>] broker=1 bytes_written=31 err=<nil> reporter=job-producer time_to_write=28.198µs write_wait=106.234µs
time=2021-12-06T20:01:04+01:00 level=debug msg=read ApiVersions v3[broker 1 bytes_read 404 read_wait 475.948µs time_to_read 3.548014ms err <nil>] broker=1 bytes_read=404 err=<nil> read_wait=475.948µs reporter=job-producer time_to_read=3.548014ms
time=2021-12-06T20:01:04+01:00 level=debug msg=connection initialized successfully[addr 127.0.0.1:9092 broker 1] addr=127.0.0.1:9092 broker=1 reporter=job-producer
time=2021-12-06T20:01:04+01:00 level=debug msg=wrote Metadata v9[broker 1 bytes_written 67 write_wait 5.91561ms time_to_write 32.116µs err <nil>] broker=1 bytes_written=67 err=<nil> reporter=job-producer time_to_write=32.116µs write_wait=5.91561ms
time=2021-12-06T20:01:04+01:00 level=debug msg=read Metadata v9[broker 1 bytes_read 119 read_wait 503.213µs time_to_read 14.927694ms err <nil>] broker=1 bytes_read=119 err=<nil> read_wait=503.213µs reporter=job-producer time_to_read=14.927694ms
time=2021-12-06T20:01:04+01:00 level=info msg=new topic metadata wait failed, retrying wait[topic local_8800ab87-b192-4b8c-b755-7a0d37c343b2 err LEADER_NOT_AVAILABLE: There is no leader for this topic-partition as we are in the middle of a leadership election.] err=LEADER_NOT_AVAILABLE: There is no leader for this topic-partition as we are in the middle of a leadership election. reporter=job-producer topic=local_8800ab87-b192-4b8c-b755-7a0d37c343b2
time=2021-12-06T20:01:04+01:00 level=debug msg=wrote Metadata v9[broker seed 0 bytes_written 67 write_wait 267.552µs time_to_write 34.995µs err <nil>] broker=seed 0 bytes_written=67 err=<nil> reporter=job-producer time_to_write=34.995µs write_wait=267.552µs
time=2021-12-06T20:01:04+01:00 level=debug msg=read Metadata v9[broker seed 0 bytes_read 119 read_wait 526.747µs time_to_read 12.997286ms err <nil>] broker=seed 0 bytes_read=119 err=<nil> read_wait=526.747µs reporter=job-producer time_to_read=12.997286ms
time=2021-12-06T20:01:04+01:00 level=info msg=metadata update triggered[why re-updating due to inner errors: LEADER_NOT_AVAILABLE{local_8800ab87-b192-4b8c-b755-7a0d37c343b2}] reporter=job-producer why=re-updating due to inner errors: LEADER_NOT_AVAILABLE{local_8800ab87-b192-4b8c-b755-7a0d37c343b2}
time=2021-12-06T20:01:04+01:00 level=info msg=new topic metadata wait failed, retrying wait[topic local_8800ab87-b192-4b8c-b755-7a0d37c343b2 err LEADER_NOT_AVAILABLE: There is no leader for this topic-partition as we are in the middle of a leadership election.] err=LEADER_NOT_AVAILABLE: There is no leader for this topic-partition as we are in the middle of a leadership election. reporter=job-producer topic=local_8800ab87-b192-4b8c-b755-7a0d37c343b2

============== 10 second gap here

time=2021-12-06T20:01:14+01:00 level=debug msg=wrote Metadata v9[broker 1 bytes_written 67 write_wait 266.433µs time_to_write 50.592µs err <nil>] broker=1 bytes_written=67 err=<nil> reporter=job-producer time_to_write=50.592µs write_wait=266.433µs
time=2021-12-06T20:01:14+01:00 level=debug msg=read Metadata v9[broker 1 bytes_read 197 read_wait 311.16733ms time_to_read 25.563µs err <nil>] broker=1 bytes_read=197 err=<nil> read_wait=311.16733ms reporter=job-producer time_to_read=25.563µs
time=2021-12-06T20:01:14+01:00 level=info msg=done waiting for metadata for new topic[topic local_8800ab87-b192-4b8c-b755-7a0d37c343b2] reporter=job-producer topic=local_8800ab87-b192-4b8c-b755-7a0d37c343b2
time=2021-12-06T20:01:14+01:00 level=info msg=initializing producer id[] reporter=job-producer
time=2021-12-06T20:01:14+01:00 level=debug msg=wrote InitProducerID v4[broker seed 0 bytes_written 34 write_wait 173.641µs time_to_write 34.41µs err <nil>] broker=seed 0 bytes_written=34 err=<nil> reporter=job-producer time_to_write=34.41µs write_wait=173.641µs
time=2021-12-06T20:01:14+01:00 level=debug msg=read InitProducerID v4[broker seed 0 bytes_read 26 read_wait 483.243µs time_to_read 1.804594ms err <nil>] broker=seed 0 bytes_read=26 err=<nil> read_wait=483.243µs reporter=job-producer time_to_read=1.804594ms
time=2021-12-06T20:01:14+01:00 level=info msg=producer id initialization success[id 7 epoch 0] epoch=0 id=7 reporter=job-producer
time=2021-12-06T20:01:14+01:00 level=debug msg=opening connection to broker[addr 127.0.0.1:9092 broker 1] addr=127.0.0.1:9092 broker=1 reporter=job-producer
time=2021-12-06T20:01:14+01:00 level=debug msg=connection opened to broker[addr 127.0.0.1:9092 broker 1] addr=127.0.0.1:9092 broker=1 reporter=job-producer
time=2021-12-06T20:01:14+01:00 level=debug msg=connection initialized successfully[addr 127.0.0.1:9092 broker 1] addr=127.0.0.1:9092 broker=1 reporter=job-producer
time=2021-12-06T20:01:14+01:00 level=debug msg=wrote Produce v8[broker 1 bytes_written 244 write_wait 981.393µs time_to_write 25.516µs err <nil>] broker=1 bytes_written=244 err=<nil> reporter=job-producer time_to_write=25.516µs write_wait=981.393µs
time=2021-12-06T20:01:14+01:00 level=debug msg=read Produce v8[broker 1 bytes_read 100 read_wait 472.121µs time_to_read 3.200482ms err <nil>] broker=1 bytes_read=100 err=<nil> read_wait=472.121µs reporter=job-producer time_to_read=3.200482ms
time=2021-12-06T20:01:14+01:00 level=debug msg=produced[broker 1 to local_8800ab87-b192-4b8c-b755-7a0d37c343b2[2{0=>1}]] broker=1 reporter=job-producer to=local_8800ab87-b192-4b8c-b755-7a0d37c343b2[2{0=>1}]
time=2021-12-06T20:01:14+01:00 level=info msg=beginning autocommit loop[group local_8800ab87-b192-4b8c-b755-7a0d37c343b2] group=local_8800ab87-b192-4b8c-b755-7a0d37c343b2 reporter=job-consumer-8800ab87-b192-4b8c-b755-7a0d37c343b2
time=2021-12-06T20:01:14+01:00 level=info msg=metadata update triggered[why client initialization] reporter=job-consumer-8800ab87-b192-4b8c-b755-7a0d37c343b2 why=client initialization
time=2021-12-06T20:01:14+01:00 level=debug msg=opening connection to broker[addr 127.0.0.1:9092 broker seed 0] addr=127.0.0.1:9092 broker=seed 0 reporter=job-consumer-8800ab87-b192-4b8c-b755-7a0d37c343b2
time=2021-12-06T20:01:14+01:00 level=debug msg=connection opened to broker[addr 127.0.0.1:9092 broker seed 0] addr=127.0.0.1:9092 broker=seed 0 reporter=job-consumer-8800ab87-b192-4b8c-b755-7a0d37c343b2
time=2021-12-06T20:01:14+01:00 level=debug msg=issuing api versions request[broker seed 0 version 3] broker=seed 0 reporter=job-consumer-8800ab87-b192-4b8c-b755-7a0d37c343b2 version=3
time=2021-12-06T20:01:14+01:00 level=debug msg=wrote ApiVersions v3[broker seed 0 bytes_written 31 write_wait 62.705µs time_to_write 21.894µs err <nil>] broker=seed 0 bytes_written=31 err=<nil> reporter=job-consumer-8800ab87-b192-4b8c-b755-7a0d37c343b2 time_to_write=21.894µs write_wait=62.705µs
time=2021-12-06T20:01:14+01:00 level=debug msg=read ApiVersions v3[broker seed 0 bytes_read 404 read_wait 360.535µs time_to_read 2.555572ms err <nil>] broker=seed 0 bytes_read=404 err=<nil> read_wait=360.535µs reporter=job-consumer-8800ab87-b192-4b8c-b755-7a0d37c343b2 time_to_read=2.555572ms
time=2021-12-06T20:01:14+01:00 level=debug msg=connection initialized successfully[addr 127.0.0.1:9092 broker seed 0] addr=127.0.0.1:9092 broker=seed 0 reporter=job-consumer-8800ab87-b192-4b8c-b755-7a0d37c343b2
time=2021-12-06T20:01:14+01:00 level=debug msg=wrote Metadata v9[broker seed 0 bytes_written 67 write_wait 4.299755ms time_to_write 24.078µs err <nil>] broker=seed 0 bytes_written=67 err=<nil> reporter=job-consumer-8800ab87-b192-4b8c-b755-7a0d37c343b2 time_to_write=24.078µs write_wait=4.299755ms
time=2021-12-06T20:01:14+01:00 level=debug msg=read Metadata v9[broker seed 0 bytes_read 197 read_wait 346.522µs time_to_read 1.566851ms err <nil>] broker=seed 0 bytes_read=197 err=<nil> read_wait=346.522µs reporter=job-consumer-8800ab87-b192-4b8c-b755-7a0d37c343b2 time_to_read=1.566851ms
time=2021-12-06T20:01:14+01:00 level=info msg=beginning to manage the group lifecycle[group local_8800ab87-b192-4b8c-b755-7a0d37c343b2] group=local_8800ab87-b192-4b8c-b755-7a0d37c343b2 reporter=job-consumer-8800ab87-b192-4b8c-b755-7a0d37c343b2
time=2021-12-06T20:01:14+01:00 level=info msg=joining group[group local_8800ab87-b192-4b8c-b755-7a0d37c343b2] group=local_8800ab87-b192-4b8c-b755-7a0d37c343b2 reporter=job-consumer-8800ab87-b192-4b8c-b755-7a0d37c343b2
time=2021-12-06T20:01:14+01:00 level=debug msg=opening connection to broker[addr 127.0.0.1:9092 broker 1] addr=127.0.0.1:9092 broker=1 reporter=job-consumer-8800ab87-b192-4b8c-b755-7a0d37c343b2
time=2021-12-06T20:01:14+01:00 level=debug msg=connection opened to broker[addr 127.0.0.1:9092 broker 1] addr=127.0.0.1:9092 broker=1 reporter=job-consumer-8800ab87-b192-4b8c-b755-7a0d37c343b2
time=2021-12-06T20:01:14+01:00 level=debug msg=issuing api versions request[broker 1 version 3] broker=1 reporter=job-consumer-8800ab87-b192-4b8c-b755-7a0d37c343b2 version=3
time=2021-12-06T20:01:14+01:00 level=debug msg=wrote ApiVersions v3[broker 1 bytes_written 31 write_wait 57.763µs time_to_write 22.921µs err <nil>] broker=1 bytes_written=31 err=<nil> reporter=job-consumer-8800ab87-b192-4b8c-b755-7a0d37c343b2 time_to_write=22.921µs write_wait=57.763µs
time=2021-12-06T20:01:14+01:00 level=debug msg=read ApiVersions v3[broker 1 bytes_read 404 read_wait 384.176µs time_to_read 1.676039ms err <nil>] broker=1 bytes_read=404 err=<nil> read_wait=384.176µs reporter=job-consumer-8800ab87-b192-4b8c-b755-7a0d37c343b2 time_to_read=1.676039ms
time=2021-12-06T20:01:14+01:00 level=debug msg=connection initialized successfully[addr 127.0.0.1:9092 broker 1] addr=127.0.0.1:9092 broker=1 reporter=job-consumer-8800ab87-b192-4b8c-b755-7a0d37c343b2
time=2021-12-06T20:01:14+01:00 level=debug msg=wrote FindCoordinator v3[broker 1 bytes_written 63 write_wait 3.565361ms time_to_write 22.191µs err <nil>] broker=1 bytes_written=63 err=<nil> reporter=job-consumer-8800ab87-b192-4b8c-b755-7a0d37c343b2 time_to_write=22.191µs write_wait=3.565361ms
time=2021-12-06T20:01:14+01:00 level=debug msg=read FindCoordinator v3[broker 1 bytes_read 39 read_wait 422.746µs time_to_read 1.442076ms err <nil>] broker=1 bytes_read=39 err=<nil> read_wait=422.746µs reporter=job-consumer-8800ab87-b192-4b8c-b755-7a0d37c343b2 time_to_read=1.442076ms
time=2021-12-06T20:01:14+01:00 level=debug msg=opening connection to broker[addr 127.0.0.1:9092 broker 1] addr=127.0.0.1:9092 broker=1 reporter=job-consumer-8800ab87-b192-4b8c-b755-7a0d37c343b2
time=2021-12-06T20:01:14+01:00 level=debug msg=connection opened to broker[addr 127.0.0.1:9092 broker 1] addr=127.0.0.1:9092 broker=1 reporter=job-consumer-8800ab87-b192-4b8c-b755-7a0d37c343b2
time=2021-12-06T20:01:14+01:00 level=debug msg=connection initialized successfully[addr 127.0.0.1:9092 broker 1] addr=127.0.0.1:9092 broker=1 reporter=job-consumer-8800ab87-b192-4b8c-b755-7a0d37c343b2
time=2021-12-06T20:01:14+01:00 level=debug msg=wrote JoinGroup v7[broker 1 bytes_written 173 write_wait 757.116µs time_to_write 22.229µs err <nil>] broker=1 bytes_written=173 err=<nil> reporter=job-consumer-8800ab87-b192-4b8c-b755-7a0d37c343b2 time_to_write=22.229µs write_wait=757.116µs
time=2021-12-06T20:01:14+01:00 level=debug msg=read JoinGroup v7[broker 1 bytes_read 248 read_wait 404.855µs time_to_read 5.129187ms err <nil>] broker=1 bytes_read=248 err=<nil> read_wait=404.855µs reporter=job-consumer-8800ab87-b192-4b8c-b755-7a0d37c343b2 time_to_read=5.129187ms
time=2021-12-06T20:01:14+01:00 level=info msg=joined, balancing group[group local_8800ab87-b192-4b8c-b755-7a0d37c343b2 member_id test-155e8289-3318-48fb-9e49-ef373a0d877b instance_id 0xc00049b5a0 generation 1 balance_protocol cooperative-sticky leader true] balance_protocol=cooperative-sticky generation=1 group=local_8800ab87-b192-4b8c-b755-7a0d37c343b2 instance_id=0xc00049b5a0 leader=true member_id=test-155e8289-3318-48fb-9e49-ef373a0d877b reporter=job-consumer-8800ab87-b192-4b8c-b755-7a0d37c343b2
time=2021-12-06T20:01:14+01:00 level=info msg=balancing group as leader[] reporter=job-consumer-8800ab87-b192-4b8c-b755-7a0d37c343b2
time=2021-12-06T20:01:14+01:00 level=info msg=balance group member[id test-155e8289-3318-48fb-9e49-ef373a0d877b instance_id test interests interested topics: [local_8800ab87-b192-4b8c-b755-7a0d37c343b2], previously owned: ] id=test-155e8289-3318-48fb-9e49-ef373a0d877b instance_id=test interests=interested topics: [local_8800ab87-b192-4b8c-b755-7a0d37c343b2], previously owned:  reporter=job-consumer-8800ab87-b192-4b8c-b755-7a0d37c343b2
time=2021-12-06T20:01:14+01:00 level=info msg=balanced[plan test-155e8289-3318-48fb-9e49-ef373a0d877b{local_8800ab87-b192-4b8c-b755-7a0d37c343b2[0 1 2]}] plan=test-155e8289-3318-48fb-9e49-ef373a0d877b{local_8800ab87-b192-4b8c-b755-7a0d37c343b2[0 1 2]} reporter=job-consumer-8800ab87-b192-4b8c-b755-7a0d37c343b2
time=2021-12-06T20:01:14+01:00 level=info msg=syncing[group local_8800ab87-b192-4b8c-b755-7a0d37c343b2 protocol_type consumer protocol cooperative-sticky] group=local_8800ab87-b192-4b8c-b755-7a0d37c343b2 protocol=cooperative-sticky protocol_type=consumer reporter=job-consumer-8800ab87-b192-4b8c-b755-7a0d37c343b2
time=2021-12-06T20:01:14+01:00 level=debug msg=wrote SyncGroup v5[broker 1 bytes_written 256 write_wait 106.141µs time_to_write 23.118µs err <nil>] broker=1 bytes_written=256 err=<nil> reporter=job-consumer-8800ab87-b192-4b8c-b755-7a0d37c343b2 time_to_write=23.118µs write_wait=106.141µs
time=2021-12-06T20:01:14+01:00 level=debug msg=read SyncGroup v5[broker 1 bytes_read 115 read_wait 410.639µs time_to_read 2.564327ms err <nil>] broker=1 bytes_read=115 err=<nil> read_wait=410.639µs reporter=job-consumer-8800ab87-b192-4b8c-b755-7a0d37c343b2 time_to_read=2.564327ms
time=2021-12-06T20:01:14+01:00 level=info msg=synced[group local_8800ab87-b192-4b8c-b755-7a0d37c343b2 assigned local_8800ab87-b192-4b8c-b755-7a0d37c343b2[0 1 2]] assigned=local_8800ab87-b192-4b8c-b755-7a0d37c343b2[0 1 2] group=local_8800ab87-b192-4b8c-b755-7a0d37c343b2 reporter=job-consumer-8800ab87-b192-4b8c-b755-7a0d37c343b2
time=2021-12-06T20:01:14+01:00 level=info msg=new group session begun[group local_8800ab87-b192-4b8c-b755-7a0d37c343b2 added map[local_8800ab87-b192-4b8c-b755-7a0d37c343b2:[0 1 2]] lost map[]] added=map[local_8800ab87-b192-4b8c-b755-7a0d37c343b2:[0 1 2]] group=local_8800ab87-b192-4b8c-b755-7a0d37c343b2 lost=map[] reporter=job-consumer-8800ab87-b192-4b8c-b755-7a0d37c343b2
time=2021-12-06T20:01:14+01:00 level=info msg=beginning heartbeat loop[group local_8800ab87-b192-4b8c-b755-7a0d37c343b2] group=local_8800ab87-b192-4b8c-b755-7a0d37c343b2 reporter=job-consumer-8800ab87-b192-4b8c-b755-7a0d37c343b2
time=2021-12-06T20:01:14+01:00 level=info msg=fetching offsets for added partitions[group local_8800ab87-b192-4b8c-b755-7a0d37c343b2 added map[local_8800ab87-b192-4b8c-b755-7a0d37c343b2:[0 1 2]]] added=map[local_8800ab87-b192-4b8c-b755-7a0d37c343b2:[0 1 2]] group=local_8800ab87-b192-4b8c-b755-7a0d37c343b2 reporter=job-consumer-8800ab87-b192-4b8c-b755-7a0d37c343b2
time=2021-12-06T20:01:14+01:00 level=debug msg=entering OnAssigned[with map[local_8800ab87-b192-4b8c-b755-7a0d37c343b2:[0 1 2]]] reporter=job-consumer-8800ab87-b192-4b8c-b755-7a0d37c343b2 with=map[local_8800ab87-b192-4b8c-b755-7a0d37c343b2:[0 1 2]]
time=2021-12-06T20:01:14+01:00 level=debug msg=sharded request[destinations [1]] destinations=[1] reporter=job-consumer-8800ab87-b192-4b8c-b755-7a0d37c343b2
time=2021-12-06T20:01:14+01:00 level=debug msg=wrote OffsetFetch v7[broker 1 bytes_written 121 write_wait 196.254µs time_to_write 24.921µs err <nil>] broker=1 bytes_written=121 err=<nil> reporter=job-consumer-8800ab87-b192-4b8c-b755-7a0d37c343b2 time_to_write=24.921µs write_wait=196.254µs
time=2021-12-06T20:01:14+01:00 level=debug msg=read OffsetFetch v7[broker 1 bytes_read 122 read_wait 411.192µs time_to_read 1.533869ms err <nil>] broker=1 bytes_read=122 err=<nil> read_wait=411.192µs reporter=job-consumer-8800ab87-b192-4b8c-b755-7a0d37c343b2 time_to_read=1.533869ms
time=2021-12-06T20:01:14+01:00 level=info msg=assigning partitions[why newly fetched offsets for group local_8800ab87-b192-4b8c-b755-7a0d37c343b2 how assigning everything new, keeping current assignment input map[local_8800ab87-b192-4b8c-b755-7a0d37c343b2:map[0:{-2.-1~0} 1:{-2.-1~0} 2:{-2.-1~0}]]] how=assigning everything new, keeping current assignment input=map[local_8800ab87-b192-4b8c-b755-7a0d37c343b2:map[0:{-2.-1~0} 1:{-2.-1~0} 2:{-2.-1~0}]] reporter=job-consumer-8800ab87-b192-4b8c-b755-7a0d37c343b2 why=newly fetched offsets for group local_8800ab87-b192-4b8c-b755-7a0d37c343b2
time=2021-12-06T20:01:14+01:00 level=debug msg=assign requires loading offsets[] reporter=job-consumer-8800ab87-b192-4b8c-b755-7a0d37c343b2
time=2021-12-06T20:01:14+01:00 level=debug msg=offsets to load broker[broker 1 load {map[local_8800ab87-b192-4b8c-b755-7a0d37c343b2:map[0:{-2.-1~0} 1:{-2.-1~0} 2:{-2.-1~0}]] map[]}] broker=1 load={map[local_8800ab87-b192-4b8c-b755-7a0d37c343b2:map[0:{-2.-1~0} 1:{-2.-1~0} 2:{-2.-1~0}]] map[]} reporter=job-consumer-8800ab87-b192-4b8c-b755-7a0d37c343b2
time=2021-12-06T20:01:14+01:00 level=debug msg=wrote ListOffsets v5[broker 1 bytes_written 122 write_wait 109.965µs time_to_write 27.414µs err <nil>] broker=1 bytes_written=122 err=<nil> reporter=job-consumer-8800ab87-b192-4b8c-b755-7a0d37c343b2 time_to_write=27.414µs write_wait=109.965µs
time=2021-12-06T20:01:14+01:00 level=debug msg=read ListOffsets v5[broker 1 bytes_read 142 read_wait 437.378µs time_to_read 1.667824ms err <nil>] broker=1 bytes_read=142 err=<nil> read_wait=437.378µs reporter=job-consumer-8800ab87-b192-4b8c-b755-7a0d37c343b2 time_to_read=1.667824ms
time=2021-12-06T20:01:14+01:00 level=debug msg=handled list results[broker 1 using map[local_8800ab87-b192-4b8c-b755-7a0d37c343b2:map[0:{0 0} 1:{0 0} 2:{0 0}]] reloading map[]] broker=1 reloading=map[] reporter=job-consumer-8800ab87-b192-4b8c-b755-7a0d37c343b2 using=map[local_8800ab87-b192-4b8c-b755-7a0d37c343b2:map[0:{0 0} 1:{0 0} 2:{0 0}]]
time=2021-12-06T20:01:14+01:00 level=debug msg=opening connection to broker[addr 127.0.0.1:9092 broker 1] addr=127.0.0.1:9092 broker=1 reporter=job-consumer-8800ab87-b192-4b8c-b755-7a0d37c343b2
time=2021-12-06T20:01:14+01:00 level=debug msg=connection opened to broker[addr 127.0.0.1:9092 broker 1] addr=127.0.0.1:9092 broker=1 reporter=job-consumer-8800ab87-b192-4b8c-b755-7a0d37c343b2
time=2021-12-06T20:01:14+01:00 level=debug msg=connection initialized successfully[addr 127.0.0.1:9092 broker 1] addr=127.0.0.1:9092 broker=1 reporter=job-consumer-8800ab87-b192-4b8c-b755-7a0d37c343b2
time=2021-12-06T20:01:14+01:00 level=debug msg=wrote Fetch v12[broker 1 bytes_written 191 write_wait 845.563µs time_to_write 26.46µs err <nil>] broker=1 bytes_written=191 err=<nil> reporter=job-consumer-8800ab87-b192-4b8c-b755-7a0d37c343b2 time_to_write=26.46µs write_wait=845.563µs
time=2021-12-06T20:01:14+01:00 level=debug msg=read Fetch v12[broker 1 bytes_read 337 read_wait 352.325µs time_to_read 3.331182ms err <nil>] broker=1 bytes_read=337 err=<nil> read_wait=352.325µs reporter=job-consumer-8800ab87-b192-4b8c-b755-7a0d37c343b2 time_to_read=3.331182ms
time=2021-12-06T20:01:14+01:00 level=debug msg=updated uncommitted[group local_8800ab87-b192-4b8c-b755-7a0d37c343b2 to local_8800ab87-b192-4b8c-b755-7a0d37c343b2[], local_8800ab87-b192-4b8c-b755-7a0d37c343b2[], local_8800ab87-b192-4b8c-b755-7a0d37c343b2[2{0=>0=>1}]] group=local_8800ab87-b192-4b8c-b755-7a0d37c343b2 reporter=job-consumer-8800ab87-b192-4b8c-b755-7a0d37c343b2 to=local_8800ab87-b192-4b8c-b755-7a0d37c343b2[], local_8800ab87-b192-4b8c-b755-7a0d37c343b2[], local_8800ab87-b192-4b8c-b755-7a0d37c343b2[2{0=>0=>1}]
time=2021-12-06T20:01:14+01:00 level=debug msg=wrote Fetch v12[broker 1 bytes_written 125 write_wait 148.535µs time_to_write 25.122µs err <nil>] broker=1 bytes_written=125 err=<nil> reporter=job-consumer-8800ab87-b192-4b8c-b755-7a0d37c343b2 time_to_write=25.122µs write_wait=148.535µs
time=2021-12-06T20:01:14+01:00 level=info msg=metadata update triggered[why client initialization] reporter=job-finder why=client initialization
time=2021-12-06T20:01:14+01:00 level=debug msg=opening connection to broker[addr 127.0.0.1:9092 broker seed 0] addr=127.0.0.1:9092 broker=seed 0 reporter=job-finder
time=2021-12-06T20:01:14+01:00 level=debug msg=connection opened to broker[addr 127.0.0.1:9092 broker seed 0] addr=127.0.0.1:9092 broker=seed 0 reporter=job-finder
time=2021-12-06T20:01:14+01:00 level=debug msg=issuing api versions request[broker seed 0 version 3] broker=seed 0 reporter=job-finder version=3
time=2021-12-06T20:01:14+01:00 level=debug msg=wrote ApiVersions v3[broker seed 0 bytes_written 31 write_wait 49.032µs time_to_write 21.183µs err <nil>] broker=seed 0 bytes_written=31 err=<nil> reporter=job-finder time_to_write=21.183µs write_wait=49.032µs
time=2021-12-06T20:01:14+01:00 level=debug msg=read ApiVersions v3[broker seed 0 bytes_read 404 read_wait 342.037µs time_to_read 1.926107ms err <nil>] broker=seed 0 bytes_read=404 err=<nil> read_wait=342.037µs reporter=job-finder time_to_read=1.926107ms
time=2021-12-06T20:01:14+01:00 level=debug msg=connection initialized successfully[addr 127.0.0.1:9092 broker seed 0] addr=127.0.0.1:9092 broker=seed 0 reporter=job-finder
time=2021-12-06T20:01:14+01:00 level=debug msg=wrote Metadata v9[broker seed 0 bytes_written 67 write_wait 3.613423ms time_to_write 24.216µs err <nil>] broker=seed 0 bytes_written=67 err=<nil> reporter=job-finder time_to_write=24.216µs write_wait=3.613423ms
time=2021-12-06T20:01:14+01:00 level=debug msg=read Metadata v9[broker seed 0 bytes_read 197 read_wait 362.395µs time_to_read 2.098122ms err <nil>] broker=seed 0 bytes_read=197 err=<nil> read_wait=362.395µs reporter=job-finder time_to_read=2.098122ms
time=2021-12-06T20:01:14+01:00 level=info msg=assigning partitions[why new assignments from direct consumer how assigning everything new, keeping current assignment input map[local_8800ab87-b192-4b8c-b755-7a0d37c343b2:map[0:{-2.-1~0} 1:{-2.-1~0} 2:{0.-1~0}]]] how=assigning everything new, keeping current assignment input=map[local_8800ab87-b192-4b8c-b755-7a0d37c343b2:map[0:{-2.-1~0} 1:{-2.-1~0} 2:{0.-1~0}]] reporter=job-finder why=new assignments from direct consumer
time=2021-12-06T20:01:14+01:00 level=debug msg=assign requires loading offsets[] reporter=job-finder
time=2021-12-06T20:01:14+01:00 level=debug msg=offsets to load broker[broker 1 load {map[local_8800ab87-b192-4b8c-b755-7a0d37c343b2:map[0:{-2.-1~0} 1:{-2.-1~0}]] map[]}] broker=1 load={map[local_8800ab87-b192-4b8c-b755-7a0d37c343b2:map[0:{-2.-1~0} 1:{-2.-1~0}]] map[]} reporter=job-finder
time=2021-12-06T20:01:14+01:00 level=debug msg=opening connection to broker[addr 127.0.0.1:9092 broker 1] addr=127.0.0.1:9092 broker=1 reporter=job-finder
time=2021-12-06T20:01:14+01:00 level=debug msg=connection opened to broker[addr 127.0.0.1:9092 broker 1] addr=127.0.0.1:9092 broker=1 reporter=job-finder
time=2021-12-06T20:01:14+01:00 level=debug msg=issuing api versions request[broker 1 version 3] broker=1 reporter=job-finder version=3
time=2021-12-06T20:01:14+01:00 level=debug msg=wrote ApiVersions v3[broker 1 bytes_written 31 write_wait 47.074µs time_to_write 22.195µs err <nil>] broker=1 bytes_written=31 err=<nil> reporter=job-finder time_to_write=22.195µs write_wait=47.074µs
time=2021-12-06T20:01:14+01:00 level=debug msg=read ApiVersions v3[broker 1 bytes_read 404 read_wait 328.305µs time_to_read 2.897592ms err <nil>] broker=1 bytes_read=404 err=<nil> read_wait=328.305µs reporter=job-finder time_to_read=2.897592ms
time=2021-12-06T20:01:14+01:00 level=debug msg=connection initialized successfully[addr 127.0.0.1:9092 broker 1] addr=127.0.0.1:9092 broker=1 reporter=job-finder
time=2021-12-06T20:01:14+01:00 level=debug msg=wrote Fetch v12[broker 1 bytes_written 125 write_wait 4.608826ms time_to_write 24.381µs err <nil>] broker=1 bytes_written=125 err=<nil> reporter=job-finder time_to_write=24.381µs write_wait=4.608826ms
time=2021-12-06T20:01:14+01:00 level=debug msg=opening connection to broker[addr 127.0.0.1:9092 broker 1] addr=127.0.0.1:9092 broker=1 reporter=job-finder
time=2021-12-06T20:01:14+01:00 level=debug msg=connection opened to broker[addr 127.0.0.1:9092 broker 1] addr=127.0.0.1:9092 broker=1 reporter=job-finder
time=2021-12-06T20:01:14+01:00 level=debug msg=connection initialized successfully[addr 127.0.0.1:9092 broker 1] addr=127.0.0.1:9092 broker=1 reporter=job-finder
time=2021-12-06T20:01:14+01:00 level=debug msg=wrote ListOffsets v5[broker 1 bytes_written 106 write_wait 5.441759ms time_to_write 33.574µs err <nil>] broker=1 bytes_written=106 err=<nil> reporter=job-finder time_to_write=33.574µs write_wait=5.441759ms
time=2021-12-06T20:01:14+01:00 level=debug msg=read Fetch v12[broker 1 bytes_read 263 read_wait 422.134µs time_to_read 2.382216ms err <nil>] broker=1 bytes_read=263 err=<nil> read_wait=422.134µs reporter=job-finder time_to_read=2.382216ms
time=2021-12-06T20:01:14+01:00 level=debug msg=read ListOffsets v5[broker 1 bytes_read 0 read_wait 487.09µs time_to_read 1.792011ms err client closed] broker=1 bytes_read=0 err=client closed read_wait=487.09µs reporter=job-finder time_to_read=1.792011ms
time=2021-12-06T20:01:14+01:00 level=info msg=assigning partitions[why invalidating all assignments in LeaveGroup how unassigning everything input map[]] how=unassigning everything input=map[] reporter=job-consumer-8800ab87-b192-4b8c-b755-7a0d37c343b2 why=invalidating all assignments in LeaveGroup
time=2021-12-06T20:01:14+01:00 level=debug msg=read Fetch v12[broker 1 bytes_read 0 read_wait 393.041µs time_to_read 16.354307ms err context canceled] broker=1 bytes_read=0 err=context canceled read_wait=393.041µs reporter=job-consumer-8800ab87-b192-4b8c-b755-7a0d37c343b2 time_to_read=16.354307ms
time=2021-12-06T20:01:14+01:00 level=info msg=heartbeat errored[group local_8800ab87-b192-4b8c-b755-7a0d37c343b2 err context canceled] err=context canceled group=local_8800ab87-b192-4b8c-b755-7a0d37c343b2 reporter=job-consumer-8800ab87-b192-4b8c-b755-7a0d37c343b2
time=2021-12-06T20:01:14+01:00 level=debug msg=read from broker errored, killing connection[addr 127.0.0.1:9092 broker 1 successful_reads 1 err context canceled] addr=127.0.0.1:9092 broker=1 err=context canceled reporter=job-consumer-8800ab87-b192-4b8c-b755-7a0d37c343b2 successful_reads=1
time=2021-12-06T20:01:14+01:00 level=debug msg=entering OnRevoked[with map[local_8800ab87-b192-4b8c-b755-7a0d37c343b2:[0 1 2]]] reporter=job-consumer-8800ab87-b192-4b8c-b755-7a0d37c343b2 with=map[local_8800ab87-b192-4b8c-b755-7a0d37c343b2:[0 1 2]]
time=2021-12-06T20:01:14+01:00 level=debug msg=in CommitOffsetsSync[group local_8800ab87-b192-4b8c-b755-7a0d37c343b2 with map[local_8800ab87-b192-4b8c-b755-7a0d37c343b2:map[2:{0 0}]]] group=local_8800ab87-b192-4b8c-b755-7a0d37c343b2 reporter=job-consumer-8800ab87-b192-4b8c-b755-7a0d37c343b2 with=map[local_8800ab87-b192-4b8c-b755-7a0d37c343b2:map[2:{0 0}]]
time=2021-12-06T20:01:14+01:00 level=debug msg=issuing commit[group local_8800ab87-b192-4b8c-b755-7a0d37c343b2 uncommitted map[local_8800ab87-b192-4b8c-b755-7a0d37c343b2:map[2:{0 0}]]] group=local_8800ab87-b192-4b8c-b755-7a0d37c343b2 reporter=job-consumer-8800ab87-b192-4b8c-b755-7a0d37c343b2 uncommitted=map[local_8800ab87-b192-4b8c-b755-7a0d37c343b2:map[2:{0 0}]]
time=2021-12-06T20:01:14+01:00 level=debug msg=wrote OffsetCommit v8[broker 1 bytes_written 218 write_wait 151.1µs time_to_write 29.123µs err <nil>] broker=1 bytes_written=218 err=<nil> reporter=job-consumer-8800ab87-b192-4b8c-b755-7a0d37c343b2 time_to_write=29.123µs write_wait=151.1µs
time=2021-12-06T20:01:14+01:00 level=debug msg=read OffsetCommit v8[broker 1 bytes_read 67 read_wait 470.251µs time_to_read 3.46822ms err <nil>] broker=1 bytes_read=67 err=<nil> read_wait=470.251µs reporter=job-consumer-8800ab87-b192-4b8c-b755-7a0d37c343b2 time_to_read=3.46822ms
time=2021-12-06T20:01:14+01:00 level=debug msg=updated committed[group local_8800ab87-b192-4b8c-b755-7a0d37c343b2 to local_8800ab87-b192-4b8c-b755-7a0d37c343b2[2{0=>0}]] group=local_8800ab87-b192-4b8c-b755-7a0d37c343b2 reporter=job-consumer-8800ab87-b192-4b8c-b755-7a0d37c343b2 to=local_8800ab87-b192-4b8c-b755-7a0d37c343b2[2{0=>0}]
time=2021-12-06T20:01:14+01:00 level=debug msg=left CommitOffsetsSync[group local_8800ab87-b192-4b8c-b755-7a0d37c343b2] group=local_8800ab87-b192-4b8c-b755-7a0d37c343b2 reporter=job-consumer-8800ab87-b192-4b8c-b755-7a0d37c343b2
time=2021-12-06T20:01:14+01:00 level=info msg=assigning partitions[why clearing assignment at end of group management session how unassigning everything input map[]] how=unassigning everything input=map[] reporter=job-consumer-8800ab87-b192-4b8c-b755-7a0d37c343b2 why=clearing assignment at end of group management session
time=2021-12-06T20:01:14+01:00 level=info msg=flushing[] reporter=job-producer
time=2021-12-06T20:01:14+01:00 level=debug msg=flushed[] reporter=job-producer

I looked into this and will change some internal code to hopefully improve this situation.
Currently, an unknown topic triggers an immediate update. When using metadata requests to create topics, Kafka does not assign a leader immediately, so the topic / partitions have no leader. This is considered a "failure" internally, and since this metadata request was from an immediate trigger, the client immediately retries again. This retry happens twice (three tries total), all very fast back to back, and Kafka has not assigned a leader in this time (<1s, per your logs). After three failures, the client triggers itself to load metadata slowly (metadata min age). This is the 10s pause you see, after which it requests again, and by that time Kafka has assigned a leader.
I'm going to change the code to not immediately re-issue a metadata request. The new code will only allow one extra retry when the metadata request has a true error (connection cut), since this case already retries 3x internally before getting to this point (it's retries all the way down). When the request is non-errored but has internal errors (no leader), I will allow retries up to a total of 8 requests, with a 250ms sleep between them. This gives immediate-triggers 2s to be successful, rather than the prior basically 0s.
As well, I'm going to change the default metadata min age to 5s. So, if Kafka still has not stabilized on a leader within 2s, the client will fall back to waiting 5s between attempts rather than 10
All told this will increase the number of metadata requests on per-partition failures. Immediate triggers only happen on per-partition errors, so ideally the increased number of metadata requests only happens when things are going south, and it may help recover in the client sooner.

Should be closed with https://github.com/twmb/franz-go/commit/8325ba7; if it is not, I'm not sure there's much more to do within the client to help this case.

(commenting in this because it seems like it's related) I think this introduced an issue when you start a consumer and immediately after create the topic.it seems like it's sleeping for ~2.5s upon calling PollFetches

This retries every 250ms 8 times in a row. What specific problem are you running into?

I wrote a snippet to illustrate what I think the issue is:
func TestFranzPollHanging(t *testing.T) {
	topicID := uuid.NewString()

	// Create client used to consume
	subCl, err := kgo.NewClient(
		kgo.SeedBrokers("localhost:9092"),
		kgo.ConsumeTopics(topicID),
	)
	if err != nil {
		t.Fatal(err)
	}

	// start polling for fetches
	wg := new(sync.WaitGroup)
	wg.Add(1)
	go func() {
		fmt.Println(">fetch", time.Now())
		for {
			cctx, cancel := context.WithTimeout(context.Background(), 300*time.Millisecond)
			defer cancel()

			rs := subCl.PollFetches(cctx)
			if rs.Err() == nil {
				fmt.Println("<fetch", time.Now())
				wg.Done()
				break
			}
			fmt.Println(" fetch", rs.Err())
		}
	}()

	// create topic
	admCl := kadm.NewClient(subCl)
	admCl.CreateTopics(context.Background(), 1, 1, nil, topicID)

	// Producing with new client
	fmt.Println(">produce", time.Now())
	pubCl, err := kgo.NewClient(kgo.SeedBrokers("localhost:9092"))
	if err != nil {
		t.Fatal(err)
	}

	pubCl.ProduceSync(context.Background(), &kgo.Record{Value: []byte("waiting"), Topic: topicID})
	fmt.Println("<produce", time.Now())

	wg.Wait()
}

This outputs the following:
=== RUN   TestFranz
>fetch 2022-05-24 18:40:32.063644477 -0300 -03 m=+0.001146096
>produce 2022-05-24 18:40:32.185176625 -0300 -03 m=+0.122678175
<produce 2022-05-24 18:40:32.213508301 -0300 -03 m=+0.151011737
<fetch 2022-05-24 18:40:34.572476576 -0300 -03 m=+2.509978615
--- PASS: TestFranz (2.51s)

As you can see, the producer runs virtually instantly after topic creation and 100ms after the fetch was called,  but the fetch hangs for 2.5s. I'd expect it to return before, probably after the 250ms and during the first retry. My hypothesis is the retry logic is probably broken - maybe some caching issue?

This is benign behavior that would only be encountered if trying to create a client and consume immediately after topic creation.  However, the fix is benign so I've done so here: https://github.com/twmb/franz-go/commit/f981856e89c99898aa0c86a7f463d733b1753c64
I still expect the client to take a bit if you, for example, use regex consuming and create a topic. The client only periodically updates metadata.
As well, if your topic doesn't exist and you try to consume it and then you only create the topic a minute later, it will still take the min metadata wait to discover it.

authors: AnatolyRugalev caioaao twmb

repo: twmb/franz-go


text:
How can I named zip file with folder name?

I want's to named .zip file with the name of folder, but can't find any method in doc, can you please help me to solve it? thanks!

For example
I have a project like this:
|  root
|_folder1
|_jquery.js
|_folder2
|_jquery.js
It should create two zip files like this:
|  folder1.zip
|_jquery.js
|  folder2.zip
|_jquery.js
Any solution? Thanks so much.

Each task will only generate a single zip file. You can dynamically configure grunt to generate new tasks for the folders:
// Load in dependencies
var fs = require('fs');
var path = require('path');

module.exports = function (grunt) {
  // Create a task for each folder
  var zipConfig = {};
  var folders = fs.readdirSync('root');
  folders.forEach(function createZipTask (folder) {
    // Save all folder contents to zip file (e.g. `root/folder1/*.*`)
    var folderGlob = path.join('root', folder, '*.*');
    var filename = folder + '.zip';
    zipConfig[filename] = folderGlob;
  });

  // Save config to grunt
  grunt.config.set('zip', zipConfig);

  // Load in our grunt tasks
  grunt.loadNpmTasks('grunt-zip');
};

Alternatively, you can create a task for each folder via hardcoding.

authors: galenyuan twolfson

repo: twolfson/grunt-zip


text:
cell menu do not close when you click on another one

This is a regression

Normally a click on anywhere on the page causes the window click handler for the menus to fire and close themselves, however our good friends jquery ui and angular decided that they should prevent default on the toggle click thus killing the click event and preventing it from bubbling up to the window and thus preventing the other menus from closing.

Investigating a real fix

If we take a look at the current implementation of the dropdown menu from bootstrap we can see that this prevent default is not actually present:

https://github.com/twbs/bootstrap/blob/83bfff7f0765503b990b96c303eef67009e48d77/js/dropdown.js#L58-L91
The current angular port of the dropdown logic in the angular directive is from 2012, so we are quite a bit behind from how actual bootstrap works.

authors: ildipo samccone

repo: twosigma/beaker-notebook


text:
take 2: Fix z-index cell stacking bug.

I have tested advanced mode, none advanced mode, and clicking on cell contents, it all seems to work.
Let me know if you find anything else

Fixes #1815
the z-index: 10 and node stacking lead to this bug, initially added in
https://github.com/twosigma/beaker-notebook/commit/eb17a7013701954ee03ad9544e82c147cfd8b647
But was a new "fix" from an earlier "fix" in #951
The origin of the issue, is simply in advanced mode, the combination of z-index, position attributes, DOM order, and codemirror z-index was messing up the stacking order of all of the elements. The solution was to reorder the DOM nodes and to remove the z-index of the codemirror pre.
ref:
https://developer.mozilla.org/en-US/docs/Web/Guide/CSS/Understanding_z_index/Stacking_context_example_1

QA looks good, giving CI another chance...

authors: samccone scottdraves


text:
cit/2966 fixed

This is a os dependent problem. In current moment tested for linux and windows os

Problem still exists for MacOS. I  do not have  MacOS at the current moment

:+1:

This thread is difficult (for me) to follow. Mentions "fixes" for windows. I'm running the windows download (recent) and still getting this very error. Did everything in terms of the config file; even installed ipython in python34 and python27; tried both in config file.  Just in case, my config is here: https://gist.github.com/KnowledgeGarden/3b2c714dd0c193ff8b75

authors: KnowledgeGarden kpaharelau scottdraves


text:
Moved some UserDefaults outside of Preferences to avoid unnecessary .body computations

Discussion in issue https://github.com/twostraws/ControlRoom/issues/107.
I moved some UserDefaults outside of Preferences class because they should be local state of some views instead of global shared state (e.g. filterText, carrier). I used @AppStorage for memory persistence accros launches.
For filterText I made the filterSimulator() func of SimulatorsController public to be able to update the list when filterText changes.
I also removed some useless .environmentObject(preferences) calls since it was already called higher in the view tree.
There are still some UserDefaults that could be removed from Preferences I think.
All those changes avoid lots of .body computations that were uselessly triggered by the many Preferences updates triggered by keystrokes (in URL and Carrier fields for instance) and updating the simulators list view.

This is really great work – thank you very much!

repo: twostraws/ControlRoom


text:
How can I test in my own .mat files?

I have converted my images to .mat files, later I realised that my files are not same as the testsets provided in the repository. Did anybody faced similar situation as mine?

@surajitsaikia27 Please refer the matlab code here

thanks..I have successfully implemented  :D

@surajitsaikia27請參考此處的matlab代碼

how to run this code? 😊

repo: twtygqyy/pytorch-SRResNet


text:
Loses single-line comments in source files

Stylus supports single-line comments, but they're lost in conversion.
E..g,
div {
  // http://stylus-lang.com/docs/comments.html#single-line
  margin 0  // http://stylus-lang.com/docs/comments.html#single-line
}

-->
div  {

  margin: 0;
}

@turadg HI~

@turadg Thank you for your question. I need to look at it.

@turadg My tool is based on stylus parser parsed ast object, stylus seems to abandon the handling of single-line comments when converting ast, so I have no way to handle single-line comments.

@turadg I added a new attribute to the stylus converter version 0.5.1. If you want to keep comments, just add -s yes in cli. I will change the single-line comment in the file to a multiline comment.


text:
EVM addon: iteration on constructs

What's our take on trying to merge the 4 required constructs we have today, to something that'd look like:
runtime "batch" {
    inputs = [
        evm::chain("arbitrum"),
        evm::chain("blast")
    ]
}

runtime "evm::defaults" {
    chain_id = env.evm_chain_id
    rpc_api_url = env.evm_rpc_api_url
    block_explorer_api_key = env.evm_block_explorer_api_key
}

wallet "alice" "evm::mnemonic" {
    mnemonic = "model elbow sunny fashion orient nominee symbol odor joy clown range lake"
}

// deploy simple storage contract
action "artifacts" "evm::deploy_contract" {
    foundry {
        manifest_path = env.foundry_toml_path
    }
    contract_name = "SimpleStorage"
    constructor_args = [1]
    chain_id = env.evm_chain_id
    rpc_api_url = env.evm_rpc_api_url
    signer = wallet.alice
    confirmations = 1
    verify = true
    block_explorer_api_key = env.evm_block_explorer_api_key
}

// deploy simple storage contract via create2
action "artifacts" "evm::instantiate_contract" {
    foundry {
        manifest_path = env.foundry_toml_path
    }
    contract_name = "SimpleStorage"
    constructor_args = [1]
    chain_id = env.evm_chain_id
    rpc_api_url = env.evm_rpc_api_url
    signer = wallet.alice
    confirmations = 1
    verify = true
    block_explorer_api_key = env.evm_block_explorer_api_key
}

Address with latest!

repo: txtx/txtx


text:
[menu] Menu doesn't close when button isn't in the DOM yet at time of initialization

Describe the bug:
When <forge-menu> is used with a button that is not yet in the DOM at time of initialization, the menu is unable to be closed by clicking off. This could be a problem, especially such as in frameworks like Angular with components that are button wrappers. In our instance, we have a button component and the button element is ngIf'd out of the DOM until a condition is met (it's bound to an | async pipe). It appears that if there is no match for the menu selector, it defaults to just assuming the first child element is the button. This is not valid, as the component only behaves properly if it's in fact a button, and this could result in a targetElement that is not a button (exactly what's happening in our scenario).
Specifically, this line of code is problematic, and should likely wait until it finds a selector match before setting the targetElement
https://github.com/tyler-technologies-oss/forge/blob/04741554822b7b4b5831d5146cf1ed4f4ed225a0/src/lib/menu/menu-adapter.ts#L54
To Reproduce:
Steps to reproduce the behavior:

Use a  with a nested  (or some non-button element inside)
Add a button to the  after forge-menu has been initialized (or if using angular, can simply ngIf this button into the dom after initiailization)
Notice the button works to open the menu, but you cannot click off to close.

Expected behavior:
Clicking off of the forge-menu should always close the forge-menu
Please complete the following information:

Forge version: v2.13.1
I have searched existing issues before creating this report? Y
Browser: All
Platform: All
OS: All

We were able to workaround this by doing element.dispatchEvent(new Event('blur')) from the firstElementChild of 'forge-menu'.

repo: tyler-technologies-oss/forge


text:
Small note about ember-template-imports

This was a setup configuration detail that would have saved me some time!

Thanks!

authors: TechieQian chriskrycho

repo: typed-ember/glint


text:
Response.failure? behaves differently under WebMock

Did some debugging to see why a test in my code didn't catch a redirect error.
Definition of success?
Definition of failure?
When fetching a URL that redirects with followlocation: false the variables get the following values:
mock = nil
return_code = :ok
response_code = 302
This means that success? becomes false because it is not a good response code, and failure? becomes false because return_code != :internal_server_error, so both are false. Surprising that these doesn't give the same result.
However in my test mock becomes :webmock which means that success? is still false, but now failure? become true because return_code doesn't matter any longer, and it is a bad response code.
I don't know if failure? should return true or false here, but I expect to get the same result under WebMock.

This recently caused a lot of trouble for my team and I, as we were working on improving the error handling we wrote a code similar to this that would raise an exception if there was an error with the request. This method of course came with some tests ensuring proper behavior
def item(id)
  response = Typhoeus.get "https://example.com/item/#{id}"
  raise 'Item could not be retrieved' if response.failure?
  MultiJson.load(response.body, symbolize_keys: true)
end

it 'indexes item with id' do
  stub_request(:get, 'https://example.com/item/1').to_return(status: 200, body: { id: 1 }.to_json)
  item_1 = items 1
  expect(item_1[:id]).to eq(1)
end

it 'raises error on 404' do
  stub_request(:get, 'https://example.com/item/1').to_return(status: 404)
  expect { items 1 }.to raise_error
end

it 'raises error on 500' do
  stub_request(:get, 'https://example.com/item/1').to_return(status: 500)
  expect { items 1 }.to raise_error
end

it 'raises error on timeout' do
  stub_request(:get, 'https://example.com/item/1').and_timeout
  expect { items 1 }.to raise_error
end

It wasn't until after we deployed this code to production that we noticed strange behavior, as only 5XX were considered failure any 404 or timeout was considered successful and would not raise an error. The main problem with this is that both methods work differently on test and productive environments, which makes it really hard to avoid in the first place.
The failure? method is implemented as follows; in a mocked environment it checks for status code != 2XX, but in production the return_code == :internal_server_error is evaluated which reduces this range to status code == 5XX
def failure?
  (mock || return_code == :internal_server_error) && response_code && has_bad_response_code?
end

authors: eruizc-dev stenlarsson

repo: typhoeus/typhoeus


text:
Promise Rejection

This is what I'm getting
Possible Unhandled Promise Rejection ... JSON Parse error: Unexpected EOF
And this is my request
export const request = (endPoint, payload = {}, method = 'get', headers = {}) => {
    return new Promise((resolve, reject) => {
        fetchival(`http://localhost...`, options)[method.toLowerCase()](payload)
        .then((json) => {
            return resolve(json)
        })
        .catch((e) => {
            if (e.response && e.response.status === 500) {
                console.warn('URL:', tmp, 'OPTIONS:', options, 'PAYLOAD:', payload, 'EXCEPTION:', e)
                return reject(new Error('Server error.'))
            }
            if (e.response && e.response.json) {
                e.response.json().then((json) => {
                    return reject(json.error)
                })
            } else {
                console.warn('URL:', tmp, 'OPTIONS:', options, 'PAYLOAD:', payload, 'EXCEPTION:', e)
                return reject(new Error('Server error.'))
            }
        })
    })
})

request().then(() => {

}).catch(() => {
    // still can't catch the propper error
})

But none of these catch it's working
What could I be doing wrong?

Never mind, just changing the if (e.response && e.response.status === 500) { worked.

repo: typicode/fetchival


text:
nth:1.0.1

I am submitting

[ ] a new package
[x] an update for a package

Description: add category and keywords for integration with Typst Universe, and add other authors to license file. Otherwise, this is a minor update, no important changes.

Thank you :)

authors: elegaanz extua

repo: typst/packages


text:
Handle compiler panics when handling infinite lengths

See #1918.
This currently fixes:

NaN results when multiplying a zero Abs or Em unit with infinity, or multiplying an infinite unit with zero

TODO:

[ ] Error when addition or subtraction between Scalars would produce a NaN result (would have to replace the Add and Sub impls with fallible equivalents)
[ ] Fix panic with grid
[ ] Fix panic with line
[ ] Fix panic with polygon

Having to deal with fallability across the whole layout code sounds like a huge pain. Rather than fixing individual panics across different layouters, I wonder whether we can find a general way to deal with this (perhaps by "normalizing" NaN to zero or something).

perhaps by "normalizing" NaN to zero or something

That’s probably the simplest fix to the issues with arithmetic, though I’m concerned about this introducing surprising behavior (like 2pt + infpt - infpt != 2pt).

I think 2pt + infpt - infpt != 2pt is okay. It just isn't well defined. That would also be a problem in pretty much every other programming language.

The panics with frames of infinite sizes probably still remain. Do you also want to address those in this PR or is it ready now?

I think these can be done in a future PR.

Thanks!

repo: typst/typst


text:
Make math.italic compatible with ħ

U+210F ℏ PLANCK CONSTANT OVER TWO PI (present in sym as planck.reduce) seems to be the mathematical italic counterpart of U+0127 ħ LATIN SMALL LETTER H WITH STROKE, as suggested in the chart:

Thanks!


text:
添加workflows功能

What would you like to be added?
添加workflows功能
Why is this needed?
实现ci/cd功能
Acceptance Criteria

放在.github文件夹

具体功能有那些啊

authors: tyvekzhang weiqiang-zhang

repo: tyvekzhang/fastapi-sqlmodel-starter


text:
fix bug if image files have multiple filename extensions

The saveFileDialog function has a small bug. I the save dialog box, if you just click "save", and if your image name have multiple extensions, like this: foo.001.jpg,  foo.002.jpg, foo.003.jpg, all your xml will be saved as foo.xml, which is not what you want. Because you need: foo.001.xml, foo.002.xml, foo.003.xml. The problem is caused by:
return os.path.splitext(fullFilePath)[0]
So I just return:
 return fullFilePath+".xml"

The solution is a workaround.

authors: icyhearts tzutalin

repo: tzutalin/labelImg


text:
take audio from mp4 video using ffmpeg

I'm trying to take audio from an mp4 video. I don't want to create extra local files, but I can't pass the input otherwise.
I transfer the created file and return the audio to io.Reader(audio var):
telegramFile, err := r.bot.GetFile(&msg.VideoNote.File)
if err != nil {
    // handling error
}
fileBytes, err := io.ReadAll(telegramFile)
if err != nil {
    // handling error
}

inputFile := fmt.Sprintf("%s.mp4", msg.VideoNote.File.FileID)
err = ioutil.WriteFile(inputFile, fileBytes, 0o600)
if err != nil {
    // handling error
}

audio := bytes.NewBuffer(nil)
err = ffmpeg.Input(
    inputFile,
).
    Output("pipe:1", ffmpeg.KwArgs{"format": "wav"}).WithOutput(audio).Run()
if err != nil {
    // handling error
}

I am sending io.Reader(telegramFile var) and get io.Reader(audio var):
telegramFile, err := r.bot.GetFile(&msg.VideoNote.File)
if err != nil {
    // handling error
}

audio := bytes.NewBuffer(nil)
err = ffmpeg.Input(
    "pipe:0", ffmpeg.KwArgs{"format": "mp4"},
).
    Output("pipe:1", ffmpeg.KwArgs{"format": "wav"}).WithInput(telegramFile).WithOutput(audio).Run()
if err != nil {
    // handling error
}

the first code works, but I need the second one. The conversion is performed, but the audio is invalid. Too few bytes.
here is an example of using input -> output https://github.com/u2takey/ffmpeg-go/blob/8af5c3849807dcda756406a7b2b3631a5c90d53b/ffmpeg_test.go#L330

@nakem1 I've stumbled on the same problem. ffmpeg can't process mp4 files with pipes due to mp4 format structure. Here is a more detailed answer on SO https://stackoverflow.com/questions/62823746/ffmpeg-piping-doesnt-work-with-mp4-files


text:
Feature/#59  co2 sensor data

#59
実装内容

SensorDataを管理するSensorDataManagerを作成。SensorDataManager.Instance.GetSensorData("名前")で参照できる。
MqttControllerがSensorDataを取得した際、SensorDataManagerが存在していればデータを送るようにした。
CO2SceneにMQTTやセンサー情報管理全般を担うSensorControllerオブジェクトを追加
センサー情報を取得し、二酸化炭素情報を表示するTextMeshProUGUI用のComponentを作成、適用した。
Fontを適用する日本語フォントの文字数を少し増やした。

仕様

MqttControllerはSensorDataManagerを持つオブジェクトがシーン上に無くても機能する。
CO2InfoTextUIコンポーネントインスペクタのTextFormat欄に表示内容を入力する。なお、string.Format関数に従い{0}が二酸化炭素濃度に、{1}が二酸化炭素個数に変換される。

確認事項

[ ] SensorControllerオブジェクトのMqttControllerに情報を入力し、Mqtt通信ができる（ログに通信状態が出力）
[ ] node-redからstatなどを含むデータが返されると、データがManagerに保存される（SaveData:~~とログ表示）
[ ] 実行後、CO2濃度や分子個数が変動した際にテキスト内容が更新される。
[ ] テキストの表示文章は仮なので、CO2濃度の単位追加や文章変更をする可能性あり。

#58
追記します。すみません。
#59の流れで#58の実装までしてしまいました。


text:
Websockets randomly closing with code CLOSE_ABNORMAL when using autoping

I just upgrade uws and enabled autoping and after 10-20 seconds my sockets are closing with code 1006. Am I misunderstanding the purpose of autoping, or is this a bug?

If you pass a message to it, the client needs to respond in time.

I assumed this was lower level than the client js interface, but are you saying I need to call ws.send for every onmessage callback?

You need to read the release text, and also tell me more than this. You haven't really described anything of what you are doing. I cannot guess what you are trying to do. We use this autoping feature at DS and it works there.

It's just a basic node server and chrome client. I'll just go back to my own scheme, apologies.

I am also getting that CLOSE_ABNORMAL when using autoping with code 1006 , any fix ?

I also use autoping, working fine on local server, but on AWS (ALB).
I got a disconnection after a 2 minutes or so with code 0x3ee (1006, CLOSE_ABNORMAL) and no message.
I use a workaround : I sent a lightweight message with send every 30 seconds and it fixes the issue (no disconnection)
@alexhultman not sure if it's related to uWebSockets in itself, but the autoping feature is not working properly with AWS Application Load Balancer.

repo: uNetworking/uWebSockets


text:
Test suite fails on ubuntu 17.04  clean install

What operating system are you running?
Ubuntu 17.04 fresh install
-libboost-dev-all 1.62.0.1
-libuv (from source or from apt repos results in same issue)
Are you running any CPU architechute out of the normal?

I run 64-bit in the year 2017
7700K intel i7

What platform/language are you using?

C++

What version of uws are you using?

master

What features of µWS are involved in the issue?

Server support (WebSocket)
Client support (WebSocket)
Server support (HTTP)

How does the issue reproduce?

All the time

Can you show me some short code that triggers your issue or any other important information?
Running the testsuite by
make
make install
make tests
./testsBin

Results in:
SSL: 1
CLIENT CLOSE: 1000
SERVER CLOSE: 1000
Throughput: 0.0108696 echoes/ms (92 ms elapsed)
POSTing 0 bytes
POSTing 1000000 bytes
POSTing 2000000 bytes
POSTing 3000000 bytes
POSTing 4000000 bytes
POSTing 5000000 bytes
POSTing 6000000 bytes
POSTing 7000000 bytes
POSTing 8000000 bytes
POSTing 9000000 bytes
FAILURE: expectedRequests differ: 0

Maybe you are running other servers or multiple instances of the test? It looks very weird, those "POSTing"s should block until finished and it should print stuff in between. I just ran the test and everything finished as it should.

Same results as OP, same conditions except:

Linux Mint 17.3 (Ubuntu 14.04.5)
Intel(R) Core(TM) i7 CPU         870  @ 2.93GHz
NO libboost-dev-all

Same results as @ampyx , same conditions except:

Aliyun CentOS 6.7
NO libboost-dev-all

Once I comment testHTTP() in the test suite, all the reset test can be passed.
int main(int argc, char *argv[])
{
    //serveEventSource();
    //serveHttp();
    //serveBenchmark();

#ifdef UWS_THREADSAFE
    testThreadSafety();
#endif

    // These will run on Travis OS X
    testReceivePerformance();
    testStress();
    //testHTTP();
    testSmallSends();
    testSendCallback();
    testRouting();
    testClosing();
    testListening();
    testBroadcast();
    testMessageBatch();
    testAutoPing();
    testConnections();
    testTransfers();

    // Linux-only feature
#ifdef __linux__
    testReusePort();
#endif

    //testAutobahn();
}

./testsBin
Messages per microsecond: 35.456
Messages per microsecond: 35.4761
Messages per microsecond: 35.6722
Messages per microsecond: 35.7641
Messages per microsecond: 35.7462
Messages per microsecond: 35.6519
Messages per microsecond: 35.6608
Messages per microsecond: 35.7373
Messages per microsecond: 35.7245
Messages per microsecond: 35.7003
Messages per microsecond: 35.5834
Messages per microsecond: 35.7424
Messages per microsecond: 35.6952
Messages per microsecond: 35.671
Messages per microsecond: 35.6443
Messages per microsecond: 35.6812
Messages per microsecond: 35.6837
Messages per microsecond: 35.7003
Messages per microsecond: 35.5581
Messages per microsecond: 35.7411
Messages per microsecond: 35.6786
Messages per microsecond: 35.0165
Messages per microsecond: 35.5518
Messages per microsecond: 35.6773
Messages per microsecond: 35.6532
Messages per microsecond: 35.5821
Messages per microsecond: 35.7105
Messages per microsecond: 35.1815
Messages per microsecond: 35.1791
Messages per microsecond: 35.6786
Messages per microsecond: 35.6926
Messages per microsecond: 35.3794
Messages per microsecond: 34.4495
Messages per microsecond: 35.4158
Messages per microsecond: 35.6354
Messages per microsecond: 35.6633
Messages per microsecond: 35.6608
Messages per microsecond: 35.7015
Messages per microsecond: 35.6341
Messages per microsecond: 35.4635
Messages per microsecond: 35.7322
Messages per microsecond: 35.7079
Messages per microsecond: 35.6824
Messages per microsecond: 35.5417
Messages per microsecond: 35.6481
Messages per microsecond: 35.6595
Messages per microsecond: 35.6392
Messages per microsecond: 35.671
Messages per microsecond: 35.6646
Messages per microsecond: 35.6608
Messages per microsecond: 35.6659
Messages per microsecond: 35.5556
Messages per microsecond: 35.6595
Messages per microsecond: 35.6875
Messages per microsecond: 35.699
Messages per microsecond: 35.6977
Messages per microsecond: 35.7513
Messages per microsecond: 35.6265
Messages per microsecond: 35.6227
Messages per microsecond: 35.5051
Messages per microsecond: 35.6964
Messages per microsecond: 35.4635
Messages per microsecond: 35.6392
Messages per microsecond: 35.7309
Messages per microsecond: 35.6888
Messages per microsecond: 35.6481
Messages per microsecond: 35.6608
Messages per microsecond: 35.6824
Messages per microsecond: 35.3444
Messages per microsecond: 35.6722
Messages per microsecond: 34.5018
Messages per microsecond: 35.7539
Messages per microsecond: 35.7449
Messages per microsecond: 35.5973
Messages per microsecond: 35.699
Messages per microsecond: 35.759
Messages per microsecond: 35.7782
Messages per microsecond: 35.7833
Messages per microsecond: 35.7948
Messages per microsecond: 35.7743
Messages per microsecond: 35.8012
Messages per microsecond: 35.8038
Messages per microsecond: 35.7398
Messages per microsecond: 35.8038
Messages per microsecond: 35.7833
Messages per microsecond: 35.7871
Messages per microsecond: 35.7923
Messages per microsecond: 35.7923
Messages per microsecond: 35.7705
Messages per microsecond: 35.7807
Messages per microsecond: 35.7679
Messages per microsecond: 35.7679
Messages per microsecond: 35.8025
Messages per microsecond: 35.7897
Messages per microsecond: 35.7641
Messages per microsecond: 35.7859
Messages per microsecond: 35.7679
Messages per microsecond: 35.7807
Messages per microsecond: 35.7846
Messages per microsecond: 35.7846
[Size: 1, echoes: 1]
SSL: 0
CLIENT CLOSE: 1000
SERVER CLOSE: 1000
Too small load!
SSL: 1
CLIENT CLOSE: 1000
SERVER CLOSE: 1000
Throughput: 0.0769231 echoes/ms (13 ms elapsed)
[Size: 2, echoes: 1]
SSL: 0
CLIENT CLOSE: 1000
SERVER CLOSE: 1000
Too small load!
SSL: 1
CLIENT CLOSE: 1000
SERVER CLOSE: 1000
Throughput: 0.0769231 echoes/ms (13 ms elapsed)
[Size: 4, echoes: 1]
SSL: 0
CLIENT CLOSE: 1000
SERVER CLOSE: 1000
Too small load!
SSL: 1
CLIENT CLOSE: 1000
SERVER CLOSE: 1000
Throughput: 0.0769231 echoes/ms (13 ms elapsed)
[Size: 8, echoes: 1]
SSL: 0
CLIENT CLOSE: 1000
SERVER CLOSE: 1000
Too small load!
SSL: 1
CLIENT CLOSE: 1000
SERVER CLOSE: 1000
Throughput: 0.0769231 echoes/ms (13 ms elapsed)
[Size: 16, echoes: 1]
SSL: 0
CLIENT CLOSE: 1000
SERVER CLOSE: 1000
Too small load!
SSL: 1
CLIENT CLOSE: 1000
SERVER CLOSE: 1000
Throughput: 0.0769231 echoes/ms (13 ms elapsed)
[Size: 32, echoes: 1]
SSL: 0
CLIENT CLOSE: 1000
SERVER CLOSE: 1000
Too small load!
SSL: 1
CLIENT CLOSE: 1000
SERVER CLOSE: 1000
Throughput: 0.0769231 echoes/ms (13 ms elapsed)
[Size: 64, echoes: 1]
SSL: 0
CLIENT CLOSE: 1000
SERVER CLOSE: 1000
Too small load!
SSL: 1
CLIENT CLOSE: 1000
SERVER CLOSE: 1000
Throughput: 0.0769231 echoes/ms (13 ms elapsed)
[Size: 128, echoes: 1]
SSL: 0
CLIENT CLOSE: 1000
SERVER CLOSE: 1000
Too small load!
SSL: 1
CLIENT CLOSE: 1000
SERVER CLOSE: 1000
Throughput: 0.0769231 echoes/ms (13 ms elapsed)
[Size: 256, echoes: 1]
SSL: 0
CLIENT CLOSE: 1000
SERVER CLOSE: 1000
Too small load!
SSL: 1
CLIENT CLOSE: 1000
SERVER CLOSE: 1000
Throughput: 0.0769231 echoes/ms (13 ms elapsed)
[Size: 512, echoes: 1]
SSL: 0
CLIENT CLOSE: 1000
SERVER CLOSE: 1000
Too small load!
SSL: 1
CLIENT CLOSE: 1000
SERVER CLOSE: 1000
Throughput: 0.0769231 echoes/ms (13 ms elapsed)
[Size: 1024, echoes: 1]
SSL: 0
CLIENT CLOSE: 1000
SERVER CLOSE: 1000
Too small load!
SSL: 1
CLIENT CLOSE: 1000
SERVER CLOSE: 1000
Throughput: 0.0769231 echoes/ms (13 ms elapsed)
[Size: 2048, echoes: 1]
SSL: 0
CLIENT CLOSE: 1000
SERVER CLOSE: 1000
Too small load!
SSL: 1
CLIENT CLOSE: 1000
SERVER CLOSE: 1000
Throughput: 0.0714286 echoes/ms (14 ms elapsed)
[Size: 4096, echoes: 1]
SSL: 0
CLIENT CLOSE: 1000
SERVER CLOSE: 1000
Too small load!
SSL: 1
CLIENT CLOSE: 1000
SERVER CLOSE: 1000
Throughput: 0.0769231 echoes/ms (13 ms elapsed)
[Size: 8192, echoes: 1]
SSL: 0
CLIENT CLOSE: 1000
SERVER CLOSE: 1000
Too small load!
SSL: 1
CLIENT CLOSE: 1000
SERVER CLOSE: 1000
Throughput: 0.0769231 echoes/ms (13 ms elapsed)
[Size: 16384, echoes: 1]
SSL: 0
CLIENT CLOSE: 1000
SERVER CLOSE: 1000
Too small load!
SSL: 1
CLIENT CLOSE: 1000
SERVER CLOSE: 1000
Throughput: 0.0666667 echoes/ms (15 ms elapsed)
[Size: 32768, echoes: 1]
SSL: 0
CLIENT CLOSE: 1000
SERVER CLOSE: 1000
Too small load!
SSL: 1
CLIENT CLOSE: 1000
SERVER CLOSE: 1000
Throughput: 0.0666667 echoes/ms (15 ms elapsed)
[Size: 65536, echoes: 1]
SSL: 0
CLIENT CLOSE: 1000
SERVER CLOSE: 1000
Too small load!
SSL: 1
CLIENT CLOSE: 1000
SERVER CLOSE: 1000
Throughput: 0.0714286 echoes/ms (14 ms elapsed)
[Size: 131072, echoes: 1]
SSL: 0
CLIENT CLOSE: 1000
SERVER CLOSE: 1000
Too small load!
SSL: 1
CLIENT CLOSE: 1000
SERVER CLOSE: 1000
Throughput: 0.0625 echoes/ms (16 ms elapsed)
[Size: 262144, echoes: 1]
SSL: 0
CLIENT CLOSE: 1000
SERVER CLOSE: 1000
Throughput: 1 echoes/ms (1 ms elapsed)
SSL: 1
CLIENT CLOSE: 1000
SERVER CLOSE: 1000
Throughput: 0.0588235 echoes/ms (17 ms elapsed)
[Size: 524288, echoes: 1]
SSL: 0
CLIENT CLOSE: 1000
SERVER CLOSE: 1000
Throughput: 0.333333 echoes/ms (3 ms elapsed)
SSL: 1
CLIENT CLOSE: 1000
SERVER CLOSE: 1000
Throughput: 0.047619 echoes/ms (21 ms elapsed)
[Size: 1048576, echoes: 1]
SSL: 0
CLIENT CLOSE: 1000
SERVER CLOSE: 1000
Throughput: 0.166667 echoes/ms (6 ms elapsed)
SSL: 1
CLIENT CLOSE: 1000
SERVER CLOSE: 1000
Throughput: 0.0333333 echoes/ms (30 ms elapsed)
[Size: 2097152, echoes: 1]
SSL: 0
CLIENT CLOSE: 1000
SERVER CLOSE: 1000
Throughput: 0.0714286 echoes/ms (14 ms elapsed)
SSL: 1
CLIENT CLOSE: 1000
SERVER CLOSE: 1000
Throughput: 0.0208333 echoes/ms (48 ms elapsed)
[Size: 4194304, echoes: 1]
SSL: 0
CLIENT CLOSE: 1000
SERVER CLOSE: 1000
Throughput: 0.0344828 echoes/ms (29 ms elapsed)
SSL: 1
CLIENT CLOSE: 1000
SERVER CLOSE: 1000
Throughput: 0.0104167 echoes/ms (96 ms elapsed)
[Size: 8388608, echoes: 1]
SSL: 0
CLIENT CLOSE: 1000
SERVER CLOSE: 1000
Throughput: 0.0123457 echoes/ms (81 ms elapsed)
SSL: 1
CLIENT CLOSE: 1000
SERVER CLOSE: 1000
Throughput: 0.00578035 echoes/ms (173 ms elapsed)
[Size: 16777216, echoes: 1]
SSL: 0
CLIENT CLOSE: 1000
SERVER CLOSE: 1000
Throughput: 0.00666667 echoes/ms (150 ms elapsed)
SSL: 1
CLIENT CLOSE: 1000
SERVER CLOSE: 1000
Throughput: 0.0030581 echoes/ms (327 ms elapsed)
Connected, will send small messages now
Falling through testSmallSends
Correct data was sent to send callback
testRouting passed, falling through
Server recives terminate close code after terminating
Client gets terminated on first connection
Server receives correct close code after closing
Client gets closed on second connection with correct close code
Falling through after testClosing!
Server emits error listening to port 80 (permission denied)
Server listens to port 3000
Server emits error listening to port 3000 twice
Server falls through after group closes
Broadcasting & closing now!
Falling through now!
Received message from batch: hello
Received message from batch: world
PING
PONG
PING
PONG
PING
PONG
Client emitted error on invalid URI
Client emitted error on invalid protocol
Client emitted error on resolve failure
Client emitted error on poll error
Client emitted error on connection timeout (non-SSL)
Client emitted error on connection timeout (SSL)
Client established a remote connection over non-SSL
Client got disconnected with data: 0x8, code: 1000, message: <>
Client established a remote connection over SSL
Client got disconnected with data: 0x9, code: 1000, message: <>
Client emitted error on HTTP response without upgrade (non-SSL)
Client emitted error on HTTP response without upgrade (SSL)
Falling through testConnections
Message 1: first message here
Message 2: second message
Message 3: some broadcast here
Message 4: binary
Message 1: first message here
Message 2: second message
Message 3: some broadcast here
Message 4: binary
Falling through testMultithreading
Can listen to same port twice!

authors: alexhultman ampyx irondune yaoyinbear