pythonPackages.tensorflow: 1.3.1 -> 1.4.1

Also revert to a wheel-based build (the bazel-based build is broken
and it is unclear how to repair it)
Motivation for this change
Two motivations:

Tensorflow does not currently build in master
Upstream update

Things done

[ ] Tested using sandboxing (nix.useSandbox on NixOS, or option build-use-sandbox in nix.conf on non-NixOS)
Built on platform(s)

[x] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nox --run "nox-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
[x] Fits CONTRIBUTING.md.

@FRidh Would you think that this version is acceptable? (@abbradar still has not given any sign of activity)

@jyp Apparently Arch is able to build 1.5x from git. Might try to dig into it this weekend – when I try to build 1.5, bazel throws errors about jemalloc caused by various scoping issues which I'd imagine are straightforward to fix.
My 1.5x branch
Build log

@jyp (continuation from #31492)

I have another PR with 1.4 which should be mergeable now. If you support the revert to a wheel-based build please comment about it in the PR.

I'm not against getting this merged in the short term, but ideally we would trace down why the bazel build fails (source build would make #31046 straightforward to resolve). Easy to undo this if/when we get build from source working.
This method is nice since Bazel on Darwin is broken.

@lukeadams "Ideally" yes.  If someone can fix it I'll be happy to see the bazel build restored.  In practice tensorflow has been broken for three months in master now, hence this PR.

@proger Tensorboard is incompatible with python 3.6. https://github.com/tensorflow/tensorboard/issues/427

@proger Thanks a lot for your review. I acted on your suggestions but I've left the top-level definition as it was to minimize the diff with master. We can change that one separately. (It's hard enough to get the simplest PR merged.)

This patch is all that's necessary to build on Darwin:
From 5cbbb34a43cc431aeb40591042f3d61c31c88085 Mon Sep 17 00:00:00 2001
From: Luke Adams<EMAIL_ADDRESS>Date: Sat, 10 Feb 2018 10:18:50 -0600
Subject: [PATCH] tensorflow: move cudatoolkit_joined to top-level for clarity

allows for simplification of postFixup
---
 .../python-modules/tensorflow/default.nix          | 24 +++++++++++-----------
 1 file changed, 12 insertions(+), 12 deletions(-)

diff --git a/pkgs/development/python-modules/tensorflow/default.nix b/pkgs/development/python-modules/tensorflow/default.nix
index 5c5d98e7ace..ff34d02c4fa 100644
--- a/pkgs/development/python-modules/tensorflow/default.nix
+++ b/pkgs/development/python-modules/tensorflow/default.nix
@@ -31,8 +31,18 @@ assert ! (stdenv.isDarwin && cudaSupport);
 # project's build system is an arcane beast based on
 # bazel. Untangling it and building the wheel from source is an open
 # problem.
+let
+  # cudatoolkit is split (see https://github.com/NixOS/nixpkgs/commit/bb1c9b027d343f2ce263496582d6b56af8af92e6)
+  # However this means that libcusolver is not loadable by tensor flow. So we undo the split here.
+  cudatoolkit_joined = symlinkJoin {
+    name = "unsplit_cudatoolkit";
+    paths = [
+      cudatoolkit.out
+      cudatoolkit.lib
+    ];
+   };

-buildPythonPackage rec {
+in buildPythonPackage rec {
   pname = "tensorflow";
   version = "1.4.1";
   name = "${pname}-${version}";
@@ -82,17 +92,7 @@ buildPythonPackage rec {
   # patchelf --shrink-rpath will remove the cuda libraries.
   postFixup = let
     rpath = stdenv.lib.makeLibraryPath
-      (if cudaSupport then
-        # cudatoolkit is split (see https://github.com/NixOS/nixpkgs/commit/bb1c9b027d343f2ce263496582d6b56af8af92e6)
-        # However this means that libcusolver is not loadable by tensor flow. So we undo the split here.
-        (let cudatoolkit_joined = symlinkJoin {
-          name = "unsplit_cudatoolkit";
-          paths = [ cudatoolkit.out
-                    cudatoolkit.lib ];};
-         in [ stdenv.cc.cc.lib zlib cudatoolkit_joined cudnn nvidia_x11 ])
-      else
-        [ stdenv.cc.cc.lib zlib ]
-      );
+      ([ stdenv.cc.cc.lib zlib ] ++ lib.optionals cudaSupport [ cudatoolkit_joined cudnn nvidia_x11 ]);
   in
   ''
     rrPath="$out/${python.sitePackages}/tensorflow/:${rpath}"
--
2.15.1

I have applied the patch of @lukeadams
Could this PR be considered for merging? @FRidh ?

Tensorflow is still not building ( #31492 ), even after merging the PR of @abbradar .  Can we please merge this PR until the bazel build works? @FRidh ?

That's very strange as I'm using it right now. Can you show your error?

Ah, I see failure on Hydra (it was down today morning so I didn't check it first). The error is very strange; for now my theory is that something in nixpkgs has updated since the last successful build (https://hydra.nixos.org/build/69832610). Currently tensorflow doesn't build because of unrelated reasons on master; I'll see if I can reproduce the issue.

Thanks! Please report progress on #31492, I'll ping you from there.

Just wanted to mention: building from source prevents the use of TF on Darwin until #30590 / #32080 are fixed.

@lukeadams Yeah, I want to tackle that next -- or return wheel-based build specifically for Darwin.

I've tried to set up a Mac OS X VirtualBox machine but apparently AMD processors are not supported, and on an image from https://forum.amd-osx.com/ mouse and keyboard do not work.
@LnL7 Can you perhaps set a Darwin Hydra job for my tensorflow branch again? For now I've reset it to be just master.

@abbradar in case it is not possible to get the source builds working entirely on all supported archs, I think we should still provide the wheel-based solution, at least for 18.03, for all archs.
In that case, @jyp, I recommend including the script you used as an actual script in the tree. Also, instead of bothering to write .nix you can just output .json.

@FRidh Yeah, that's my opinion too -- I thought I'd try to tackle this one on holidays before giving up completely.

@jyp I feel too defeated by Darwin for now D: Can you rebase this pull request and make it be used only for Darwin? I can do it by myself if you don't have enough time. Thanks in advance!

@abbradar I am completely swamped at the moment so it's great if you can take this (I am not even a darwin user btw). Additionally I wouldn't even know how to apply the advice of @FRidh.


TextField label position when changing fontsize

Problem description
When you change TextField's fontSize, the label translate() position isn't changing according to font size.
which leads to the label being too close to the text of the input.
Steps to reproduce
Take a text field, change font size, type. (40px for an example)
before changing shrink translate - http://prntscr.com/gggmsg
after changing - http://prntscr.com/gggmf0
Versions

Material-UI: latest v1-beta
React: latest
Browser: chrome

Maybe we could be changing the InputLabel transformation value to take the font size into account in the formula, but I have some doubt about the viability of such rule.
So I think that the best way to handle this is to also change the translation value on userland.


Remove active_support Time extensions

[x] Have you followed the guidelines in our Contributing document?
[x] Have you checked to ensure there aren't other open Pull Requests for the same change?
[x] Have you added an explanation of what your changes do and why you'd like us to include them?
[ ] Have you written new tests for your changes? Here's an example.

[x] Have you successfully run brew typecheck with your changes locally?
[x] Have you successfully run brew tests with your changes locally?

As requested in https://github.com/Homebrew/brew/issues/10508, I was looking at the performance of requiring various ActiveSupport require statements, and noticed that 35-39% of the time in global.rb was spent in require "active_support/core_ext/numeric/time" (as measured via brew prof --stackprof help):

This PR removes that require statement, and cleans up related code.
The long pole of ActiveSupport require statements is now require "active_support/core_ext/string/inflections", at 6.9-7.8% of time in global.rb:

The long pole of ActiveSupport require statements is now require "active_support/core_ext/string/inflections", at 6.9-7.8% of time in global.rb:

Would be game to remove that next, I think!

Note that this is a risky change. I found some use of the extensions that weren't covered by tests by grepping for the most common 🐵 patches, but could easily have missed others.
Note that I also tried removing the parts of the ActiveSupport rbi file that were concerned with time/duration to see if that would trigger any type errors (for demonstration only, reverted in a subsequent commit in this PR).

Thanks again @dduugg!

This caused breakage when referencing time.rfc3339:
Error: An exception occurred within a child process:
  NoMethodError: undefined method `rfc3339' for 2023-02-02 08:18:45 UTC:Time

Reverting this locally resolved the issue.

@p-linnane thanks for flagging, and apologies for the breakage. I've proposed a fix in https://github.com/Homebrew/homebrew-core/pull/122480 (and also listed some other approaches to resolve).

I wonder if we can just revert this PR and retry with a better fix for https://github.com/Homebrew/homebrew-core/pull/122480 (mostly for the sugar syntax stuff)


Scrolling values are strange

getScroll() works in a very strange way.
After reading the documentation i would expect it to return the number of line that is currently scrolled down.
for example if i scroll one line down i expect it to return 1.
What i would expect it ti return is this:
var NrOfScrollableLines = Box.getScrollHeight() - Box.height;
Math.round(NrOfScrollableLines*(Box.getScrollPerc()/100));
//This may be a one line wrong cause of rounding so it would be better to get the value directly.

Box.alwaysScroll has to be on for this to work otherwize the terminal and blessed becomes unsynchronized.

Just had this issue myself, but found a simpler answer.
The value you'd expect getScroll() to give can actually be found with:
var offset = Box.childBase
Hope this helps.

Awesome find @niki-m, my earlier work-around had a bug everything the scrollbar would appear, this finally fixed that. Thanks!


ci: add a workflow that builds docs

This allows somebody who is enhancing the docs to check the results entirely through CI without having to set up the dependencies necessary for docs on their end. (Perfect for Dev Days.) It also ensures that any changes we make to the code base don't break the documentation somehow, because now a successful docs build will be part of the CI.
Note that the docs building job leave behind an artifact, which will be a zip file of the directly containing the HTML docs, just like one would fine on RTD, so you can download that zip file and view the docs it made to verify that everything looks right.
I made the docs builder a separate workflow, but I also changed some things in the CI workflow for the sake of making them more similar.

I downloaded the new artifact from the CI job.
this looks great! This is going to be really useful.


Atom not visible under "Other programs" in order to "open with" or set as default in Ubuntu

I installed the latest Atom 1.0.11 on Ubuntu 14.04 by opening atom-amd64.deb in Ubuntu's software center and installing from there. Next, when right-clicking a plain text file, Atom is not listed for "Open with", nor is it listed under "Other applications". This means it also wasn't possible to set it as the default program for .txt.
Adding %f at the end of the line Exec=/usr/share/atom/atom ... in ~/.local/share/applications/atom.desktop made Atom available in the Open with menu/tab. (not sure if this is Ubuntu-specific).

I'm using Ubuntu 15.04 with Atom 1.0.19 and I don't have any atom.desktop file under ~/.local/share/applications and in my case Atom is listed in "Open with" and "Other applications". However I did install Atom for the first time a long time ago (version 0.17x maybe?)

i had the same problem with Ubuntu 15.10. I fixed this problem using your solution.

Under Fedora, I cannot see Atom in the selection of a e.g. folder's OpenWith/All Applications list either.
In atom.desktop I find:
Exec=/usr/share/atom/atom %U

According to the desktop entry specification

%U: A list of URLs. Each URL is passed as a separate argument to the executable program. Local files may either be passed as file: URLs or as file path.

I guess this is at the end a problem with the OpenWith dialog not recognizing such applications (desktop files) since - from how I understand what is written in the spec - the %U Exec entries could be handled just in the same way as the %fs.
The relation is somehow %U ⊃ %u and %F ⊃ %f and %U ⊃ %F, conclusively %U ⊃ %f; which means that each entry that can handle %U should also be able to handle %f - or am I wrong?

Same here with Atom 1.6.1 under Ubuntu 15.10, also corrected using the fix proposed in the initial report
also, in atom.desktop the Name entry seemed a bit random, namely: Name=untitled — /home/some(semi-?)randompath — Atom

I'm on Ubuntu 14.04, adding %f or %F didn't solve the issue for me.
Tried many things with Desktop Entry: Adding removing properties, changing Exec to 'atom %F' (without path), adding MimeType of the file type I'm interested in, changing the Name to 'Atom1' (to avoid a possible collusion), and other minor changes. With and without %F or %U. None has worked.
I work with sudo, so file is saved properly.

Same here. :(


[release] Increase timeout of CI job

Even with a time limit of 5h (increased in 847f85160bcf396b9a5858cfcbc000a49ce380fa / PR #18952), the Release job still times out.  A trial run without timeout took 458min to complete.
This commit increases the timeout of the Release job to 500min, which is ca. 10% more than the currently expected run time to account for load variances.

Third PR is a charm ... (but seriously, now that we have seen the job complete in 458 min, a timeout of 500min should finally resolve this).
CC @cfrantz


Simplify ClientScene functions.

:tada: This PR is included in version 1.0.0 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


feature(tests): add python 3.11 to ci, skip tests

Summary
Added Python 3.11 to GitHub workflow:

setup
check-deps
lint
test_unit

Updated skip tests with hi_res parameter if the python version is higher 3.10.x

Closes issue #607

Closing in favor of #908


Speed up deployment

https://github.com/Azure/webapps-deploy/issues/60#issuecomment-791484833

Fixed deployment flakiness and increased the speed:

Turned of Oryx build
Turned off deployment center repo connection
Wrote deploy scripts for dist folder and startup


remove use of kubectl proxy for api calls

This is a rebase of https://github.com/simonleung8/service-catalog/pull/1 on top of jberkhahn/service-catalog plugin-cmds
cc @fabianofranz

Thanks @juanvallejo! I'm going to end up refactoring the commands a bit, I'll let you know when I submit the PR to the service catalog.


lean cooper command failing

Hi,
I have cloned the repo, ran npm install electron-prebuilt -g but then when I run the lein cooper command i get the following stack trace:

If I run: lein trampoline cljsbuild auto electron-dev and lein trampoline figwheel frontend-dev separately it works fine until I want to make any changes and re-run the application. It will then hang on Waiting for changes..
Apologies for my gap in knowledge. I am new to using clojure in this way.

It has nothing to do with clojure itself. You dont have env command for some reason on your macos. Or it might be missing from your $PATH.


Accept URL parameters

Hello,
I'm not proficient in Python, so by looking at the code I'm not sure if this is already supported. But it would be great if I could do something like:
curl http://vim-bootstrap.com/generate?editor=vim&langs=javascript,php,html,ruby > ~/.vimrc

working:
curl 'http://vim-bootstrap.com/generate.vim' --data 'langs=javascript&langs=php&langs=html&langs=ruby&editor=vim'

:+1:


Select images by index

Let user jump to a specific image by providing the index of the image (position in the dataset).


Inserts Not Working

Environment
HikariCP version: x.x.x
JDK version     : 1.8.0_111
Database        :  MySQL
Driver version  : unknown

I cannot get inserts working either by maually putting the values into the statement or by using the proper methods of PreparedStatments. The tables are created fine but when I go to try to insert it just doesn't work tried with executeBatch and executeUpdate and both returned 1. Here is the code https://pastebin.com/N2ErvhrP

I figured it out with the help of some people turns out I wasn't Committing and autocommit was false


An issue when capturing clipboard

Describe the bug
A clear and concise description of what the bug is.
When I try to capture what is on my clipboard, using templater clipboard template. It creates the file and copies the template but the template does not get replaced with the clipboard content. And it does not add a link or open the note after that. I have been using the exact same thing for a long time and this was happening rarely. But now it just doesn't work any longer. There is something going wrong with this plugin using templater , maybe need some more delay between commands. I have tested templater and it works fine on its own.
To Reproduce
Steps to reproduce the behavior:

Go to '...'
Click on '....'
Scroll down to '....'
See error

Expected behavior
A clear and concise description of what you expected to happen.
Screenshots
If applicable, add screenshots to help explain your problem.
Desktop (please complete the following information):

OS: [e.g. iOS]
Browser [e.g. chrome, safari]
Version [e.g. 22]
Windows 10
Smartphone (please complete the following information):
Device: [e.g. iPhone6]
OS: [e.g. iOS8.1]
Browser [e.g. stock browser, safari]
Version [e.g. 22]

Additional context
Add any other context about the problem here.

Show me your capture and I'll try to find the problem


[BUG]build image faild:Untar re-exec error: exit status 1: output: operation not supported

Output of docker version:
(paste your output here)
Client:
 Version:      1.10.2
 API version:  1.22
 Go version:   go1.5.3
 Git commit:   c3959b1
 Built:        Mon Feb 22 21:37:01 2016
 OS/Arch:      linux/amd64

Server:
 Version:      1.10.2
 API version:  1.22
 Go version:   go1.5.3
 Git commit:   c3959b1
 Built:        Mon Feb 22 21:37:01 2016
 OS/Arch:      linux/amd64

Output of docker info:
Steps to reproduce the issue:
i want to build an ubuntu image(download from ubuntu website, version=15.04.img), using scratch method,
1.the content of Dockerfile is below:
FROM scratch
ADD . /
RUN mkdir /var/run/sshd
RUN rm Dockerfile
CMD [\"/usr/sbin/sshd\", \"-D\"]

2.execute command: docker build -t ubuntu-15.04.0203 .
3.then failed
Describe the results you received:
Step 1 : FROM scratch
 --->
Step 2 : ADD . /
Untar re-exec error: exit status 1: output: operation not supported

Additional information you deem important (e.g. issue happens only occasionally):
this problem like #14792, but not the same, he solved his problem by updating the docker version, however, my docker version is up to date. Beside, i can succeed finish the above procedure when i use ubuntu-14.04.img, does anybody know how to fix this problem, thanks.
@thaJeztah， @arthurlogilab

i found a solution for the above problem, when i mount the ubuntu15.04 qcow2 image file on a directory, if i directly build with the above Dockerfile under the  mounted directory, it failed with the above error, if i remove the bin directory, it will succeed.

i don't know if it is a bug or something, does anybody knows that?

Is there a specific reason you're trying to build for own Ubuntu image, instead of using the official ubuntu:15.04 image? Note that you probably have to do more than just adding that image, to get a functional image. See this repository, which is used to create the official images; https://github.com/tianon/docker-brew-ubuntu-core/blob/master/update.sh

@thaJeztah yes, i just want to keep the docker image directories as the same as the ubuntu image. I will check the procedures of creating a official image, thank you.

@vklonghml I really recommend using the official images instead of trying to build your own Ubuntu base image. The official images are always kept up to date, so you don't have to maintain them yourself (but be aware that Ubuntu 15.04 is EOL, and will not get any updates from Ubuntu). So simply
FROM ubuntu:15.04
....

Also note that if you use a .dockerignore file, you don't have to remove the Dockerfile inside your image (if you add it to the ignore-list).
If you're looking for a simple example to build an SSH image, have a look here; https://docs.docker.com/engine/examples/running_ssh_service/

@thaJeztah ok, thanks a lot.


Set to SameSite to None for auth cookie

Another unforeseen fix required after #257
Cookies were set to SameSite=Strict, the issue is that our backend and frontend don't share the same home domain, and the cookie cannot be set on the deployment.
Regarding security:
This would open the possibility to CSRF attacks BUT we are also using CORS and limiting requests to the backend only from our deployments, so there should be no risk of that.

Oh that would be very nice. I didn't know it was possible. Certainly a good idea for production.


Rename attributes and default styles.

IMPORTANT: All PRs must be linked to an issue (except for extremely trivial and straightforward changes).
Fixes #1475
Description

Rename default styles and attributes in datacapture module.
try to differentiate style and attributes names from android default names.

Alternative(s) considered
Have you considered any alternatives? And if so, why have you chosen the approach in this PR?
Type
Choose one:  Code health
Screenshots (if applicable)
Checklist

[x] I have read and acknowledged the Code of conduct.
[x] I have read the Contributing page.
[x] I have signed the Google Individual CLA, or I am covered by my company's Corporate CLA.
[x] I have discussed my proposed solution with code owners in the linked issue(s) and we have agreed upon the general approach.
[x] I have run ./gradlew spotlessApply and ./gradlew spotlessCheck to check my code follows the style guide of this project.
[x] I have run ./gradlew check and ./gradlew connectedCheck to test my changes locally.
[x] I have built and run the demo app(s) to verify my change fixes the issue and/or does not break the demo app(s).

Nice, these are definitely more concise and clear! 💯

@juanchazo thanks!
@jingtang10
Can you please also review


reqparse raises on any non-JSON request with Werkzeug 2.1.0

Werkzeug 2.1.0 makes Request.get_json() raise if request is not JSON, which causes reqparse to raise when it attempts to access Request.json, which it does by default for all arguments without a specified location.

Confirmed. Additionally, setting location='args' did not prevent the exception from being raised.

Setting location='args' worked for me (I subclassed RequestParser to make the constructor use a custom Argument, which passes location='args' to super().__init__() when request.is_json is false).

@emosenkis That's a clever way to do that! However, after spending some hours investigating this I'm still unable to get the location='args' trick to work. And I'm just parsing a single string query arg (overkill to use the deprecated reqparse for this, I know).
As an aside, props to Github tox workflows that caught this for me (although I spent an hour assuming that I had broken something when I checked in some project documentation changes) ;-)

I ended up moving to marshmallow for my query param parsing. It was very straight-forward. I'm still using Flask-RESTful for its Resource functionality.

It seems like Flask-Restful isn't actively maintained anymore: https://github.com/flask-restful/flask-restful/issues/883 lists alternatives, including Marshmallow in place of reqparse.
Flask-Restx seems to be based on the similar code, and has this PR open: https://github.com/python-restx/flask-restx/pull/423. The same could be applied here.
Given that this isn't actively maintained, it's likely that other things will continue to diverge in incompatible ways. So if you're still using Flask-Restful, it's a very good idea to pin your dependency tree to avoid updates. Or migrate to the suggested alternatives (and still pin to control updates).

I've submitted a potential fix for this issue. FWIW, I also reported the issue at werkzeug (werkzeug#2339), as there may be other broken things, and it took me a bit to narrow down where the problem was.

Setting location='args' worked for me (I subclassed RequestParser to make the constructor use a custom Argument, which passes location='args' to super().__init__() when request.is_json is false).

It seems that letting location="values" also works.


tiles justified change position

Hi, I'm using your wonderful widget but I'm just having an issue when I enlarge the webpage. Instead of resizing and keeping horizontal the individual tiles line up vertically and move out and away from the div in which they are contained. Any suggestion on how I can correct this?

HI, please show me it in our website, tell me what I should do in order to
see the issue, and i'll help you.
On Tue, Jan 26, 2016 at 4:56 AM, mdizza125<EMAIL_ADDRESS>wrote:

Hi, I'm using your wonderful widget but I'm just having an issue when I
enlarge the webpage Instead of resizing and keeping horizontal the
individual tiles line up vertically and move out and away from the div in
which they are contained Any suggestion on how I can correct this?
—
Reply to this email directly or view it on GitHub
https://github.com/vvvmax/unitegallery/issues/54.


Composer 2.2+ requires allow-plugins config to be set

See https://getcomposer.org/doc/06-config.md#allow-plugins

Thank you @T2L!


[RFC] Quality fixes

Some small fixes to the code before we ship it off to SIG.
After #22.

Looks good.


Any Updates for Create Custom Help doc to reflect Azure changes in last 6 months?

The document "Create Custom Help for Microsoft Dynamics 365 for Finance and Operations" has been most helpful, but many of the Azure options/screens/selections have changed since the doc was written.
Is and update likely in the not too distant future?
Cheers

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

ID: 55d63462-2df6-7954-d80c-e9211718f3a8
Version Independent ID: f345be27-924a-d0c1-b0f4-3c2d78849ede
Content: Connect a custom help site to Dynamics 365 for Finance and Operations - Finance & Operations | Dynamics 365 | #MSDyn365FO
Content Source: articles/fin-and-ops/get-started/help-custom.md
Service: dynamics-ax-platform
GitHub Login: @MargoC
Microsoft Alias: margoc

@pbonny1, thank you for posting this!
@jasongre, can you please review and update the topic as needed?

Bug 316729 has been logged to track this issue.


openroad -gui doesn't work

After cmake .. and make I run openroad -gui. But nothing opened. Only the phrase below appeared and was not implemented.
~/OpenROAD$ openroad -gui
openroad: command not found

This has nothing to do with the gui - it can't find the executable at all.  I suspect you don't have it in your path.

By default cmake doesn't install the binary, it just builds it. I suspect that if you run the following command it will work ./build/src/openroad -gui


features search request has misnamed field

The field named ontologyTerms in the SearchFeaturesRequest object would be more descriptively named as featureTypes.

Fixed in #581


[Video conference] Confusing naming overlay vs. banner vs. ?

It's a bit confusing how we call things. Sometimes, we call the mute/unmute UI control 'overlay', but we use the same naming the image that can be set when the camera is turned off.
What should be the correct naming?
1) Overlay: the banner that provides the mute/unmute buttons?
2) Default camera image: the image that shows when the camera is muted?
cc @enricogior @crutkas

I suggest using "bar" instead of "overlay". I believe overlay would be more something like in Snip & Sketch app, covering the whole screen.

Suggestions:

Status bar for the banner that provides the mute/unmute buttons. - Here you see and can change the microphone and camera status.

Camera overlay (image) for the image that is shown when the camera os muted.

Why did we close this?

The latest version wasn't using 'overlay'but 'toolbar'. Which makes sense and is not conflicting with the image overlay.
Happy to reopen it if you have other recommendations on what would be the right terminology?

Toolbar.

An overlay IMO is a entire screen object.


View initialization, and viewoptions

Hi there,
I would know if there is any particular reason behind the fact that in the ampersand-view constructor, the view option attributes are updated only after the  initialize method is called?
this.on('change:el', this._handleElementChange, this);

// ...

this.initialize.apply(this, arguments);
this.set(_.pick(attrs, viewOptions));

I think having the options set before the view is initialized is the preferred behaviour; otherwise the same code is run twice, without a real need.
In my particular case, I am extending ampersand-view, with a module that retrieve a template from server (or local storage when available)... I will release it open source when I will reach an adeguate test coverage.
During the initialization i've to change the template (root element, ...)
when this.set(_.pick(attrs, viewOptions)); is called attrs.el still references the old container, the one that was replaced with the server response... and this causes the fact that the event listeners are delegated to the wrong element.
I would suggest to change the order of:
this.set(_.pick(attrs, viewOptions));
this.initialize.apply(this, arguments);

Do you see any problem? I would be happy to submit a pull request for this.
Thanks for your time :)

I forked the repo, and made the "fix"...
it passes all the tests...
I hope this can be merged soon...
if you need more info, i am available for further clarification.

@wraithgar Backbone does this as well. This call the initialize function last.
https://github.com/jashkenas/backbone/blob/master/backbone.js#L1171
Although I suggest this PR should be merged, it is a breaking change.
There should also be a test that validates the order.

Should no longer be needed once viewOptions are removed.

@brunoscopelliti Thanks for the fix, but once we merge #125 this will be fixed as well..

@pgilad you're welcome. thank you.


Phantom Crash

Operating system: Linux
0.0.0 Linux 2.6.26-2-amd64 #1 SMP Tue Jan 25 05:59:43 UTC 2011 x86_64
CPU: amd64
family 6 model 26 stepping 5
4 CPUs
Crash reason:  SIGSEGV
Crash address: 0x110
Thread 0 (crashed)
0  phantomjs + 0x696aba
rbx = 0x0000000000000000   r12 = 0x0000000000000100
r13 = 0x00007f623fd78718   r14 = 0x0000000000000001
r15 = 0x0000000000000000   rip = 0x0000000000a96aba
rsp = 0x00007fffe618dee0   rbp = 0x00007fffe618df10
Found by: given as instruction pointer in context
1  phantomjs + 0x69ab3c
rip = 0x0000000000a9ab3d   rsp = 0x00007fffe618df10
rbp = 0x00007fffe618df10
Found by: stack scanning
2  phantomjs + 0x4edb74
rip = 0x00000000008edb75   rsp = 0x00007fffe618df50
Found by: stack scanning
3  phantomjs + 0x4f36b2
rip = 0x00000000008f36b3   rsp = 0x00007fffe618dfb0
Found by: stack scanning
4  phantomjs + 0xd6e8d3
rip = 0x000000000116e8d4   rsp = 0x00007fffe618e0a0
Found by: stack scanning
5  phantomjs + 0x61cbd9
rip = 0x0000000000a1cbda   rsp = 0x00007fffe618e110
Found by: stack scanning
6  phantomjs + 0x61ea69
rip = 0x0000000000a1ea6a   rsp = 0x00007fffe618e1d0
Found by: stack scanning
7  phantomjs + 0x5efe2b
rip = 0x00000000009efe2c   rsp = 0x00007fffe618e1f0
Found by: stack scanning
8  phantomjs + 0x5d303f
rip = 0x00000000009d3040   rsp = 0x00007fffe618e270
Found by: stack scanning
9  phantomjs + 0x5d90a0
rip = 0x00000000009d90a1   rsp = 0x00007fffe618e340
Found by: stack scanning
10  phantomjs + 0x5d536e
rip = 0x00000000009d536f   rsp = 0x00007fffe618e350
Found by: stack scanning
11  phantomjs + 0x5db151
rip = 0x00000000009db152   rsp = 0x00007fffe618e3a0
Found by: stack scanning
Thread 1
0  libc-2.11.3.so + 0xa0c5d
rbx = 0x00007f6287fccd80   r12 = 0x00000000ffffffff
r13 = 0x00007f6239c101a0   r14 = 0x0000000002a7e740
r15 = 0x0000000002a7e710   rip = 0x00007f6288e95c5d
rsp = 0x00007f6287fccc50   rbp = 0x00007f6287fccd00
Found by: given as instruction pointer in context
1  libc-2.11.3.so + 0xa0acf
rip = 0x00007f6288e95ad0   rsp = 0x00007f6287fccc60
rbp = 0x00007f6287fccd00
Found by: stack scanning
2  phantomjs + 0x18b5c6f
rip = 0x0000000001cb5c70   rsp = 0x00007f6287fccc68
rbp = 0x00007f6287fccd00
Found by: stack scanning
3  ld-2.11.3.so + 0x9009
rip = 0x00007f628a3f100a   rsp = 0x00007f6287fccca0
rbp = 0x00007f6287fccd00
Found by: stack scanning
4  ld-2.11.3.so + 0x982b
rip = 0x00007f628a3f182c   rsp = 0x00007f6287fccce0
rbp = 0x00007f6287fccd00
Found by: stack scanning
5  libpthread-2.11.3.so + 0xefef
rip = 0x00007f6289911ff0   rsp = 0x00007f6287fcccf8
rbp = 0x00007f6287fccd00
Found by: stack scanning
6  ld-2.11.3.so + 0x9af1
rip = 0x00007f628a3f1af2   rsp = 0x00007f6287fccd00
rbp = 0x00007f6287fccd00
Found by: stack scanning
7  libc-2.11.3.so + 0xe217
rip = 0x00007f6288e03218   rsp = 0x00007f6287fccd48
Found by: stack scanning
8  libpthread-2.11.3.so + 0xb295
rip = 0x00007f628990e296   rsp = 0x00007f6287fcce18
Found by: stack scanning
9  phantomjs + 0xdda2d
rip = 0x00000000004dda2e   rsp = 0x00007f6287fcce40
Found by: stack scanning
10  libpthread-2.11.3.so + 0x10fbf
rip = 0x00007f6289913fc0   rsp = 0x00007f6287fcce70
Found by: stack scanning
11  libpthread-2.11.3.so + 0x10fbf
rip = 0x00007f6289913fc0   rsp = 0x00007f6287fccea0
Found by: stack scanning
12  phantomjs + 0xddc98
rip = 0x00000000004ddc99   rsp = 0x00007f6287fccec0
Found by: stack scanning
13  libpthread-2.11.3.so + 0x68c9
rip = 0x00007f62899098ca   rsp = 0x00007f6287fcced0
Found by: stack scanning
14  libpthread-2.11.3.so + 0x10fbf
rip = 0x00007f6289913fc0   rsp = 0x00007f6287fccf78
Found by: stack scanning
15  libc-2.11.3.so + 0xcfb6c
rip = 0x00007f6288ec4b6d   rsp = 0x00007f6287fccfe0
Found by: stack scanning
Thread 2
0  libc-2.11.3.so + 0xc93e3
rbx = 0x0000000000000000   r12 = 0x00007f62877cbda0
r13 = 0x0000000000000008   r14 = 0x0000000003d80e28
r15 = 0x0000000003d810c0   rip = 0x00007f6288ebe3e3
rsp = 0x00007f62877cbb70   rbp = 0x0000000003d80c70
Found by: given as instruction pointer in context
1  phantomjs + 0x1906326
rip = 0x0000000001d06327   rsp = 0x00007f62877cbb80
Found by: stack scanning
2  ld-2.11.3.so + 0x9009
rip = 0x00007f628a3f100a   rsp = 0x00007f62877cbba0
Found by: stack scanning
3  libpthread-2.11.3.so + 0xe158
rip = 0x00007f6289911159   rsp = 0x00007f62877cbbd0
Found by: stack scanning
4  phantomjs + 0x19075e6
rip = 0x0000000001d075e7   rsp = 0x00007f62877cbc10
Found by: stack scanning
5  phantomjs + 0x18f6ab6
rip = 0x0000000001cf6ab7   rsp = 0x00007f62877cbc30
Found by: stack scanning
6  linux-gate.so + 0x531
rip = 0x00007fffe61ff532   rsp = 0x00007f62877cbc40
Found by: stack scanning
7  librt-2.11.3.so + 0x3e7e
rip = 0x00007f6289b22e7f   rsp = 0x00007f62877cbc70
Found by: stack scanning
8  phantomjs + 0x1840b73
rip = 0x0000000001c40b74   rsp = 0x00007f62877cbc90
Found by: stack scanning
9  phantomjs + 0x1840a78
rip = 0x0000000001c40a79   rsp = 0x00007f62877cbcd0
Found by: stack scanning
10  phantomjs + 0x1906fa5
rip = 0x0000000001d06fa6   rsp = 0x00007f62877cbce0
Found by: stack scanning
11  phantomjs + 0x1908091
rip = 0x0000000001d08092   rsp = 0x00007f62877cbd50
Found by: stack scanning
12  phantomjs + 0x18dd4b4
rip = 0x0000000001cdd4b5   rsp = 0x00007f62877cbda0
Found by: stack scanning
13  phantomjs + 0x18ddca8
rip = 0x0000000001cddca9   rsp = 0x00007f62877cbdb0
Found by: stack scanning
14  phantomjs + 0x18dd917
rip = 0x0000000001cdd918   rsp = 0x00007f62877cbdd0
Found by: stack scanning
15  phantomjs + 0x17dfdf5
rip = 0x0000000001bdfdf6   rsp = 0x00007f62877cbe30
Found by: stack scanning
16  phantomjs + 0x17e2cc1
rip = 0x0000000001be2cc2   rsp = 0x00007f62877cbe80
Found by: stack scanning
17  libpthread-2.11.3.so + 0x68c9
rip = 0x00007f62899098ca   rsp = 0x00007f62877cbed0
Found by: stack scanning
Thread 3
0  libc-2.11.3.so + 0xc93e3
rbx = 0x0000000000000005   r12 = 0x00007f62306c2dc0
r13 = 0x0000000002aa3080   r14 = 0x00007f628a606040
r15 = 0x0000000000000003   rip = 0x00007f6288ebe3e3
rsp = 0x00007f62306c2db0   rbp = 0x00007f62306c2e4f
Found by: given as instruction pointer in context
1  phantomjs + 0x18b7133
rip = 0x0000000001cb7134   rsp = 0x00007f62306c2dc0
rbp = 0x00007f62306c2e4f
Found by: stack scanning
2  phantomjs + 0x17e2cc1
rip = 0x0000000001be2cc2   rsp = 0x00007f62306c2e80
Found by: stack scanning
3  libpthread-2.11.3.so + 0x68c9
rip = 0x00007f62899098ca   rsp = 0x00007f62306c2ed0
Found by: stack scanning
Thread 4
0  libpthread-2.11.3.so + 0xb1fc
rbx = 0x0000000007a32e40   r12 = 0x004189374bc6a7ef
r13 = 0xffffffffffffffff   r14 = 0x0000000007a32e68
r15 = 0x0000000007a32e00   rip = 0x00007f628990e1fc
rsp = 0x00007f6232890d38   rbp = 0x00007f623e3ffc50
Found by: given as instruction pointer in context
1  phantomjs + 0x17e39f4
rip = 0x0000000001be39f5   rsp = 0x00007f6232890d60
rbp = 0x00007f623e3ffc50
Found by: stack scanning
2  linux-gate.so + 0x6a4
rip = 0x00007fffe61ff6a5   rsp = 0x00007f6232890d90
rbp = 0x00007f623e3ffc50
Found by: stack scanning
3  phantomjs + 0xe70e9
rip = 0x00000000004e70ea   rsp = 0x00007f6232890de0
rbp = 0x00007f623e3ffc50
Found by: stack scanning
4  phantomjs + 0xd85268
rip = 0x0000000001185269   rsp = 0x00007f6232890e00
rbp = 0x00007f623e3ffc50
Found by: stack scanning
5  phantomjs + 0xd85492
rip = 0x0000000001185493   rsp = 0x00007f6232890e40
rbp = 0x00007f623e3ffc50
Found by: stack scanning
6  phantomjs + 0xe68fa
rip = 0x00000000004e68fb   rsp = 0x00007f6232890e70
rbp = 0x00007f623e3ffc50
Found by: stack scanning
7  phantomjs + 0x17e2cc1
rip = 0x0000000001be2cc2   rsp = 0x00007f6232890e80
rbp = 0x00007f623e3ffc50
Found by: stack scanning
8  phantomjs + 0x3fafff
rip = 0x00000000007fb000   rsp = 0x00007f6232890ea0
rbp = 0x00007f623e3ffc50
Found by: stack scanning
9  libpthread-2.11.3.so + 0x68c9
rip = 0x00007f62899098ca   rsp = 0x00007f6232890ed0
rbp = 0x00007f623e3ffc50
Found by: stack scanning
Thread 5
0  libpthread-2.11.3.so + 0xb7d2
rbx = 0x0000000007c751b0   r12 = 0x00000000000010b2
r13 = 0x00007f6225f69de0   r14 = 0xffffffffffffff92
r15 = 0x0000000000000000   rip = 0x00007f628990e7d2
rsp = 0x00007f6225f69d68   rbp = 0x00000000078e67a0
Found by: given as instruction pointer in context
1  phantomjs + 0x17e39d6
rip = 0x0000000001be39d7   rsp = 0x00007f6225f69dc0
Found by: stack scanning
2  phantomjs + 0x17d783c
rip = 0x0000000001bd783d   rsp = 0x00007f6225f69e40
Found by: stack scanning
3  phantomjs + 0x17e2cc1
rip = 0x0000000001be2cc2   rsp = 0x00007f6225f69e80
Found by: stack scanning
4  libc-2.11.3.so + 0x35885f
rip = 0x00007f628914d860   rsp = 0x00007f6225f69ea0
Found by: stack scanning
5  libc-2.11.3.so + 0x358867
rip = 0x00007f628914d868   rsp = 0x00007f6225f69ea8
Found by: stack scanning
6  libpthread-2.11.3.so + 0x68c9
rip = 0x00007f62899098ca   rsp = 0x00007f6225f69ed0
Found by: stack scanning
Thread 6
0  libc-2.11.3.so + 0xc4c13
rbx = 0x0000000029bf2a10   r12 = 0x0000000000000002
r13 = 0x0000000000000000   r14 = 0x00007f623102caa8
r15 = 0x0000000000000005   rip = 0x00007f6288eb9c13
rsp = 0x00007f623102c850   rbp = 0x00007f623102fdb8
Found by: given as instruction pointer in context
1  libresolv-2.11.3.so + 0x98dd
rip = 0x00007f62316718de   rsp = 0x00007f623102c880
rbp = 0x00007f623102fdb8
Found by: stack scanning
Thread 7
0  libpthread-2.11.3.so + 0xb7d2
rbx = 0x0000000007c751b0   r12 = 0x00000000000010b4
r13 = 0x00007f622e1fcde0   r14 = 0xffffffffffffff92
r15 = 0x0000000000000000   rip = 0x00007f628990e7d2
rsp = 0x00007f622e1fcd68   rbp = 0x0000000007c75450
Found by: given as instruction pointer in context
1  phantomjs + 0x17e39d6
rip = 0x0000000001be39d7   rsp = 0x00007f622e1fcdc0
Found by: stack scanning
2  phantomjs + 0x17d783c
rip = 0x0000000001bd783d   rsp = 0x00007f622e1fce40
Found by: stack scanning
3  phantomjs + 0x17e2cc1
rip = 0x0000000001be2cc2   rsp = 0x00007f622e1fce80
Found by: stack scanning
4  libc-2.11.3.so + 0x35885f
rip = 0x00007f628914d860   rsp = 0x00007f622e1fcea0
Found by: stack scanning
5  libc-2.11.3.so + 0x358867
rip = 0x00007f628914d868   rsp = 0x00007f622e1fcea8
Found by: stack scanning
6  libpthread-2.11.3.so + 0x68c9
rip = 0x00007f62899098ca   rsp = 0x00007f622e1fced0
Found by: stack scanning
Thread 8
0  libpthread-2.11.3.so + 0xb7d2
rbx = 0x0000000007c751b0   r12 = 0x00000000000010b0
r13 = 0x00007f622ebafde0   r14 = 0xffffffffffffff92
r15 = 0x0000000000000000   rip = 0x00007f628990e7d2
rsp = 0x00007f622ebafd68   rbp = 0x00007f628000aac0
Found by: given as instruction pointer in context
1  phantomjs + 0x17e39d6
rip = 0x0000000001be39d7   rsp = 0x00007f622ebafdc0
rbp = 0x00007f628000aac0
Found by: stack scanning
2  phantomjs + 0x17d783c
rip = 0x0000000001bd783d   rsp = 0x00007f622ebafe40
rbp = 0x00007f628000aac0
Found by: stack scanning
3  phantomjs + 0x17e2cc1
rip = 0x0000000001be2cc2   rsp = 0x00007f622ebafe80
rbp = 0x00007f628000aac0
Found by: stack scanning
4  libc-2.11.3.so + 0x35885f
rip = 0x00007f628914d860   rsp = 0x00007f622ebafea0
rbp = 0x00007f628000aac0
Found by: stack scanning
5  libc-2.11.3.so + 0x358867
rip = 0x00007f628914d868   rsp = 0x00007f622ebafea8
rbp = 0x00007f628000aac0
Found by: stack scanning
6  libpthread-2.11.3.so + 0x68c9
rip = 0x00007f62899098ca   rsp = 0x00007f622ebafed0
rbp = 0x00007f628000aac0
Found by: stack scanning
Thread 9
0  libc-2.11.3.so + 0xc93e3
rbx = 0x00007f6225768d50   r12 = 0x0000000000196560
r13 = 0x000000000000005f   r14 = 0x000000000fcf8b28
r15 = 0x000000000fcf8dc0   rip = 0x00007f6288ebe3e3
rsp = 0x00007f6225768b70   rbp = 0x00000000000eae77
Found by: given as instruction pointer in context
1  phantomjs + 0x1906227
rip = 0x0000000001d06228   rsp = 0x00007f6225768b80
Found by: stack scanning
2  phantomjs + 0x19075e6
rip = 0x0000000001d075e7   rsp = 0x00007f6225768c10
Found by: stack scanning
3  phantomjs + 0x18f6ab6
rip = 0x0000000001cf6ab7   rsp = 0x00007f6225768c30
Found by: stack scanning
4  linux-gate.so + 0x531
rip = 0x00007fffe61ff532   rsp = 0x00007f6225768c40
Found by: stack scanning
5  librt-2.11.3.so + 0x3e7e
rip = 0x00007f6289b22e7f   rsp = 0x00007f6225768c70
Found by: stack scanning
6  phantomjs + 0x1840b73
rip = 0x0000000001c40b74   rsp = 0x00007f6225768c90
Found by: stack scanning
7  phantomjs + 0x1907ced
rip = 0x0000000001d07cee   rsp = 0x00007f6225768cc0
Found by: stack scanning
8  phantomjs + 0x1840a78
rip = 0x0000000001c40a79   rsp = 0x00007f6225768cd0
Found by: stack scanning
9  phantomjs + 0x1906fa5
rip = 0x0000000001d06fa6   rsp = 0x00007f6225768ce0
Found by: stack scanning
10  phantomjs + 0x1908091
rip = 0x0000000001d08092   rsp = 0x00007f6225768d50
Found by: stack scanning
11  phantomjs + 0x18dd4b4
rip = 0x0000000001cdd4b5   rsp = 0x00007f6225768da0
Found by: stack scanning
12  phantomjs + 0x18ddca8
rip = 0x0000000001cddca9   rsp = 0x00007f6225768db0
Found by: stack scanning
13  phantomjs + 0x18dd917
rip = 0x0000000001cdd918   rsp = 0x00007f6225768dd0
Found by: stack scanning
14  phantomjs + 0x17dfdf5
rip = 0x0000000001bdfdf6   rsp = 0x00007f6225768e30
Found by: stack scanning
15  phantomjs + 0x17e2cc1
rip = 0x0000000001be2cc2   rsp = 0x00007f6225768e80
Found by: stack scanning
16  libpthread-2.11.3.so + 0x5ee8
rip = 0x00007f6289908ee9   rsp = 0x00007f6225768e90
Found by: stack scanning
17  libc-2.11.3.so + 0x35884f
rip = 0x00007f628914d850   rsp = 0x00007f6225768e98
Found by: stack scanning
18  libc-2.11.3.so + 0x35885f
rip = 0x00007f628914d860   rsp = 0x00007f6225768ea0
Found by: stack scanning
19  libc-2.11.3.so + 0x358867
rip = 0x00007f628914d868   rsp = 0x00007f6225768ea8
Found by: stack scanning
20  libpthread-2.11.3.so + 0x68c9
rip = 0x00007f62899098ca   rsp = 0x00007f6225768ed0
Found by: stack scanning
Thread 10
0  libc-2.11.3.so + 0xc93e3
rbx = 0x0000000000000000   r12 = 0x00007f6224f67da0
r13 = 0x000000000000004b   r14 = 0x000000000f7a68b8
r15 = 0x000000000f7a6b50   rip = 0x00007f6288ebe3e3
rsp = 0x00007f6224f67b70   rbp = 0x000000000f7a6700
Found by: given as instruction pointer in context
1  phantomjs + 0x1906326
rip = 0x0000000001d06327   rsp = 0x00007f6224f67b80
Found by: stack scanning
2  libpthread-2.11.3.so + 0xe158
rip = 0x00007f6289911159   rsp = 0x00007f6224f67bd0
Found by: stack scanning
3  phantomjs + 0x19075e6
rip = 0x0000000001d075e7   rsp = 0x00007f6224f67c10
Found by: stack scanning
4  phantomjs + 0x18f6ab6
rip = 0x0000000001cf6ab7   rsp = 0x00007f6224f67c30
Found by: stack scanning
5  linux-gate.so + 0x531
rip = 0x00007fffe61ff532   rsp = 0x00007f6224f67c40
Found by: stack scanning
6  librt-2.11.3.so + 0x3e7e
rip = 0x00007f6289b22e7f   rsp = 0x00007f6224f67c70
Found by: stack scanning
7  phantomjs + 0x1840b73
rip = 0x0000000001c40b74   rsp = 0x00007f6224f67c90
Found by: stack scanning
8  phantomjs + 0x1840a78
rip = 0x0000000001c40a79   rsp = 0x00007f6224f67cd0
Found by: stack scanning
9  phantomjs + 0x1906fa5
rip = 0x0000000001d06fa6   rsp = 0x00007f6224f67ce0
Found by: stack scanning
10  phantomjs + 0x1908091
rip = 0x0000000001d08092   rsp = 0x00007f6224f67d50
Found by: stack scanning
11  phantomjs + 0x18dd4b4
rip = 0x0000000001cdd4b5   rsp = 0x00007f6224f67da0
Found by: stack scanning
12  phantomjs + 0x18ddca8
rip = 0x0000000001cddca9   rsp = 0x00007f6224f67db0
Found by: stack scanning
13  phantomjs + 0x18dd917
rip = 0x0000000001cdd918   rsp = 0x00007f6224f67dd0
Found by: stack scanning
14  phantomjs + 0x17dfdf5
rip = 0x0000000001bdfdf6   rsp = 0x00007f6224f67e30
Found by: stack scanning
15  phantomjs + 0x17e2cc1
rip = 0x0000000001be2cc2   rsp = 0x00007f6224f67e80
Found by: stack scanning
16  libpthread-2.11.3.so + 0x5ee8
rip = 0x00007f6289908ee9   rsp = 0x00007f6224f67e90
Found by: stack scanning
17  libc-2.11.3.so + 0x35884f
rip = 0x00007f628914d850   rsp = 0x00007f6224f67e98
Found by: stack scanning
18  libc-2.11.3.so + 0x35885f
rip = 0x00007f628914d860   rsp = 0x00007f6224f67ea0
Found by: stack scanning
19  libc-2.11.3.so + 0x358867
rip = 0x00007f628914d868   rsp = 0x00007f6224f67ea8
Found by: stack scanning
20  libpthread-2.11.3.so + 0x68c9
rip = 0x00007f62899098ca   rsp = 0x00007f6224f67ed0
Found by: stack scanning
Loaded modules:
0x00400000 - 0x0268dfff  phantomjs  ???  (main)
0x7f62279ae000 - 0x7f62279c9fff  p052024l.pfb  ???
0x7f62279ca000 - 0x7f62279dffff  n021024l.pfb  ???
0x7f62279e0000 - 0x7f62279f7fff  c059036l.pfb  ???
0x7f62279f8000 - 0x7f6227a09fff  b018035l.pfb  ???
0x7f6227a0a000 - 0x7f6227a30fff  FreeSansBoldOblique.ttf  ???
0x7f622c359000 - 0x7f622c3a9fff  DejaVuSans-ExtraLight.ttf  ???
0x7f622cac1000 - 0x7f622cadbfff  p052023l.pfb  ???
0x7f622cbff000 - 0x7f622cc16fff  c059033l.pfb  ???
0x7f622cc21000 - 0x7f622cc44fff  LiberationSerif-Italic.ttf  ???
0x7f622cc45000 - 0x7f622cc8efff  FreeSansOblique.ttf  ???
0x7f622cce2000 - 0x7f622ccf6fff  b018032l.pfb  ???
0x7f622ce75000 - 0x7f622cef5fff  DejaVuSans-BoldOblique.ttf  ???
0x7f622cf4b000 - 0x7f622cf65fff  c059016l.pfb  ???
0x7f622cf95000 - 0x7f622cfa7fff  b018015l.pfb  ???
0x7f622cfa8000 - 0x7f622cff1fff  DejaVuSansMono-Bold.ttf  ???
0x7f622cff2000 - 0x7f622d072fff  DejaVuSans-Oblique.ttf  ???
0x7f622d073000 - 0x7f622d084fff  n019004l.pfb  ???
0x7f622d085000 - 0x7f622d09bfff  z003034l.pfb  ???
0x7f622d09c000 - 0x7f622d0c0fff  LiberationSerif-Regular.ttf  ???
0x7f622d0c1000 - 0x7f622d1fbfff  FreeSerif.ttf  ???
0x7f622e21c000 - 0x7f622e236fff  LiberationMono-Regular.ttf  ???
0x7f622e237000 - 0x7f622e27ffff  DejaVuSerifCondensed.ttf  ???
0x7f622e280000 - 0x7f622e2cefff  DejaVuSansMono.ttf  ???
0x7f622e2cf000 - 0x7f622e31bfff  FreeMono.ttf  ???
0x7f622e31c000 - 0x7f622e336fff  p052003l.pfb  ???
0x7f622e337000 - 0x7f622e34efff  n022003l.pfb  ???
0x7f622e34f000 - 0x7f622e367fff  n021003l.pfb  ???
0x7f622e368000 - 0x7f622e381fff  c059013l.pfb  ???
0x7f622e382000 - 0x7f622e39afff  b018012l.pfb  ???
0x7f622ebb1000 - 0x7f622edb2fff  libnss_mdns4.so.2  ???
0x7f622f165000 - 0x7f622f17bfff  n021023l.pfb  ???
0x7f622f241000 - 0x7f622f251fff  n019023l.pfb  ???
0x7f622f58d000 - 0x7f622f5b7fff  FreeSansBold.ttf  ???
0x7f622f630000 - 0x7f622f6a0fff  FreeSans.ttf  ???
0x7f622f6a1000 - 0x7f622f6c1fff  LiberationSans-BoldItalic.ttf  ???
0x7f622fc63000 - 0x7f622fc73fff  n019024l.pfb  ???
0x7f622fc7f000 - 0x7f622fca3fff  LiberationSerif-BoldItalic.ttf  ???
0x7f62306c4000 - 0x7f62306ebfff  LiberationSans-Italic.ttf  ???
0x7f62306ec000 - 0x7f623070dfff  LiberationSans-Bold.ttf  ???
0x7f623070e000 - 0x7f6230793fff  DejaVuSansCondensed-Bold.ttf  ???
0x7f6230794000 - 0x7f623082efff  DejaVuSans.ttf  ???
0x7f6231030000 - 0x7f6231052fff  LiberationSans-Regular.ttf  ???
0x7f6231053000 - 0x7f6231258fff  libnss_dns-2.11.3.so  ???
0x7f6231259000 - 0x7f623145afff  libnss_mdns4_minimal.so.2  ???
0x7f623145b000 - 0x7f6231667fff  libnss_files-2.11.3.so  ???
0x7f6231668000 - 0x7f623187bfff  libresolv-2.11.3.so  ???
0x7f6231b68000 - 0x7f6231b77fff  a010013l.pfb  ???
0x7f6231e03000 - 0x7f6231e26fff  LiberationSerif-Bold.ttf  ???
0x7f6231e27000 - 0x7f6231e40fff  LiberationMono-Bold.ttf  ???
0x7f6231e41000 - 0x7f6231e8cfff  DejaVuSerif-Bold.ttf  ???
0x7f6231e8d000 - 0x7f6231ecefff  FreeSerifBold.ttf  ???
0x7f6231ecf000 - 0x7f6231ef7fff  FreeMonoBold.ttf  ???
0x7f6231ef8000 - 0x7f6231f12fff  p052004l.pfb  ???
0x7f6231f13000 - 0x7f6231f2bfff  n022004l.pfb  ???
0x7f6231f2c000 - 0x7f6231f44fff  n021004l.pfb  ???
0x7f62328ed000 - 0x7f62328fcfff  a010015l.pfb  ???
0x7f6284062000 - 0x7f628406afff  s050000l.pfb  ???
0x7f6284074000 - 0x7f628407ffff  d050000l.pfb  ???
0x7f6285f5a000 - 0x7f6285f6dfff  n019003l.pfb  ???
0x7f6287fce000 - 0x7f62881d0fff  ISO8859-15.so  ???
0x7f62881d1000 - 0x7f6288427fff  libssl.so.0.9.8  ???
0x7f6288428000 - 0x7f62887c4fff  libcrypto.so.0.9.8  ???
0x7f62887c9000 - 0x7f62889b5fff  locale-archive  ???
0x7f62889b6000 - 0x7f6288bddfff  libexpat.so.1.5.2  ???
0x7f6288bde000 - 0x7f6288df4fff  libz.so.<IP_ADDRESS>  ???
0x7f6288df5000 - 0x7f6289151fff  libc-2.11.3.so  ???
0x7f6289157000 - 0x7f628936cfff  libgcc_s.so.1  ???
0x7f628936d000 - 0x7f62895eefff  libm-2.11.3.so  ???
0x7f62895ef000 - 0x7f62898edfff  libstdc++.so.6.0.13  ???
0x7f6289903000 - 0x7f6289b1afff  libpthread-2.11.3.so  ???
0x7f6289b1f000 - 0x7f6289d26fff  librt-2.11.3.so  ???
0x7f6289d27000 - 0x7f6289f2afff  libdl-2.11.3.so  ???
0x7f6289f2b000 - 0x7f628a15ffff  libfontconfig.so.1.4.4  ???
0x7f628a160000 - 0x7f628a3e7fff  libfreetype.so.6.6.0  ???
0x7f628a3e8000 - 0x7f628a405fff  ld-2.11.3.so  ???
0x7f628a5a7000 - 0x7f628a5adfff  gconv-modules.cache  ???
0x7f628a5ae000 - 0x7f628a5cdfff  libc.mo  ???
0x7f628a5ce000 - 0x7f628a5d6fff  945677eb7aeaf62f1d50efc3fb3ec7d8-le64.cache-3  ???
0x7f628a5d7000 - 0x7f628a5dffff  6d41288fd70b0be22e8c3a91e032eec0-le64.cache-3  ???
0x7f628a5e0000 - 0x7f628a5e9fff  d52a8644073d54c13679302ca1180695-le64.cache-3  ???
0x7f628a5f6000 - 0x7f628a5f9fff  6eb3985aa4124903f6ff08ba781cd364-le64.cache-3  ???
0x7f628a5fa000 - 0x7f628a602fff  e13b20fdb08344e0e664864cc2ede53d-le64.cache-3  ???
0x7fffe61ff000 - 0x7fffe61fffff  linux-gate.so  ???

Please upgrade to PhantomJS 2. 1.9.x is no longer supported, and known to have many crasher bugs that are fixed in 2 version.


Reference xunit 2.2.0 in the specification package

Waiting on @Eilon to approve this. I'll get a BuildTools change out to remove the NPV exception.


Logs tab crashes on Minikube cluster with error: "Log task finished unexpectedly"

I've installed kty on my minikube cluster, and ssh'ed into it. However when navigating to the "Logs" tab of a pod, I get an error in the UI which says "Log task finished unexpectedly".

This also caused my kubectl port forwarding to crash:
❯ kubectl -n kty port-forward service/server 2222:2222
Forwarding from <IP_ADDRESS>:2222 -> 2222
Forwarding from [::1]:2222 -> 2222
Handling connection for 2222
E0925 21:44:08.685517   15807 portforward.go:413] an error occurred forwarding 2222 -> 2222: error forwarding port 2222 to pod fb97c9059137cdd5f273d45f0045c1a49b8afc11f3b13ded4e32a721ade8cd48, uid : exit status 1: 2024/09/25 13:44:08 socat[11307] E write(5, 0x556626382000, 68): Broken pipe
error: lost connection to pod

This error seems to only happen in some pods. For example, I am able to see logs in the kty server pod running just fine.

I've seen this with my local k3d cluster as well. It seems to have something to do with pods restarting. This is a little better in main right now.
For some reason, k8s is returning all the logs but the stream itself ends. stern correctly streams logs still, so I need to go figure out what they're doing differently (and hope that it isn't polling).
Gonna look into this right now.


Stack trace produced when an image can't be downloaded due to networking issues is way too verbose

It feels like a simple message saying "Failed host lookup: 'd3rt1990lpmkn.cloudfront.net' (OS Error: Non-recoverable error, errno = -4)"  "Can't load image"
would be sufficient.   It's just a debug mode message.
Sometimes the problem is that the filename is wrong, and you need the stack to figure out where it's being generated.

This is my gripe with flutter as well. Instead of producing clear error messages it just explodes with stacktraces hundreds of lines of code. Makes debugging experience poor.
Can we perhaps have a flag to just hide or skip over frames that are internal to Flutter? Or maybe just anything related to rendering? The amount of updateChild and inflateChild is useless.  It obscures the real issue.

Unfortunately sometimes the updateChild and inflateChild calls are important...
The framework already removes some frames (e.g. private frames in dart:async). But we do need to do more.


Add Bulgaria

refs #

For information, read and make sure you're okay with the CONTRIBUTING document.

[ ] Tests with a significant number of years to be tested for your calendar.
[ ] Docstrings for the Calendar class and specific methods.
[ ] Calendar country / label added to the README.rst file,
[ ] Changelog amended with a mention like: "Added <country> by @pseudo (#)"

[ ] Tests with a significant number of years to be tested for your calendar.
[ ] Changelog amended with a mention describing your changes.

could you please rebase your branch from upstream, to clean it up ad such?
There are a lot of "howtos" online ; but if you need help to do so, I'd be glad to.

I think I've made a mess of rebasing
(venv) kochanski:workalendar gregn$ git status
On branch bulgaria
Your branch is up-to-date with 'origin/bulgaria'.
nothing to commit, working directory clean
(venv) kochanski:workalendar gregn$ git fetch novafloss
(venv) kochanski:workalendar gregn$ git rebase novafloss/master
First, rewinding head to replay your work on top of it...
Applying: Add Bulgaria
(venv) kochanski:workalendar gregn$

can you paste the output of the following command?
git diff master

It looks like it's just the Bulgaria patch
$ git diff master
diff --git a/CHANGELOG b/CHANGELOG
index 024fc83..10d71ce 100644
--- a/CHANGELOG
+++ b/CHANGELOG
@@ -6,7 +6,8 @@ master (unreleased)

 - Add Ireland. thx @gregn610 (#152).
 - Bugfix: New Year's Eve is not a holiday in Netherlands (#154).
-- Add Austria. thx @gregn610 (#153)
+- Add Austria.  thx @gregn610 (#153)
+- Add Bulgaria. thx @gregn610 (#156)

 0.8.1 (2016-11-08)
diff --git a/README.rst b/README.rst
index 9fbd465..fca1a82 100644
--- a/README.rst
+++ b/README.rst
@@ -76,6 +76,7 @@ Europe

 * Austria
 * Belgium
+* Bulgaria
 * Czech Republic
 * Denmark
 * Estonia
diff --git a/workalendar/europe/__init__.py b/workalendar/europe/__init__.py
index 79b47cc..d27320d 100644
--- a/workalendar/europe/__init__.py
+++ b/workalendar/europe/__init__.py
@@ -1,6 +1,7 @@
 # -*- coding: utf-8 -*-
 from .austria import Austria
 from .belgium import Belgium
+from .bulgaria import Bulgaria
 from .czech_republic import CzechRepublic
 from .estonia import Estonia
 from .european_central_bank import EuropeanCentralBank
@@ -36,6 +37,7 @@ from .germany import (
 __all__ = (
     Austria,
     Belgium,
+    Bulgaria,
     Catalonia,
     CzechRepublic,
     Denmark,
diff --git a/workalendar/europe/bulgaria.py b/workalendar/europe/bulgaria.py
new file mode 100644
index 0000000..bb53a84
--- /dev/null
+++ b/workalendar/europe/bulgaria.py
@@ -0,0 +1,28 @@
+# -*- coding: utf-8 -*-
+from workalendar.core import WesternCalendar, ChristianMixin
+
+
+class Bulgaria(WesternCalendar, ChristianMixin):
+    "Bulgaria"
+
+    FIXED_HOLIDAYS = WesternCalendar.FIXED_HOLIDAYS + (
+        (3, 3, "Liberation Day"),  # Ден на Освобождението на Б
+        (5, 1, "International Workers' Day"),  # Ден на труда и на междунар
+        (5, 6, "Saint George's Day"),  # Гергьовден, ден на храброс
+        (5, 24, "Saints Cyril & Methodius Day"),  # Ден на българската просвет
+        (9, 6, "Unification Day"),  # Ден на Съединението
+        (9, 22, "Independence Day"),  # Ден на независимостта на Б
+        # wikipedia says Non-attendance day for schools, otherwise a working da
+        # (11, 1, "National Awakening Day"),  # Ден на народните будители
+
+    )
+
+    include_easter_sunday = True
+    include_easter_monday = True
+    include_christmas_eve = True  # Бъдни вечер
+    include_christmas = True  # Рождество Христово
+    include_boxing_day = True
+
+    # wikipedia says The Bulgarians have two days of Christmas,
+    # both called Christmas Day
+    boxing_day_label = "Christmas"
diff --git a/workalendar/tests/test_europe.py b/workalendar/tests/test_europe.py
index d6eafc9..9a81de5 100644
--- a/workalendar/tests/test_europe.py
+++ b/workalendar/tests/test_europe.py
@@ -1,6 +1,7 @@
 # coding=utf-8
 from datetime import date
 from workalendar.europe import Austria
+from workalendar.europe import Bulgaria
 from workalendar.tests import GenericCalendarTest
 from workalendar.europe import CzechRepublic
 from workalendar.europe import Denmark
@@ -54,6 +55,27 @@ class AustriaTest(GenericCalendarTest):
         self.assertIn(date(2016, 12, 26), holidays)  # St Stephens

+class BulgariaTest(GenericCalendarTest):
+    cal_class = Bulgaria
+
+    def test_year_2016(self):
+        holidays = self.cal.holidays_set(2016)
+        self.assertIn(date(2016,  1,  1), holidays)   # New Year's Day
+        self.assertIn(date(2016,  3,  3), holidays)   # Liberation Day
+        self.assertIn(date(2016,  3, 27), holidays)   # Easter Sun
+        self.assertIn(date(2016,  3, 28), holidays)   # Easter Mon
+        self.assertIn(date(2016,  5,  1), holidays)   # International Workers'
+        self.assertIn(date(2016,  5,  6), holidays)   # St George's Day
+        self.assertIn(date(2016,  5, 24), holidays)   # St Cyril & Methodius
+        self.assertIn(date(2016,  9,  6), holidays)   # Unification Day
+        self.assertIn(date(2016,  9, 22), holidays)   # Independence Day
+        self.assertIn(date(2016, 12, 24), holidays)   # Christmas Eve
+        self.assertIn(date(2016, 12, 25), holidays)   # Christmas 1
+        self.assertIn(date(2016, 12, 26), holidays)   # Christmas 2
+        # Non-attendance day for schools, otherwise a working day.
+        self.assertNotIn(date(2016, 11,  1), holidays)   # National Awakening
+
+
 class CzechRepublicTest(GenericCalendarTest):
     cal_class = CzechRepublic

right, so it looks pretty messy, I see your "add Bulgaria" at least twice.
We've got two solutions here: either I'm taking your branch(es) over and try to tidy-them up, rebase your contribution properly. Fast, but you won't learn how to make clean PRs.
Or the other solution is to wait for me to have time to write a tiny gist on:

how to maintain an "upstream branch" from novafloss/workalendar and keep it up-to-date,
how to fork from this upstream and make your pull-requests as minimal as possible.

it'll be better, because you could earn the "happy contributor badge", but will take more time ; time I'm not sure I can have until january (daily work + holidays).
What do you think?

Ok thanks, take them over and make it work please.
Sent from my iPhone

On 10 Dec 2016, at 18:59, Bruno Bord<EMAIL_ADDRESS>wrote:
right, so it looks pretty messy, I see your "add Bulgaria" at least twice.
We've got two solutions here: either I'm taking your branch(es) over and try to tidy-them up, rebase your contribution properly. Fast, but you won't learn how to make clean PRs.
Or the other solution is to wait for me to have time to write a tiny gist on:
how to maintain an "upstream branch" from novafloss/workalendar and keep it up-to-date,
how to fork from this upstream and make your pull-requests as minimal as possible.
it'll be better, because you could earn the "happy contributor badge", but will take more time ; time I'm not sure I can have until january (daily work + holidays).
What do you think?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.

as you wanted, I've merged your contribution. thank you very much for your work, much appreciated.
You may want to read the Github help about keeping an upstream fork, that might help a lot for your next pull-requests, on this project or another.
https://help.github.com/articles/syncing-a-fork/
Now, onto the next one :)

BTW, Github has released a UI to handle (simple) conflict resolution from the github.com front-end: https://github.com/blog/2293-resolve-simple-merge-conflicts-on-github


Static code analysis

At the risk of introducing opinions (#214), it'd be nice to introduce automatic code scanning.

tfsec would also be cool. It's somewhat redundant with our use of DivvyCloud, but it can generate SARIF files for use with GitHub Advanced Security.

tfsec would allow us to add comments to our Terraform to ignore warnings (like about how our log buckets don't have logging enabled).


ProduceSync returning "context canceled" error when parent context hasn't been cancelled

Many times throughout the day the following sequence of logs occur:

msg: "random error while producing, requeueing unattempted request", err: "ILLEGAL_SASL_STATE: Request is not valid given the current SASL state."
Msg: "produce request failed triggering metadata update", err: "ILLEGAL_SASL_STATE: Request is not valid given the current SASL state."
Msg: "metadata update triggered" why: "failed produce request triggering metadata update"
A few seconds later we get 10 or so instances of the ProduceSync method returning a "context cancelled" error. The parent context we are passing in isn't getting cancelled.

These ProduceSync errors are impacting our system. Is there an internal context that is being cancelled? Is there a reason these particular errors aren't being retried?

"2024-06-18T20:37:48.051Z	DEBUG	kzap@v0.1.0/kzap.go:105	sasl expiry limit reached, reauthenticating	{""broker"": ""1""}"
"2024-06-18T20:37:48.051Z	DEBUG	kzap@v0.1.0/kzap.go:105	issuing SASLHandshakeRequest	{""broker"": ""1""}"
"2024-06-18T20:37:48.051Z	DEBUG	kzap@v0.1.0/kzap.go:105	wrote SASLHandshake v1	{""broker"": ""1"", ""bytes_written"": 30, ""write_wait"": ""12.03µs"", ""time_to_write"": ""50.431µs"", ""err"": null}"
"2024-06-18T20:37:48.052Z	DEBUG	kzap@v0.1.0/kzap.go:105	read SASLHandshake v1	{""broker"": ""1"", ""bytes_read"": 40, ""read_wait"": ""42.972µs"", ""time_to_read"": ""1.091305ms"", ""err"": null}"
"2024-06-18T20:37:48.052Z	DEBUG	kzap@v0.1.0/kzap.go:105	beginning sasl authentication	{""broker"": ""1"", ""addr"": ""b-1-public.REDACTED.amazonaws.com:9198"", ""mechanism"": ""AWS_MSK_IAM"", ""authenticate"": true}"
"2024-06-18T20:37:48.052Z	DEBUG	kzap@v0.1.0/kzap.go:105	issuing SASLAuthenticate	{""broker"": ""1"", ""version"": 2, ""step"": 0}"
"2024-06-18T20:37:48.053Z	DEBUG	kzap@v0.1.0/kzap.go:105	wrote SASLAuthenticate v2	{""broker"": ""1"", ""bytes_written"": 1755, ""write_wait"": ""8.298µs"", ""time_to_write"": ""45.558µs"", ""err"": null}"
"2024-06-18T20:37:48.065Z	DEBUG	kzap@v0.1.0/kzap.go:105	read SASLAuthenticate v2	{""broker"": ""1"", ""bytes_read"": 98, ""read_wait"": ""31.063µs"", ""time_to_read"": ""12.384996ms"", ""err"": null}"
"2024-06-18T20:37:48.065Z	DEBUG	kzap@v0.1.0/kzap.go:105	sasl has a limited lifetime	{""broker"": ""1"", ""session_lifetime"": ""936ms"", ""lifetime_pessimism"": ""1s"", ""reauthenticate_in"": ""-64ms""}"
"2024-06-18T20:37:48.065Z	DEBUG	kzap@v0.1.0/kzap.go:105	wrote Produce v9	{""broker"": ""1"", ""bytes_written"": 643, ""write_wait"": ""14.047337ms"", ""time_to_write"": ""47.9µs"", ""err"": null}"
"2024-06-18T20:37:48.069Z	DEBUG	kzap@v0.1.0/kzap.go:105	read Produce v9	{""broker"": ""1"", ""bytes_read"": 94, ""read_wait"": ""48.54µs"", ""time_to_read"": ""4.039864ms"", ""err"": null}"
"2024-06-18T20:37:48.069Z	DEBUG	kzap@v0.1.0/kzap.go:105	produced	{""broker"": ""1"", ""to"": ""REDACTED[0{778238=>778239}]""}"
"2024-06-18T20:37:48.088Z	DEBUG	kzap@v0.1.0/kzap.go:105	sasl expiry limit reached, reauthenticating	{""broker"": ""1""}"
"2024-06-18T20:37:48.088Z	DEBUG	kzap@v0.1.0/kzap.go:105	issuing SASLHandshakeRequest	{""broker"": ""1""}"
"2024-06-18T20:37:48.088Z	DEBUG	kzap@v0.1.0/kzap.go:105	wrote SASLHandshake v1	{""broker"": ""1"", ""bytes_written"": 30, ""write_wait"": ""12.261µs"", ""time_to_write"": ""67.692µs"", ""err"": null}"
"2024-06-18T20:37:48.106Z	DEBUG	kzap@v0.1.0/kzap.go:105	read SASLHandshake v1	{""broker"": ""1"", ""bytes_read"": 14, ""read_wait"": ""57.922µs"", ""time_to_read"": ""17.648534ms"", ""err"": null}"
"2024-06-18T20:37:48.106Z	WARN	kzap@v0.1.0/kzap.go:111	random error while producing, requeueing unattempted request	{""broker"": ""1"", ""err"": ""ILLEGAL_SASL_STATE: Request is not valid given the current SASL state.""}"
github.com/twmb/franz-go/plugin/kzap.(*Logger).Log
/go/pkg/mod/github.com/twmb/franz-go/plugin/kzap@v0.1.0/kzap.go:111
github.com/twmb/franz-go/pkg/kgo.(*wrappedLogger).Log
/go/pkg/mod/github.com/twmb/franz-go@v1.16.1/pkg/kgo/logger.go:123
github.com/twmb/franz-go/pkg/kgo.(*sink).handleReqClientErr
/go/pkg/mod/github.com/twmb/franz-go@v1.16.1/pkg/kgo/sink.go:531
github.com/twmb/franz-go/pkg/kgo.(*sink).handleReqResp
/go/pkg/mod/github.com/twmb/franz-go@v1.16.1/pkg/kgo/sink.go:581
github.com/twmb/franz-go/pkg/kgo.(*sink).produce.func3
/go/pkg/mod/github.com/twmb/franz-go@v1.16.1/pkg/kgo/sink.go:369
github.com/twmb/franz-go/pkg/kgo.(*sink).handleSeqResps
/go/pkg/mod/github.com/twmb/franz-go@v1.16.1/pkg/kgo/sink.go:411
"2024-06-18T20:37:48.106Z	INFO	kzap@v0.1.0/kzap.go:109	produce request failed, triggering metadata update	{""broker"": ""1"", ""err"": ""ILLEGAL_SASL_STATE: Request is not valid given the current SASL state.""}"
"2024-06-18T20:37:48.106Z	DEBUG	kzap@v0.1.0/kzap.go:105	retry batches processed	{""wanted_metadata_update"": true, ""triggering_metadata_update"": true, ""should_backoff"": false}"
"2024-06-18T20:37:48.106Z	INFO	kzap@v0.1.0/kzap.go:109	metadata update triggered	{""why"": ""failed produce request triggered metadata update""}"
"2024-06-18T20:37:48.191Z	DEBUG	kzap@v0.1.0/kzap.go:105	wrote Produce v9	{""broker"": ""1"", ""bytes_written"": 777, ""write_wait"": ""33.683µs"", ""time_to_write"": ""61.676µs"", ""err"": null}"
"2024-06-18T20:37:48.192Z	DEBUG	kzap@v0.1.0/kzap.go:105	read Produce v9	{""broker"": ""1"", ""bytes_read"": 94, ""read_wait"": ""95.167µs"", ""time_to_read"": ""1.037898ms"", ""err"": null}"
"2024-06-18T20:37:48.192Z	DEBUG	kzap@v0.1.0/kzap.go:105	produced	{""broker"": ""1"", ""to"": ""REDACTED[0{778240=>778241}]""}"
"2024-06-18T20:37:48.389Z	DEBUG	kzap@v0.1.0/kzap.go:105	wrote Produce v9	{""broker"": ""1"", ""bytes_written"": 780, ""write_wait"": ""36.824µs"", ""time_to_write"": ""45.222µs"", ""err"": null}"
"2024-06-18T20:37:48.390Z	DEBUG	kzap@v0.1.0/kzap.go:105	read Produce v9	{""broker"": ""1"", ""bytes_read"": 94, ""read_wait"": ""69.801µs"", ""time_to_read"": ""768.197µs"", ""err"": null}"
"2024-06-18T20:37:48.390Z	DEBUG	kzap@v0.1.0/kzap.go:105	produced	{""broker"": ""1"", ""to"": ""REDACTED[0{778243=>778244}]""}"
"2024-06-18T20:37:48.591Z	DEBUG	kzap@v0.1.0/kzap.go:105	wrote Produce v9	{""broker"": ""1"", ""bytes_written"": 780, ""write_wait"": ""23.634µs"", ""time_to_write"": ""46.818µs"", ""err"": null}"
"2024-06-18T20:37:48.592Z	DEBUG	kzap@v0.1.0/kzap.go:105	read Produce v9	{""broker"": ""1"", ""bytes_read"": 94, ""read_wait"": ""61.724µs"", ""time_to_read"": ""786.672µs"", ""err"": null}"
"2024-06-18T20:37:48.592Z	DEBUG	kzap@v0.1.0/kzap.go:105	produced	{""broker"": ""1"", ""to"": ""REDACTED[0{778246=>778247}]""}"
"2024-06-18T20:37:48.650Z	DEBUG	kzap@v0.1.0/kzap.go:105	wrote Produce v9	{""broker"": ""1"", ""bytes_written"": 644, ""write_wait"": ""27.785µs"", ""time_to_write"": ""46.696µs"", ""err"": null}"
"2024-06-18T20:37:48.650Z	DEBUG	kzap@v0.1.0/kzap.go:105	read Produce v9	{""broker"": ""1"", ""bytes_read"": 94, ""read_wait"": ""86.61µs"", ""time_to_read"": ""694.89µs"", ""err"": null}"
"2024-06-18T20:37:48.650Z	DEBUG	kzap@v0.1.0/kzap.go:105	produced	{""broker"": ""1"", ""to"": ""REDACTED[0{778248=>778249}]""}"
"2024-06-18T20:37:48.893Z	DEBUG	kzap@v0.1.0/kzap.go:105	wrote Produce v9	{""broker"": ""1"", ""bytes_written"": 780, ""write_wait"": ""30.491µs"", ""time_to_write"": ""53.437µs"", ""err"": null}"
"2024-06-18T20:37:48.894Z	DEBUG	kzap@v0.1.0/kzap.go:105	read Produce v9	{""broker"": ""1"", ""bytes_read"": 94, ""read_wait"": ""80.824µs"", ""time_to_read"": ""780.472µs"", ""err"": null}"
"2024-06-18T20:37:48.894Z	DEBUG	kzap@v0.1.0/kzap.go:105	produced	{""broker"": ""1"", ""to"": ""REDACTED[0{778251=>778252}]""}"
"2024-06-18T20:37:48.953Z	DEBUG	kzap@v0.1.0/kzap.go:105	wrote Produce v9	{""broker"": ""1"", ""bytes_written"": 644, ""write_wait"": ""24.65µs"", ""time_to_write"": ""44.14µs"", ""err"": null}"
"2024-06-18T20:37:48.954Z	DEBUG	kzap@v0.1.0/kzap.go:105	read Produce v9	{""broker"": ""1"", ""bytes_read"": 94, ""read_wait"": ""69.11µs"", ""time_to_read"": ""775.095µs"", ""err"": null}"
"2024-06-18T20:37:48.954Z	DEBUG	kzap@v0.1.0/kzap.go:105	produced	{""broker"": ""1"", ""to"": ""REDACTED[0{778253=>778254}]""}"
"2024-06-18T20:37:49.203Z	DEBUG	kzap@v0.1.0/kzap.go:105	wrote Produce v9	{""broker"": ""1"", ""bytes_written"": 777, ""write_wait"": ""32.71µs"", ""time_to_write"": ""48.865µs"", ""err"": null}"
"2024-06-18T20:37:49.204Z	DEBUG	kzap@v0.1.0/kzap.go:105	read Produce v9	{""broker"": ""1"", ""bytes_read"": 94, ""read_wait"": ""83.708µs"", ""time_to_read"": ""851.99µs"", ""err"": null}"
"2024-06-18T20:37:49.204Z	DEBUG	kzap@v0.1.0/kzap.go:105	produced	{""broker"": ""1"", ""to"": ""REDACTED[0{778256=>778257}]""}"
"2024-06-18T20:37:49.267Z	DEBUG	kzap@v0.1.0/kzap.go:105	wrote Produce v9	{""broker"": ""1"", ""bytes_written"": 641, ""write_wait"": ""25.185µs"", ""time_to_write"": ""45.943µs"", ""err"": null}"
"2024-06-18T20:37:49.268Z	DEBUG	kzap@v0.1.0/kzap.go:105	read Produce v9	{""broker"": ""1"", ""bytes_read"": 94, ""read_wait"": ""75.01µs"", ""time_to_read"": ""752.085µs"", ""err"": null}"
"2024-06-18T20:37:49.268Z	DEBUG	kzap@v0.1.0/kzap.go:105	produced	{""broker"": ""1"", ""to"": ""REDACTED[0{778258=>778259}]""}"
"2024-06-18T20:37:49.490Z	DEBUG	kzap@v0.1.0/kzap.go:105	wrote Produce v9	{""broker"": ""1"", ""bytes_written"": 780, ""write_wait"": ""25.02µs"", ""time_to_write"": ""42.43µs"", ""err"": null}"
"2024-06-18T20:37:49.491Z	DEBUG	kzap@v0.1.0/kzap.go:105	read Produce v9	{""broker"": ""1"", ""bytes_read"": 94, ""read_wait"": ""70.766µs"", ""time_to_read"": ""848.823µs"", ""err"": null}"
"2024-06-18T20:37:49.491Z	DEBUG	kzap@v0.1.0/kzap.go:105	produced	{""broker"": ""1"", ""to"": ""REDACTED[0{778260=>778261}]""}"
"2024-06-18T20:37:49.549Z	DEBUG	kzap@v0.1.0/kzap.go:105	wrote Produce v9	{""broker"": ""1"", ""bytes_written"": 644, ""write_wait"": ""25.806µs"", ""time_to_write"": ""45.988µs"", ""err"": null}"
"2024-06-18T20:37:49.549Z	DEBUG	kzap@v0.1.0/kzap.go:105	read Produce v9	{""broker"": ""1"", ""bytes_read"": 94, ""read_wait"": ""86.452µs"", ""time_to_read"": ""694.985µs"", ""err"": null}"
"2024-06-18T20:37:49.549Z	DEBUG	kzap@v0.1.0/kzap.go:105	produced	{""broker"": ""1"", ""to"": ""REDACTED[0{778262=>778263}]""}"
"2024-06-18T20:37:49.800Z	DEBUG	kzap@v0.1.0/kzap.go:105	wrote Produce v9	{""broker"": ""1"", ""bytes_written"": 780, ""write_wait"": ""24.503µs"", ""time_to_write"": ""44.782µs"", ""err"": null}"
"2024-06-18T20:37:49.801Z	DEBUG	kzap@v0.1.0/kzap.go:105	read Produce v9	{""broker"": ""1"", ""bytes_read"": 94, ""read_wait"": ""76.126µs"", ""time_to_read"": ""818.682µs"", ""err"": null}"
"2024-06-18T20:37:49.801Z	DEBUG	kzap@v0.1.0/kzap.go:105	produced	{""broker"": ""1"", ""to"": ""REDACTED[0{778266=>778267}]""}"
"2024-06-18T20:37:49.859Z	DEBUG	kzap@v0.1.0/kzap.go:105	wrote Produce v9	{""broker"": ""1"", ""bytes_written"": 644, ""write_wait"": ""32.997µs"", ""time_to_write"": ""47.074µs"", ""err"": null}"
"2024-06-18T20:37:49.860Z	DEBUG	kzap@v0.1.0/kzap.go:105	read Produce v9	{""broker"": ""1"", ""bytes_read"": 94, ""read_wait"": ""85.297µs"", ""time_to_read"": ""915.296µs"", ""err"": null}"
""2024-06-18T20:37:50.052Z	DEBUG	kzap@v0.1.0/kzap.go:105	sasl expiry limit reached, reauthenticating	{""broker"": ""3""}"
"2024-06-18T20:37:50.052Z	DEBUG	kzap@v0.1.0/kzap.go:105	issuing SASLHandshakeRequest	{""broker"": ""3""}"
"2024-06-18T20:37:50.052Z	DEBUG	kzap@v0.1.0/kzap.go:105	wrote SASLHandshake v1	{""broker"": ""3"", ""bytes_written"": 30, ""write_wait"": ""11.888µs"", ""time_to_write"": ""54.789µs"", ""err"": null}"
"2024-06-18T20:37:50.052Z	DEBUG	kzap@v0.1.0/kzap.go:105	read SASLHandshake v1	{""broker"": ""3"", ""bytes_read"": 40, ""read_wait"": ""96.019µs"", ""time_to_read"": ""568.061µs"", ""err"": null}"
"2024-06-18T20:37:50.052Z	DEBUG	kzap@v0.1.0/kzap.go:105	beginning sasl authentication	{""broker"": ""3"", ""addr"": ""b-3-public.REDACTED.amazonaws.com:9198"", ""mechanism"": ""AWS_MSK_IAM"", ""authenticate"": true}"
"2024-06-18T20:37:50.092Z	DEBUG	kzap@v0.1.0/kzap.go:105	wrote Produce v9	{""broker"": ""1"", ""bytes_written"": 777, ""write_wait"": ""22.265µs"", ""time_to_write"": ""44.407µs"", ""err"": null}"
"2024-06-18T20:37:50.092Z	DEBUG	kzap@v0.1.0/kzap.go:105	read Produce v9	{""broker"": ""1"", ""bytes_read"": 94, ""read_wait"": ""58.667µs"", ""time_to_read"": ""877.818µs"", ""err"": null}"
"2024-06-18T20:37:50.093Z	DEBUG	kzap@v0.1.0/kzap.go:105	produced	{""broker"": ""1"", ""to"": ""REDACTED[0{778271=>778272}]""}"
"2024-06-18T20:37:50.133Z	DEBUG	kzap@v0.1.0/kzap.go:105	issuing SASLAuthenticate	{""broker"": ""3"", ""version"": 2, ""step"": 0}"
"2024-06-18T20:37:50.134Z	DEBUG	kzap@v0.1.0/kzap.go:105	wrote SASLAuthenticate v2	{""broker"": ""3"", ""bytes_written"": 1755, ""write_wait"": ""9.053µs"", ""time_to_write"": ""95.662µs"", ""err"": null}"
"2024-06-18T20:37:50.151Z	DEBUG	kzap@v0.1.0/kzap.go:105	wrote Produce v9	{""broker"": ""1"", ""bytes_written"": 641, ""write_wait"": ""26.78µs"", ""time_to_write"": ""41.639µs"", ""err"": null}"
"2024-06-18T20:37:50.152Z	DEBUG	kzap@v0.1.0/kzap.go:105	read Produce v9	{""broker"": ""1"", ""bytes_read"": 94, ""read_wait"": ""61.357µs"", ""time_to_read"": ""733.487µs"", ""err"": null}"
"2024-06-18T20:37:50.152Z	DEBUG	kzap@v0.1.0/kzap.go:105	produced	{""broker"": ""1"", ""to"": ""REDACTED[0{778273=>778274}]""}"
"2024-06-18T20:37:50.258Z	DEBUG	kzap@v0.1.0/kzap.go:105	read SASLAuthenticate v2	{""broker"": ""3"", ""bytes_read"": 294, ""read_wait"": ""50.968µs"", ""time_to_read"": ""124.369308ms"", ""err"": null}"
"2024-06-18T20:37:50.258Z	DEBUG	kzap@v0.1.0/kzap.go:105	sasl reauth failed, retrying once on new connection	{""broker"": ""3"", ""err"": ""Cannot change principals during re-authentication from IAM.arn:aws:sts::REDACTED:assumed-role/REDACTED/REDACTED: IAM.arn:aws:sts::REDACTED:assumed-role/REDACTED/REDACTED: SASL_AUTHENTICATION_FAILED: SASL Authentication failed.""}"
"2024-06-18T20:37:50.258Z	DEBUG	kzap@v0.1.0/kzap.go:105	opening connection to broker	{""addr"": ""b-3-public.REDACTED.amazonaws.com:9198"", ""broker"": ""3""}"
"2024-06-18T20:37:50.267Z	DEBUG	kzap@v0.1.0/kzap.go:105	connection opened to broker	{""addr"": ""b-3-public.REDACTED.amazonaws.com:9198"", ""broker"": ""3""}"
"2024-06-18T20:37:50.267Z	DEBUG	kzap@v0.1.0/kzap.go:105	issuing SASLHandshakeRequest	{""broker"": ""3""}"
"2024-06-18T20:37:50.267Z	DEBUG	kzap@v0.1.0/kzap.go:105	wrote SASLHandshake v1	{""broker"": ""3"", ""bytes_written"": 30, ""write_wait"": ""8.466µs"", ""time_to_write"": ""32.194µs"", ""err"": null}"
"2024-06-18T20:37:50.267Z	DEBUG	kzap@v0.1.0/kzap.go:105	read SASLHandshake v1	{""broker"": ""3"", ""bytes_read"": 40, ""read_wait"": ""36.113µs"", ""time_to_read"": ""458.292µs"", ""err"": null}"
"2024-06-18T20:37:50.267Z	DEBUG	kzap@v0.1.0/kzap.go:105	beginning sasl authentication	{""broker"": ""3"", ""addr"": ""b-3-public.REDACTED.amazonaws.com:9198"", ""mechanism"": ""AWS_MSK_IAM"", ""authenticate"": true}"
"2024-06-18T20:37:50.267Z	DEBUG	kzap@v0.1.0/kzap.go:105	issuing SASLAuthenticate	{""broker"": ""3"", ""version"": 2, ""step"": 0}"
"2024-06-18T20:37:50.267Z	DEBUG	kzap@v0.1.0/kzap.go:105	wrote SASLAuthenticate v2	{""broker"": ""3"", ""bytes_written"": 1755, ""write_wait"": ""6.579µs"", ""time_to_write"": ""42.996µs"", ""err"": null}"
"2024-06-18T20:37:50.279Z	DEBUG	kzap@v0.1.0/kzap.go:105	read SASLAuthenticate v2	{""broker"": ""3"", ""bytes_read"": 98, ""read_wait"": ""30.854µs"", ""time_to_read"": ""11.105484ms"", ""err"": null}"
"2024-06-18T20:37:50.279Z	DEBUG	kzap@v0.1.0/kzap.go:105	sasl has a limited lifetime	{""broker"": ""3"", ""session_lifetime"": ""59m59.722s"", ""lifetime_pessimism"": ""1m23.054s"", ""reauthenticate_in"": ""58m36.668s""}"
"2024-06-18T20:37:50.279Z	DEBUG	kzap@v0.1.0/kzap.go:105	connection initialized successfully	{""addr"": ""b-3-public.REDACTED.amazonaws.com:9198"", ""broker"": ""3""}"
"2024-06-18T20:37:50.279Z	DEBUG	kzap@v0.1.0/kzap.go:105	wrote Metadata v12	{""broker"": ""3"", ""bytes_written"": 83, ""write_wait"": ""226.997748ms"", ""time_to_write"": ""47.72µs"", ""err"": null}"
"2024-06-18T20:37:50.291Z	DEBUG	kzap@v0.1.0/kzap.go:105	read Metadata v12	{""broker"": ""3"", ""bytes_read"": 418, ""read_wait"": ""41.567µs"", ""time_to_read"": ""12.729919ms"", ""err"": null}"
"2024-06-18T20:37:50.292Z	DEBUG	kzap@v0.1.0/kzap.go:105	metadata refresh has identical topic partition data	{""topic"": ""REDACTED"", ""partition"": 0, ""leader"": 1, ""leader_epoch"": 150}"
"2024-06-18T20:37:50.292Z	WARN	producer/producer.go:286	failed to produce messages	{""error"": ""context deadline exceeded"", ""contextCause"": null}"
"2024-06-18T20:37:50.293Z	WARN	producer/producer.go:286	failed to produce messages	{""error"": ""context deadline exceeded"", ""contextCause"": ""context deadline exceeded""}"
"2024-06-18T20:37:50.293Z	WARN	producer/producer.go:286	failed to produce messages	{""error"": ""context deadline exceeded"", ""contextCause"": ""context deadline exceeded""}"
"2024-06-18T20:37:50.293Z	WARN	producer/producer.go:286	failed to produce messages	{""error"": ""context deadline exceeded"", ""contextCause"": ""context deadline exceeded""}"
"2024-06-18T20:37:50.293Z	WARN	producer/producer.go:286	failed to produce messages	{""error"": ""context deadline exceeded"", ""contextCause"": ""context deadline exceeded""}"
"2024-06-18T20:37:50.293Z	WARN	producer/producer.go:286	failed to produce messages	{""error"": ""context deadline exceeded"", ""contextCause"": ""context deadline exceeded""}"
"2024-06-18T20:37:50.293Z	WARN	producer/producer.go:286	failed to produce messages	{""error"": ""context deadline exceeded"", ""contextCause"": ""context deadline exceeded""}"
"2024-06-18T20:37:50.293Z	WARN	producer/producer.go:286	failed to produce messages	{""error"": ""context deadline exceeded"", ""contextCause"": ""context deadline exceeded""}"
"2024-06-18T20:37:50.294Z	WARN	producer/producer.go:286	failed to produce messages	{""error"": ""context deadline exceeded"", ""contextCause"": ""context deadline exceeded""}"
"2024-06-18T20:37:50.294Z	WARN	producer/producer.go:286	failed to produce messages	{""error"": ""context deadline exceeded"", ""contextCause"": ""context deadline exceeded""}"
"2024-06-18T20:37:50.294Z	WARN	producer/producer.go:286	failed to produce messages	{""error"": ""context deadline exceeded"", ""contextCause"": ""context deadline exceeded""}"
"2024-06-18T20:37:50.294Z	WARN	producer/producer.go:286	failed to produce messages	{""error"": ""context deadline exceeded"", ""contextCause"": ""context deadline exceeded""}"
"2024-06-18T20:37:50.294Z	WARN	producer/producer.go:286	failed to produce messages	{""error"": ""context deadline exceeded"", ""contextCause"": ""context deadline exceeded""}"
"2024-06-18T20:37:50.294Z	WARN	producer/producer.go:286	failed to produce messages	{""error"": ""context deadline exceeded"", ""contextCause"": ""context deadline exceeded""}"
"2024-06-18T20:37:50.294Z	WARN	producer/producer.go:286	failed to produce messages	{""error"": ""context deadline exceeded"", ""contextCause"": null}"
"2024-06-18T20:37:50.294Z	WARN	producer/producer.go:286	failed to produce messages	{""error"": ""context deadline exceeded"", ""contextCause"": null}"
"2024-06-18T20:37:50.294Z	WARN	producer/producer.go:286	failed to produce messages	{""error"": ""context deadline exceeded"", ""contextCause"": null}"
"2024-06-18T20:37:50.303Z	DEBUG	kzap@v0.1.0/kzap.go:105	opening connection to broker	{""addr"": ""b-1-public.REDACTED.amazonaws.com:9198"", ""broker"": ""1""}"
"2024-06-18T20:37:50.353Z	DEBUG	kzap@v0.1.0/kzap.go:105	connection opened to broker	{""addr"": ""b-1-public.REDACTED.amazonaws.com:9198"", ""broker"": ""1""}"
"2024-06-18T20:37:50.353Z	DEBUG	kzap@v0.1.0/kzap.go:105	issuing SASLHandshakeRequest	{""broker"": ""1""}"
"2024-06-18T20:37:50.353Z	DEBUG	kzap@v0.1.0/kzap.go:105	wrote SASLHandshake v1	{""broker"": ""1"", ""bytes_written"": 30, ""write_wait"": ""10.279µs"", ""time_to_write"": ""33.919µs"", ""err"": null}"
"2024-06-18T20:37:50.354Z	DEBUG	kzap@v0.1.0/kzap.go:105	read SASLHandshake v1	{""broker"": ""1"", ""bytes_read"": 40, ""read_wait"": ""36.204µs"", ""time_to_read"": ""953.121µs"", ""err"": null}"
"2024-06-18T20:37:50.354Z	DEBUG	kzap@v0.1.0/kzap.go:105	beginning sasl authentication	{""broker"": ""1"", ""addr"": ""b-1-public.REDACTED.amazonaws.com:9198"", ""mechanism"": ""AWS_MSK_IAM"", ""authenticate"": true}"
"2024-06-18T20:37:50.354Z	DEBUG	kzap@v0.1.0/kzap.go:105	issuing SASLAuthenticate	{""broker"": ""1"", ""version"": 2, ""step"": 0}"
"2024-06-18T20:37:50.354Z	DEBUG	kzap@v0.1.0/kzap.go:105	wrote SASLAuthenticate v2	{""broker"": ""1"", ""bytes_written"": 1755, ""write_wait"": ""7.747µs"", ""time_to_write"": ""47.471µs"", ""err"": null}"
"2024-06-18T20:37:50.381Z	DEBUG	kzap@v0.1.0/kzap.go:105	read SASLAuthenticate v2	{""broker"": ""1"", ""bytes_read"": 98, ""read_wait"": ""28.946µs"", ""time_to_read"": ""26.771741ms"", ""err"": null}"
"2024-06-18T20:37:50.381Z	DEBUG	kzap@v0.1.0/kzap.go:105	sasl has a limited lifetime	{""broker"": ""1"", ""session_lifetime"": ""59m59.62s"", ""lifetime_pessimism"": ""2m44.771s"", ""reauthenticate_in"": ""57m14.849s""}"
"2024-06-18T20:37:50.381Z	DEBUG	kzap@v0.1.0/kzap.go:105	connection initialized successfully	{""addr"": ""b-1-public.REDACTED.amazonaws.com:9198"", ""broker"": ""1""}"
"2024-06-18T20:37:49.860Z	DEBUG	kzap@v0.1.0/kzap.go:105	produced	{""broker"": ""1"", ""to"": ""REDACTED[0{778268=>778269}]""}"
You can see that they are now returning a "context deadline exceeded" error instead of a "context canceled" error because we added a parent context with a timeout of 500ms. It was taking several seconds to get the "context cancelled" so we added this to fail faster so we can retry.
But the flow is the same. I can't tell in this scenario if the produce request that are failing were going to broker 1 or broker 3. If it's broker 3, then we appear to cancel and not retry produce requests for the original broker connection. See https://github.com/twmb/franz-go/issues/249 for the change that creates a new connection when SASL authentication fails. If it's broker 1, then it seems more related to the ILLEGAL_SASL_STATE due to the short session.

There is no canceling in the produce path of the codebase:
@m4x3r:~/src/twmb/franz-go/pkg/kgo
$ rg 'ancel\('
client.go
457:	ctx, cancel := context.WithCancel(context.Background())
1031:	sessCloseCancel()
1036:	cl.ctxCancel()
1318:	ctx, cancel := context.WithCancel(ctx)
1322:		defer cancel()
2031:	ctx, cancel := context.WithCancel(ctx)
2032:	defer cancel()

group_test.go
184:		cancel()

txn_test.go
173:		cancel()

consumer.go
1448:	ctx, cancel := context.WithCancel(c.cl.ctx)
1614:	session.cancel()

source.go
788:		ctx, cancel = context.WithCancel(consumerSession.ctx)
790:	defer cancel()

consumer_group.go
240:		ctx, cancel = context.WithCancel(context.Background())
241:		cancel()
276:	ctx, cancel := context.WithCancel(c.cl.ctx)
497:	g.cancel()
846:	ctx, cancel := context.WithCancel(g.ctx)
848:		defer cancel() // potentially kill offset fetching
2812:	commitCtx, commitCancel := context.WithCancel(ctx) // enable ours to be canceled and waited for
2829:				commitCancel()
2837:		defer commitCancel()
2843:				priorCancel()

consumer_direct_test.go
34:	defer cancel()
108:	defer cancel()
156:	cancel()
163:	defer cancel()
232:		cancel()
328:	ctx, cancel := context.WithCancel(context.Background())
344:	defer cancel()
374:			cancel()
406:	ctx, cancel := context.WithCancel(context.Background())
422:	defer cancel()
452:			cancel()
499:		cancel()
523:	cancel()

txn.go
1163:		g.commitCancel() // cancel any prior commit
1173:	commitCtx, commitCancel := context.WithCancel(g.ctx) // enable ours to be canceled and waited for
1183:				commitCancel()
1191:		defer commitCancel()
1197:				priorCancel()

The cancel calls in client.go are unrelated or irrelevant here. Everything else is related to consuming.
Without looking at your code, my guess is that you are using the same context across multiple Produce calls and are canceling it after some messages return, which causes buffered records to be canceled too.
The logs above look normal, minus the SASL problems that we've discussed in a few issues. If you really want to see where the cancel is coming from, I think you could write a wrapper context.Context interface that calls debug.PrintStack on cancel before calling the inner (original) cancel func. I'd be pretty curious to know what the debug logs say.
I'm not really sure what to do in the client at this point for the SASL problems, considering this is almost the same behavior as the Kafka Java client itself. IMO, AWS needs to have some answer to the SASL problems -- like, propose a solution, or change what they allow. Given what I saw when I implemented the AWS_MSK_IAM auth 3yr ago, the broker side seemed a bit odd at the time.

Let me know if you have a bit more of an idea on this one -- from my audit of the code, nothing should be causing other records to return context.Canceled.

The underlying cause of this was the SASL "session too short" errors (https://github.com/twmb/franz-go/issues/731). The solution posted there has also resolved this problem. Thanks!


No way to remove management agents

We have several management agents that have been removed from our MIM config, but they still show up in AutoSync.  I don't see any way to delete them or otherwise remove them from the list.

Hi Jamie,
When the management agent is removed from MIM, it should appear in AutoSync as 'missing'. You may need to restart autosync for it to detect the missing management agent. Once it does, you'll have the option to right-click and remove

Mine just show unconfigured in italics when I remove them.  Let me make sure I’m on the most current version.
—
Jamie Booth
Windows Core Architect
WestRock
<EMAIL_ADDRESS>
From: Ryan Newington<EMAIL_ADDRESS>Sent: Wednesday, November 27, 2019 4:10:30 PM
To: lithnet/miis-autosync<EMAIL_ADDRESS>Cc: Jamie Booth<EMAIL_ADDRESS>Author<EMAIL_ADDRESS>Subject: Re: [lithnet/miis-autosync] No way to remove management agents (#168)
EXTERNAL - Use Caution. Do not click links or open attachments unless you know the content is safe.
Hi Jamie,
When the management agent is removed from MIM, it should appear in AutoSync as 'missing'. You may need to restart autosync for it to detect the missing management agent. Once it does, you'll have the option to right-click and remove
[image]https://protect2.fireeye.com/v1/url?k=b02edb11-eca46d3e-b02e6d68-8631e7619575-d8a1a1bfa37198a1&q=1&e=6736acce-56de-4307-9c38-bb926fe8816c&u=https%3A%2F%2Fuser-images.githubusercontent.com%2F17229877%2F69759531-7271c480-11b6-11ea-94ee-a1ac6b8d941e.png
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHubhttps://protect2.fireeye.com/v1/url?k=88494690-d4c3f0bf-8849f0e9-8631e7619575-cabcdb3c97b0e216&q=1&e=6736acce-56de-4307-9c38-bb926fe8816c&u=https%3A%2F%2Fgithub.com%2Flithnet%2Fmiis-autosync%2Fissues%2F168%3Femail_source%3Dnotifications%26email_token%3DAGWCK3ADRUT4WJ3PRAKEILTQV3O4NA5CNFSM4JSLJC2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEFKYDZA%23issuecomment-559251940, or unsubscribehttps://protect2.fireeye.com/v1/url?k=5e0fe1d6-028557f9-5e0f57af-8631e7619575-f58e8ebb099ba960&q=1&e=6736acce-56de-4307-9c38-bb926fe8816c&u=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAGWCK3DEKM7YR4IOF43IUR3QV3O4NANCNFSM4JSLJC2A.

This electronic message contains information from WestRock Company (www.westrock.com) or its subsidiaries, which may be confidential, privileged or otherwise protected from disclosure. The information is intended to be disclosed to and used by only the named recipient(s). If you are not the intended recipient, then your review, use, disclosure, printing, copying, or distribution of this message or its contents is prohibited. If you have received this message in error, please notify WestRock immediately at<EMAIL_ADDRESS>and delete the message from your system. For information about WestRock's privacy practices, including how WestRock collects, processes, transfers, and stores Personally Identifiable Information shared with us, please visit WestRock Privacy Policyhttps://www.westrock.com/en/privacy-policy.. Unless previously authorized in writing, this message does not constitute an offer, acceptance, or agreement of any kind. Sender is not liable for damage, errors or omissions related to or caused by transmission of this message.
(c) WestRock Company.

What happens if you modify config and save it?

I was a version or so back.  Latest version works as you described.


QT_QPA_PLATFORM=xcb not available?

Describe the bug
I had previously been running obs with the xcb backend.
I don't think I've changed anything relevant, but xcb is no longer available?
env QT_QPA_PLATFORM=xcb obs
qt.qpa.plugin: Could not find the Qt platform plugin "xcb" in ""
This application failed to start because no Qt platform plugin could be initialized. Reinstalling the application may fix this problem.

Available platform plugins are: wayland-egl, wayland, wayland-xcomposite-egl, wayland-xcomposite-glx.

Aborted (core dumped)

I know the wayland backends are provided by getting qt5.qtwayland into my environment. Is something now necessary in the same fashion for the xcb backend to be available?
Expected behavior
A clear and concise description of what you expected to happen.
Screenshots
If applicable, add screenshots to help explain your problem.
Additional context
Add any other context about the problem here.
Metadata
Please run nix run nixpkgs.nix-info -c nix-info -m and paste the result.
Maintainer information:
# a list of nixpkgs attributes affected by the problem
attribute:
# a list of nixos modules affected by the problem
module:

qt5.qtbase needs to be in my env now, as well, it seems.
from: https://github.com/NixOS/nixpkgs/issues/42893#issuecomment-463766410

See #65399, obs will need its QT wrapping fixed. Let me know if you need help.

This issue has been mentioned on NixOS Discourse. There might be relevant details there:
https://discourse.nixos.org/t/streamdeck-ui-on-unstable-getting-qt-error/27996/1


docs: standardize geometry docstring to fit sphinx

Remove the scope (tensorbay) in pull request name and commit message


Keep comments in chartfile.yaml?

Hi,
the commands tk tool charts (add-repo|add update the chartfile and remove ALL comments. This might not be desired or expected.
Would it be possible to change the command to keep comments in the file?
Further explanation: we are using renovate-bot to manage almost all updates in our code, including tanka/charts. Therefore we added a regex to be able to use comments in the chartfile.yaml to detect and update:
requires:
  - chart: renovate/whitesource-renovate
    # renovate: datasource=helm depName=whitesource-renovate registryUrl=https://mend.github.io/renovate-on-prem versioning=helm
    version: 4.1.0
....

But these useful comments would be removed on add/add-repo..

Hey @strowi thanks for this issue, I was taking a look as I also was running into this issue when updating our chart versions. Unfortunately it looks like the updates required to support this would be a major rewrite and make the code more difficult to work with.
First step is using the go-yaml.v3 subpackage of sigs.k8s.io/yaml since go-yaml.v2 has no support for when loading the file. After that it would require a solution that lets us use the Node type as an intermediary representation since that is the object that preserves comments https://github.com/go-yaml/yaml/blob/v3/yaml.go#L344-L347 . That would involve either updating every struct we have to contain the Node information as well as every reference to the values to work with that new representation, or changing all the functions to work on a raw Node rather than the representative go structs. There may also be a way to store the nodes for some post-processing merge but that would involve writing our own Node-transform functions.
That level of effort and change to the ergonomics of the codebase don't seem worth it at this time to support comments sticking around.

@SimKev2 totally understandable, thank you for looking into it and the explanation!


README rewrite

Now that Horizon is actually a well-functioning program, it's time to update the README to properly reflect Horizon's features.
Rewrite the README.md based on the GitHub guidelines:
https://docs.github.com/en/github/creating-cloning-and-archiving-repositories/about-readmes

Also change GitHut to GitHub (typo) in the readme.


TableUtil.Replace(t1, t2)

Requested on #knit in AGF Discord by Nickuhhh#0331, so I added it.
Replaces all values in t1 that share a key in t2 with the value in t2.

Closing for now


[libra framework] make Signature::ed25519_verify non-aborting

This used to abort when the signature and public key were not well-formed. It now returns false in these cases instead.
Native functions that can abort require us to introduce new native error codes. It's better for us to avoid aborting native functions and minimize the number of error codes in the system if we can manage it.

/land

:broken_heart: Test Failed - Build images and run cluster test

/land


Schema grammar does not include description of commonTypes grammar

What were you trying to do?
Understand schema grammar
https://docs.cedarpolicy.com/schema/schema-grammar.html
What is wrong and why?
commonTypes is mentioned in namespace description but is not covered in grammar details
What do we need to do to fix this?
Add grammar details for commonTypes

Closing as fixed by #130


Didnt work in hexo 4.2

when my link is http://localhost:4000/2020/03/06/%E5%95%86%E4%B8%9A%E8%AE%A1%E5%88%92%E4%B9%A6%E6%92%B0%E5%86%99%E5%8F%8A%E6%A1%88%E4%BE%8B%E5%88%86%E6%9E%90/
the img src is src="/.com//image-20200303154014932.png"
it didn show up.But i can get it when im using http://localhost:4000/2020/03/06/%E5%95%86%E4%B8%9A%E8%AE%A1%E5%88%92%E4%B9%A6%E6%92%B0%E5%86%99%E5%8F%8A%E6%A1%88%E4%BE%8B%E5%88%86%E6%9E%90/image-20200303154014932.png
it work before i upgrade the hexo.
I use file_name.assests/image to store my images when im writing , when I publish it will change folder's name to the same name as markdown file.
By the way this way looks like a solution:link

Hi, @mrbelieve128.
It still works in<EMAIL_ADDRESS>For this plugin, image paths will not be modified for those started with http, https, //, / and plain string(like path/asset.jpg).
And I think you should put your images in the _posts.images directory, then you can directly use the image path with ./images/image-whatever.png since your blog is right in the _posts directory. After magic with this plugin, the final path will be /your_post_path/image-whatever.png.
BTW, don't miss post_asset_folder: true in your _config.yml.