Improved readme

Highlighting the importance of implementing onSigninCallback, as per pamapa's request here : https://github.com/authts/react-oidc-context/issues/99

Closes/fixes #issue
Checklist

[ ] This PR makes changes to the public API
[ ] I have included links for closing relevant issue numbers

Thanks for your effort and that trigger me to think about it again. Maybe its better to have the documented onSigninCallback implementation as the default one, which can be overwritten. Drawback would be that if you do not want anything, you need to pass an empty function. But as you said it wont work...
@kherock What is your opinion?

thanks for your contribution!

It's tiny, but I hope it's useful.
On Mon, May 16, 2022, 08:23 pamapa @.***> wrote:

thanks for your contribution!
—
Reply to this email directly, view it on GitHub
https://github.com/authts/react-oidc-context/pull/354#issuecomment-1127267110,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAKRWJHWA2TIPQYLU5G6F7DVKHSW7ANCNFSM5UQCV24A
.
You are receiving this because you authored the thread.Message ID:
@.***>


Wed Dec  2 02:00:04 CET 2015 BARE METAL-TEST Test error

New build failed 2 of totally 2 checks Network test error:  No reply to arping from <IP_ADDRESS> No reply to ping from <IP_ADDRESS> Testing test_service.img on Linux trident1 3.13.1-031301-generic. Running IncludeOS-VM using QEMU emulator version 2.0.0 (Debian 2.0.0+dfsg-2ubuntu1.6). Memory usage: RSS=26324. Author of latest commit<EMAIL_ADDRESS>


tools: Reimplement CI failure message script to not call curl itself.

Using curl to POST to the CircleCI workflow endpoint on CZO:

Doesn't work on zulip/zulip@main (CZO runs a revert)
Sets a bad example for other orgs
Robs us of an opportunity to dogfood our own zulip/github-actions-zulip

Refactor the Actions workflows in this repo to report failure states using the Zulip Action, and reimplement the related helper scripts in Python, since they'd previously mostly shelled out to Python anyway.
A slightly modified version of this Workflow notified CZO successfully given an intentional failure in the Action. I've fixed the %20 in the topic name[^1] since that test run: the total diff between what was tested against CZO and what is being submitted in this PR can be found here until GitHub eventually garbage collects that commit away :smiley:
[^1]: Indeed, URL encoding strings is now completely unnecessary since the Action eventually uses a NodeJS-based HTTP JSON POST and not a curl incantation with query parameters.
Self-review checklist

[x] Self-reviewed the changes for clarity and maintainability
(variable names, code reuse, readability, etc.).

Communicate decisions, questions, and potential concerns.

[x] Explains differences from previous plans (e.g., issue description).
[ ] Highlights technical choices and bugs encountered.
[ ] Calls out remaining decisions and concerns.
[ ] Automated tests verify logic where appropriate.

Individual commits are ready for review (see commit discipline).

[x] Each commit is a coherent idea.
[x] Commit message(s) explain reasoning and motivation for changes.

Completed manual review and testing of the following:

[x] Visual appearance of the changes.
[ ] Responsiveness and internationalization.
[x] Strings and tooltips.
[x] End-to-end functionality of buttons, interactions and flows.
[ ] Corner cases, error conditions, and easily imagined bugs.

Merged -- I'm excited for the more-dogfooding here, @klardotsh!


Mypy type checking

MyPy type checking to resolve issue https://github.com/adamghill/django-unicorn/issues/705

@all-contributors add epw1624 code


fix(surface): Allow ref null type

Refs return HTMLElement | null. This allows TS users to avoid the following:
anchorElement={anchor.current || undefined}

Should be no change in behavior.

Codecov Report

Merging #978 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master     #978   +/-   ##
=======================================
  Coverage   94.13%   94.13%
=======================================
  Files          86       86
  Lines        3649     3649
  Branches      578      578
=======================================
  Hits         3435     3435
  Misses         90       90
  Partials      124      124

Impacted Files
Coverage Δ

packages/menu-surface/index.tsx
85.54% <ø> (ø)
:arrow_up:

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 7cf30b6...217cde5. Read the comment docs.


New package: ZBar v0.1.0

Registering package: ZBar
Repository: https://github.com/RexWzh/ZBar.jl
Created by: @RexWzh
Version: v0.1.0
Commit: 612eb9f221e63e9987cf59a8b36fb4731c076685
Git reference: HEAD
Description: Julia wrapper for ZBar
Release notes:

Julia wrapper for ZBar

[noblock] ZBar is a wrapper for the C library ZBar.
The name ZBar follows the package guidelines as discussed in another post https://github.com/JuliaRegistries/General/pull/77021.

[noblock] I think it is ready to be merged now ;)


question about analyze time of view counts

Hi brother, I wonder the analyze time of the view counts, is it since the project is created or using the traffic-to-badge Github action?

Yes, the GitHub only provides 2 weeks traffic data. But I combine traffic with branch traffic that backed up before.
It also means the traffic data can be modified by yourself, and only two weeks traffic data which got from API every time can be guaranteed to be official data.

@MuYunyun The GitHub only provides two weeks traffic data, but the action combine traffic with traffic_branch that backed up before.
It also means the traffic data can be modified by yourself, and only two weeks traffic data which got from API every time can be guaranteed to be official data.
The two weeks traffic data also can be seen from insight/traffic with repository.
I will point it out with next release.

thanks, I get.

the indicators about pv/weeks or pv/day maybe be more accurate and useful through official data, is it? Could you add the indicator about pv/weeks in this project?

It is a good idea to show the official traffic data. Thanks for your advice and I will add a badge for pv/week.
Because the traffic data in today will change in every time, and we can't refresh the badge with action schedule(too often). I will set the pv/week for only the data in one week before today.

Because the traffic data in today will change in every time, and we would not refresh the badge with action schedule(too often).

For the same reason, I will remove today's data from the latest data, and it will not be backed up.

It is a good idea to show the official traffic data. Thanks for your advice and I will add a badge for pv/week.
Because the traffic data in today will change in every time, and we would not refresh the badge with action schedule(too often). I will set the pv/week for only the data in one week before today.

can't wait for using it! :smile:

I add test for main branch. If there is no problem, I will release for next day.

see in https://github.com/marketplace/actions/traffic-to-badge

see in https://github.com/marketplace/actions/traffic-to-badge

Thanks. I use views/week successfully in 1.2.0 version, you should update the version in https://github.com/marketplace/actions/traffic-to-badge

Well, I forgot again. 😆


krew: update krew yaml to reflect change to go

updating the krew yaml to reflect the changes are coming from go migration. This krew file is used as configuration file for krew ci krew-release-bot to create the pr in krew index repo.
Signed-off-by: subhamkrai<EMAIL_ADDRESS>

pr is not ready for review yet.


Fix CLI to not accept gzip responses for streaming get requests

Fixes #3222
Commands like kontena service logs -f are broken with Content-Encoding: gzip, because the response_block gets the raw gzip response data: https://github.com/kontena/kontena/pull/3241#issuecomment-363033113

Merging to original PR


Refactors

Added full attention scores + some memory optimization for kvcache + other minor things

did a bit more cleaning, most major is factoring generate out of main and factoring initialize out of generate. they have different logic so easier to debug this way.

@hallucinomeny since this PR looks like it's ahead in the queue of my https://github.com/xjdr-alt/entropix/pull/40 and you also "lift" the generator function out of main, would you be open to moving to the dataclass-based impl I have there?
I think that provides better encapsulation and will also play more nicely with the "sampler interface standardization" I have in mind.


docker container status is up but cannot be accessed in browser

Bug Description
I've created a custom docker-compose with this setup:
docs:
    build:
      context: .
      dockerfile: ./docs/Dockerfile
    container_name: docs
    restart: always
    ports:
      - '4045:4567'
    volumes:
      - ./docs/source:/srv/slate/source
    networks:
      - laravel

I also notice that the container is restarted itself at some seconds
Screenshots

Browser (please complete the following information):

OS: Mac OS Catalina
Browser chrome
Version 86

Last upstream Slate commit (run git log --author="Robert Lord" | head -n 1):
(Latest commit in main branch)

solved.
update of my docker-compose:
docs:
    image: slatedocs/slate:latest
    container_name: docs
    restart: always
    ports:
      - '4567:4567'
    volumes:
      - ./docs:/srv/slate
      - ./docs/build:/srv/slate/build
      - ./docs/source:/srv/slate/source
    working_dir: /srv/slate
    entrypoint: ['/srv/slate/slate.sh']
    command: ['serve']


BatchNormalization calculates batch mean and variance even in inference mode

I'm not completely confident in the issue title, but I find it plausible and would love it if someone from the keras community helped verify/fix the issue.
Here's the steps to reproduce:

Build any model with one or more batch norm layers.  In my case it was a functional API model, although I doubt that is necessary to reproduce.
run model.predict() (wrap it in a timer of some sort)
At normalization.py:174 (as of master) add training=True
run model.predict()
observe that the model runs significantly faster.  For my model I get about a 3X speed increase.

Investigating a bit more, I think I understand what's going on.  At the end of BatchNormalization.call we return a K.in_training_phase which basically does a tf.cond() on the training phase to use either the training mode batch norm or the inference batch norm.  Tensorflow executed both branches, so even though the calculation is correct, we end up calculating the mean and variance even in inference mode.
Does that make sense?  Any thoughts on a solution?

This is as designed (by TF). So I don't think we can avoid it.
Ref : https://github.com/tensorflow/tensorflow/issues/10800

I think I agree that it can't be avoided from a tensorflow perspective if tf.cond is used (although I'm not an expert on TF graphs, so who knows?)  But regardless, there's already logic in BatchNorm to short circuit the moments calculation if you pass training=False as an argument.  That's pretty awkward, however.  In my case I end up doing something along the lines of ```
prev = BatchNormalization()(prev, training=training)
where training is a global I manage.  It seems like there's got to be a better way, and if there's not, at the very least I would expect the documentation to be modified to warn the users about the overhead in inference mode and the way to avoid it.


Rating system validation

Notes

Add Rating System validation according to acceptance criteria

Testing

By unit tests to make sure the assertions are working correctly
Closes #86

oops realized names must be alphanumeric and contain space and hypens too


Airgap HA - failed to upgrade k8s of existing cluster

What kind of request is this (question/bug/enhancement/feature request):
BUG
Steps to reproduce (least amount of steps as possible):
case 1:

run Rancher:v2.1.7 in airgap environment
add a custom cluster with k8s v1.12.6
upgrade Rancher to v2.2.0-rc6
upgrade the existing cluster's k8s to v1.13.4

case 2:

on the upgraded Rancher, add a new cluster with k8s v1.12.6
upgrade the cluster's k8s to v1.13.4

Result:
Cannot pull images from the private registry
existing cluster:

newly-added cluster

Other details that may be helpful:

provisioning new cluster works
only meet the problem when upgrading k8s version

Environment information

Rancher version (rancher/rancher/rancher/server image tag or shown bottom left in the UI): v2.2.0-rc6
Installation option (single install/HA): airgap HA

Cluster information

Cluster type (Hosted/Infrastructure Provider/Custom/Imported): Custom
Machine type (cloud/VM/metal) and specifications (CPU/memory):
Kubernetes version (use kubectl version):

Client Version: version.Info{Major:"1", Minor:"12", GitVersion:"v1.12.6", GitCommit:"ab91afd7062d4240e95e51ac00a18bd58fddd365", GitTreeState:"clean", BuildDate:"2019-02-26T12:59:46Z", GoVersion:"go1.10.8", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"12", GitVersion:"v1.12.6", GitCommit:"ab91afd7062d4240e95e51ac00a18bd58fddd365", GitTreeState:"clean", BuildDate:"2019-02-26T12:49:28Z", GoVersion:"go1.10.8", Compiler:"gc", Platform:"linux/amd64"}

Docker version (use docker version):

Client:
 Version:           18.06.1-ce
 API version:       1.38
 Go version:        go1.10.4
 Git commit:        e68fc7a
 Built:             Fri Jan 25 14:33:54 2019
 OS/Arch:           linux/amd64
 Experimental:      false

Server:
 Engine:
  Version:          18.06.1-ce
  API version:      1.38 (minimum version 1.12)
  Go version:       go1.10.4
  Git commit:       e68fc7a
  Built:            Thu Jan 24 10:56:33 2019
  OS/Arch:          linux/amd64
  Experimental:     false

@jiaqiluo @sangeethah can you check if the root cause is similar to https://github.com/rancher/rancher/issues/18964 as Private Registry's Password field is of type Password similar to S3.Password: https://github.com/rancher/types/blob/master/apis/management.cattle.io/v3/rke_types.go#L79
Steps to check:

Create a new cluster with a private registry password set. Check cluster crd using kubectl to make sure the private registry's password was set as a field
Update the cluster to a new k8s version. Check cluster crd using kubectl, check if the password field is still there. If it gets reset, then the issue's root cause is the same as in 18964

@alena1108 yes, we can confirm that the root cause is the same as #18964

Here is the output from kubectl about the private registry of the cluster
> kubectl get cluster c-kx2v2  -o json | grep -C 5 private
                "options": {
                    "flannelBackendType": "vxlan"
                },
                "plugin": "canal"
            },
            "privateRegistries": [
                {
                    "isDefault": true,
                    "url": "ec2-52-53-129-105.us-west-1.compute.amazonaws.com:443",
                    "user": "user1"
                }
--
                            "controlplane"
                        ],
                        "user": "root"
                    }
                ],
                "privateRegistries": [
                    {
                        "isDefault": true,
                        "password": "pasword2019",
                        "url": "ec2-52-53-129-105.us-west-1.compute.amazonaws.com:443",
                        "user": "user1"
--
                            "controlplane"
                        ],
                        "user": "root"
                    }
                ],
                "privateRegistries": [
                    {
                        "isDefault": true,
                        "url": "ec2-52-53-129-105.us-west-1.compute.amazonaws.com:443",
                        "user": "user1"
                    }

The fix is validated on Rancher: 2.2.0-rc7
case 1:

run Rancher:v2.1.7 in airgap environment
add a custom cluster with k8s v1.12.6
upgrade Rancher to v2.2.0-rc7
upgrade the existing cluster's k8s to v1.13.4

case 2:

on the upgraded Rancher, add a new cluster with k8s v1.12.6
upgrade the cluster's k8s to v1.13.4

Result:
Both clusters get upgraded successfully.


feat(windows): add Event::DecorationsClick

What kind of change does this PR introduce?

[ ] Bugfix
[x] Feature
[ ] Docs
[ ] New Binding issue #___
[ ] Code style update
[ ] Refactor
[ ] Build-related changes
[ ] Other, please describe:

Does this PR introduce a breaking change?

[ ] Yes, and the changes were approved in issue #___
[ ] No

Checklist

[ ] When resolving issues, they are referenced in the PR's title (e.g fix: remove a typo, closes #___, #___)
[x] A change file is added if any packages will require a version bump due to this PR per the instructions in the readme.
[ ] I have added a convincing reason for adding this feature, if necessary

Other information

Tauri needs this event to focus the webview when the user clicks on the window decoration to fix the issue of  elements not being moved when the window is moved.


Typographic amendments

Some typographic errors have been identified in the Code and will be corrected. We will also update the contact email address throughout the Code to<EMAIL_ADDRESS>

To be included:

membership requirement for registry listed in 9.5 as well as appendix c
notification of migration for 3rd parties
inclusion of any parent info necessitates parent_data_type
bots which aren't in the list must be excluded anyway
extreme circumstances audit extensions


Added REALiX.HWiNFO v7.04

[X] Have you signed the Contributor License Agreement?
[X] Have you checked that there aren't other open pull requests for the same manifest update/change?

[X] Does your manifest conform to the 1.0 schema?

Note: <path> is the name of the directory containing the manifest you're submitting.

Microsoft Reviewers: Open in CodeFlow

/azp run

@msftrubengu i think the bot might be having a bad day 🤔

/azp run

/azp run


One of the file writes was missing a Directory.Create()

generate-include-scripts used ToLowerInvariant() on the full path name which caused issues in Linux that wouldn't appear in Windows. Though apparently wasn't an issue on Macs? not sure why that would be, I don't have a mac.

At first I thought the issue was the lack of Directory.Create() before File.WriteAllText for some files, but turned out this wasn't the issue due to file creation order meaning the directory was actually already there.

Regardless I changed it so in the function to write fsharp scripts it does a Directory.Create immediately before writing, which makes the functions to create fsharp and csharp scripts more consistent, and I think it's less confusing

The Linux CI build is broken because of an issue with the .NET Core build, I have the same  problem locally

thanks!


Incorrect data attribute in export function in example

https://github.com/substance/examples/blob/master/converter/TodoHTMLConverter.js
it should be data-done instead of done in
export: function(node, el, converter) {
    el.append(converter.annotatedText([node.id, 'content']))
      .addClass('todo')
      .attr('done', node.done ? '1': '0');
  }

Thanks we will fix this in the Notes app, as we removed the notepad from the examples repo.

Well actually we don't have HTML serialization there. ;) But thanks anyway for reporting.


Resizable Console

The main intention is to fix #30 by making the LaTeXTools console resizable.
There is a functional change as it is now harder to append text to an existing line (it wouldn't be impossible to do, but I haven't implemented that feature here), which means I've dropped the br optional argument.
I also modestly changed how the console is styled. It's now using CSS properties, which has the advantage that the console can be styled any way the user likes using their own style-sheet.
In addition, addContent now uses the built-in error and warning colours, so errors and warnings should stand out a bit more in the log.
I think atom-message-panel is lightweight enough to be worth considering. It's main dependency is space-pen, which the plugin already uses.

This is great, thanks @ig0774 ! My only concern is that I was actually planning to remove the dependency on atom-space-pen, in the hope of speeding up the ref/cite panel. It's also a pretty hefty requirement, as it pulls in jQuery (I think). Actually, that was the main reason space-pen was removed from atom-core.

...though I have to say, this looks very beautiful!

@msiniscalchi: It turned out to be not so difficult to convert this over to a completely space pen-free solution that I'm actually happier with, which is now what this PR is.
Re the ref / cite panel, isn't most of the delay due to using the onDidStopChanging event? At least on my (non-slow) computer, the delay seems to be the 300ms delay. If I turn off the complete-as-you-type bit and just use the key binding it seems to be almost instantaneous. But maybe I'm missing something?

Awesome!!!! Merged. I noticed there is an issue with jumping to errors/warnings, but I'll look into it.
It does look very spiffy!

OK, don't have time right now, but there is a somewhat serious issue: jumping to warnings/errors doesn't work. With texlive, when I click on a warning/error, a new file is opened. The reason is that texlive's tex log uses relative paths to tex files. This is what gets passed to atom.workspace.open.
In the new code, this happens in LTConsoleMessaveView::gotoMessage. In the previous code, this happened directly in the builder code. I think that the reason things worked there is that, before running latexmk or texify, we chdir to the directory containing the tex (root) file. Then, atom.workspace.open interprets paths as being relative to that, and everything works. [In particular, since the callback was given to addContent using =>, everything happened in the scope of the builder code, so the current  directory was indeed set correctly.]   In the new code instead the binding happens elsewhere, and the current directory is set to .atom/latextools. Indeed, if I have an error in a file called file.tex, the file that Atom tries to open is .../.atom/latextools/file.tex.
It's a subtle bug. Unless I am missing something, I am afraid the only fix is to pass the directory of the tex master file in the call to addContent, which is somewhat unsightly.
That said, I do love the new look!

Well, I fixed it (I think) by passing the dir.

That's bizarre. I was a bit worried about passing the relative path just because of such things but it worked for me, so I didn't really dwell on it.
Something that might be midly cleaner is to create the absolute path in the builder and pass that to the console as the file (the file parameter is just used to create the clickable link; the text itself is separate), but either way it works. Now I'm stuck wondering what about my setup makes things different. Oh well.

Oh... I didn't notice that the message was a separate argument---mine was a really quick fix done before running to a seminar...
Then the right thing to do is definitely to pass the full path as the file parameter. Actually, separating the file name and absolute path would be useful to support the option to put output (or auxiliary) files in a separate directory, which is something many users on Sublime Text have asked for.
BTW, miktex uses absolute paths in error logs. Also, there may be differences across different texlive versions---I"m using the 2014 version (I think). THis may explain why you didn't see it on your machine.

Pushed the change.

...and Win32 required another fix. Actually, the issue was that, if we have absolute paths, we must not prepend the directory. Hope it all works now!


Remove the Done trait, rename DbDone to DbOutcome

As dicussed on Discord (discussion started here).

After much deliberation, we decided to go with DbQueryResult to make this very obvious what it is - if a bit wordy.
Reasons:

Nearly every db library calls this type Result, SqlResult, or some variation on that
std has examples of XResult types not being Result<T, Error> aliases

After much deliberation, we decided to go with DbQueryResult to make this very obvious what it is - if a bit wordy.
Reasons:

Nearly every db library calls this type Result, SqlResult, or some variation on that
std has examples of XResult types not being Result<T, Error> aliases


Incremented version to 1.2.3.

Coming from https://github.com/opensearch-project/opensearch-build/issues/1365.

This was done through some primitive automation. Almost identical to https://github.com/opensearch-project/security/pull/1531 minus the release notes, so will close.

Codecov Report

:exclamation: No coverage uploaded for pull request base (1.2@3c67ec1). Click here to learn what that means.
The diff coverage is n/a.

@@          Coverage Diff           @@
##             1.2    #1532   +/-   ##
======================================
  Coverage       ?   64.88%
  Complexity     ?     3229
======================================
  Files          ?      247
  Lines          ?    17335
  Branches       ?     3072
======================================
  Hits           ?    11247
  Misses         ?     4532
  Partials       ?     1556

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 3c67ec1...e37f4c1. Read the comment docs.


Stretch is not working as expected in JS build and Playground.

Report
align-items when set to stretch is not working as expected in JS build and Playground.
✅ I have searched existing issues and this is not a duplicate
Issues and Steps to Reproduce

Visit the Yoga layout playground
Configure a root element taller than child nodes
Set align-items to stretch

Expected Behavior
The height of the child nodes would change to fill the height of the parent container.
Actual Behavior
The height of the child nodes remains the same.
Link to Code
I'm working on an implementation of Yoga to drive layout for prototypes in FramerJS. I'm using a JS build.
Code doesn't work, nor does it work in the playground:

Thanks!

Coming here after having experiencing the same issue, 3 years later. Did you happen to find a fix/workaround for this by chance? I've tried with align-self on the children, that also does not work. The only thing that did work was setting up the height of the elements to a fixed px value, but that only works if the height of the parent is known ahead of time so not good for some use cases.

Old playground might be giving children definite height. Does not repro currently: https://www.yogalayout.dev/playground?code=DwGQhgng9grgLgAgMZQHYDMCWBzAvAb3xgGcBTAdVICMARU9MGAGzmIC4E4AnGUgXz4A+AFAIEwAHJQAJqVFiExOBCakC+eQoQB3TNLgALDgCYADKYA0mhQdI4DcEwFZL1sQAcw06ZlTYOAIyuWmJgTDioAJJwpAC27AgA5EpcpHBIBolWWgIiWpIyciGKyqrqbgqxYFzYvhxO2cU6eob1wSEC1gD0eQoFsiUqaoRVNXUIDQi29o4Tls36RnMCCD3ywF1SsiIb4NDwgkA


Make TagIter use explicit lifetimes

This is a move away from the many 'static lifetimes, as proposed in issue #22.
Small question regarding the specific implementation:
I made the phantom field of TagIter public, because a TagIter is constructed in src/lib.rs and I didn’t want to introduce a TagIter::new() method without approval. I don’t know which is better style here: making phantom public, as done in this PR, or make a new() function.

Been a while. Is this pull request still useful?

(Note that I mostly forgot the specifics)
I think the point about using less 'static still stands. Issue #22 doesn’t seem to have advanced.
To start a little bikeshedding, I think (now), that an fn new(…) would be appropriate.
I haven’t yet looked over the current state of the codebase and the changes in the last 2 years.
If you’d like, I can take the time and adapt the patch to resolve the conflicts.

That would be hugely helpful @Columbus240

Closing this PR in favor of a new one, because in the mean time, I deleted my fork on GitHub and can’t access this branch anymore.


Choose default calendar app

Is there a way to change the calendar app that an event opens. Right opens samsung calendar would like to change to google.

Hi @fortewu
Please note that the "calendar-widget" app is replaced by the "ToDo Agenda" app (see https://github.com/andstatus/todoagenda#readme )
The problem that you encounter is discussed in this issue: https://github.com/andstatus/todoagenda/issues/23


feat: Adding a image generation notebook example for Imagen

Opening a PR for generative-ai/vision/getting-started. Adding a new getting started sample notebook for Imagen for Image Generation. This example provides a complete end to end example using the preview Vertex AI SDK for image generation. Once ImageGenerationModel module from the Vertex AI SDK is GA will provide an updated sample.
Confirmed that this example passes required code quality checks documented in CONTRIBUTING.md
Checklist

[ X ] Passes all the required formatting and linting checks. You can locally test with these instructions.

Thanks for the PR. We have scheduled to release image generation, editing, and tuning notebooks. Could you may be create an end-to-end gradio notebook?

Hi @iamthuya updated the PR with a end to end gradio notebook instead: vision/gradio/gradio_image_generation_sdk.ipynb


Design Changes

with Repldex 3 coming, i would like to add some design changes to the application. we will still be using a WebView, but it will be customized to allow themes (which will be customizable in new Settings page). the plan is to just inject the theme data into the website's css variables. these changes will also be adding a Custom Scrollbar and adding a loading animation (on page load, including entry pages). for Security purposes, i will be making it so it will ask you if you'd like to be Redirected to the page if you click on a link that isn't on the Repldex or Replit domain. if you have any ideas, please send a comment down below 😇
Sincerely, selectthegang

This has been added into the application, will be released soon after testing >3


Add Cache option #1573

Add a new entry "cache" to the options object that is passed to the worker

Enable prompt cache #1573

Just tried this out with mixtral:8x7b-instruct-v0.1-q4_K_M, which is one of the problematic models for me. Testing via mixtral run and enabling via /set cache, it really seems to work. There is almost no delay before the generation starts, even when the context is getting bigger.
You can also see in the stats that the prompt eval count stays very low after each prompt, hinting to the fact that only newly added tokens were being evaled.
BUT, this seems to only work as long as there is a single session going on. As soon as you run a prompt in a second session, the cache seems to have gone. The cache seems to only affect the last prompt that was handled.

I think we can merge this, and tackle the further caching improvements in another PR.
If I see this correctly we need to patch this into the llama.cpp server, so we maybe be able to upstream the changes, so I'm not sure if this is even an issue we should solve here.

@BruceMacD resolved issues, I force pushed to clean up (Squash and amend) commits.

in my testing (with the default prompt from api docs)
curl http://localhost:11434/api/chat -d '{
  "model": "llama2",
  "messages": [
    { "role": "user", "content": "why is the sky blue?" }
  ], "stream": false, "options": { "num_predict": 10 }
}' | jq .prompt_eval_duration

On 100 runs, the second call took:
Average response time: 324024010 seconds  (11x faster then first run)
Median response time: 331100000 seconds  (11x faster then first run)
Highest 1% response time: 400641000 seconds  (10x faster then first run)
On 100 runs, the first call took:
Average response time:<PHONE_NUMBER> seconds
Median response time:<PHONE_NUMBER> seconds
Highest 1% response time:<PHONE_NUMBER> seconds
I'm running on wsl2 with a ryzon 3800x in cpu

Hi folks, I've changed this to always be on. Would love to know if there's a reason we should ever consider having it off (memory usage, prompt leakage?). I haven't seen any issues but do let me know.

Hi, no since it only caches the last, prompt anyway, there should be no issue with memory.
In my testing, I did not find any memory issue.
I only added the flag since I didn't know if it was acceptable to keep state in the backend.

@jmorganca I'm working on a patch for the llama server to allow us to return cached state over the API (like the context object), so maybe we can introduce this flag again later on :).

@K0IN excited to see how we can improve with even better caching. And of course, I forgot to mention: thanks so much for the PR!!

Is there a way to turn prompt caching off via api for benchmark purpose?

How can the cache-option be activated?

Prompt caching is great to have but I think in addition to that let not couple everything with caching such as tools. Woul be nice if we could define tools much like a dataset and initialize the model with tools. Then it does not need to be with caching because tools should not change.


Firefox API

I think firefox still uses the old API: navigator.getVRDevices, so VRDisplay is not defined in Firefox.
Otherwise its working great again, thank you very much!

We can close this one now, since Firefox supports WebVR 1.0


Video/Gif editor

Add a basic video/gif editor with support for trimming.

Looking forward to a quality video editor in Aves when he gets to it. However, this app doesn't collect personal info and is powerful video editor. Give it a try!
https://apkcombo.com/img-ly-photo-video-editor/com.photoeditorsdk.android.app/


Moving a workspace to a new output results in the windows on it being invisible, rendering the previously visible window of that output, or flickering

Hyprland Version
 System/Version info
Hyprland, built from branch main at commit b7d71bc0e1084bc1a296ae906503709a74fde4d9 dirty (keybinds: fix spammy warning).
Date: Thu Apr 4 11:16:47 2024
Tag: v0.38.0-23-gb7d71bc0

flags: (if any)

System Information:
System name: Linux
Node name: milkbar
Release: 6.8.2-arch2-1
Version: #1 SMP PREEMPT_DYNAMIC Thu, 28 Mar 2024 17:06:35 +0000

GPU information:
0b:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Navi 10 [Radeon RX 5600 OEM/5600 XT / 5700/5700 XT] [1002:731f] (rev c1) (prog-if 00 [VGA controller])
0c:00.0 VGA compatible controller [0300]: NVIDIA Corporation TU104 [GeForce RTX 2070 SUPER] [10de:1e84] (rev a1) (prog-if 00 [VGA controller])

os-release: NAME="Arch Linux"
PRETTY_NAME="Arch Linux"
ID=arch
BUILD_ID=rolling
ANSI_COLOR="38;2;23;147;209"
HOME_URL="https://archlinux.org/"
DOCUMENTATION_URL="https://wiki.archlinux.org/"
SUPPORT_URL="https://bbs.archlinux.org/"
BUG_REPORT_URL="https://gitlab.archlinux.org/groups/archlinux/-/issues"
PRIVACY_POLICY_URL="https://terms.archlinux.org/docs/privacy-policy/"
LOGO=archlinux-logo

Bug or Regression?
Bug
Description
As described in the title, sometime in the last few commits (fc0a7af did not exhibit this bug), whenever I move a workspace across output I get rendering issues until I change to another workspace on that output and back again.
How to reproduce
Issue movecurrentworkspacetomonitor <direction> with multiple outputs.
Crash reports, logs, images, videos
No response

347b83903474ab9e95fa9d4ba123f6f78ab38d40 is the first bad commit

patch.txt
try this

Above patch fixes the problem.


gets slow with larger text bodies

with something like man less | xsticky it slows down considerably, probably because it's drawing all the text, even that not visible

current plan:

render the whole corpus to a pixmap
window and scroll serve as a viewport to said back buffer, which is trivially copied

fixed in d1cb6e7


Sg/record tx

removed certification verification ( temporary )
added digest insertion of whole Block1

# Environment is used to prefix logs, database collections, and Pulsar topics.
env: dev

# Sui network.
net: mainnet

# Location of RocksDB file used in backfill mode. Be sure this directory has been created with correct permissions on your system.
rocksdbfile: /tmp/backfill.tmp.db

# Number of checkpoints we need to be behind to change into backfill mode.
backfillthreshold: 3

# Determine if we want to stop indexing the latest checkpoints while backfilling.
pausepollonbackfill: false

# Frequency at which we check for a new checkpoint on the Sui blockchain. Each interval will invoke an RPC call.
pollintervalms: 100

# Toggle backfill-only mode.
backfillonly: false

# Toggle livescan-only mode.
livescanonly: true

# Start the backfill from this checkpoint and work backward in time. Loaded into app as u64. Ignored if backfillonly is false.
backfillstartcheckpoint: 20319270

# These settings determine how aggressively we hammer RPC and MongoDB while backfilling Sui data. These settings are active when we are behind by backfillthreshold number of checkpoints.
backfill:
  queuebuffers:
    # 1024 * 1024
    checkpointout: 8 # The bounded capacity of the async channel which passes messages between checkpoint workers and object workers in backfill mode.
    cpcompletions: 8 # The bounded capacity of a synchronous Tokio channel which handles backpressure between checkpoint workers and object workers. This is the maximum number of pending objects requiring RPC lookup after being scanned from a checkoint scan.
    mongoinfactor: 1 # Multiplier used for a bounded Tokio channel which passes full Sui objects to the MongoDB writer channel. This value is multiplied by mongo.batchsize to determine the upper bound on the channel.
    last: 1
  workers:
    checkpoint: 16 # Determine the number of Tokio threads issuing RPC calls for checkpoint data.
    object: 32 # Determine the number of Tokio threads issuing RPC calls for full object data. Keep in mind that we use sui_multiGetObjects(), so there are many objects fetched on each invocation.
    mongo: 6 # Determine the number of Tokio threads issuing CRUD operations to MongoDB. Keep in mind that we batch these queries based on config below.
  objectqueries:
    batchsize: 50 # Determine the number of Sui objects to fetch in a single sui_multiGetObjects() request.
    batchwaittimeoutms: 1000 # Determine interval for issuing sui_multiGetObjects() request.
  mongo:
    batchsize: 4096 # Determine the number of CRUD operations to issue to Mongo at each interval.
    batchwaittimeoutms: 1000 # Determine the time between batched MongoDB operations.
    retries: 4 # Determine the number of retries for MongoDB operations before dropping queries.
    zstdlevel: 5 # MongoDB compression setting for on-wire data. See: https://www.mongodb.com/docs/manual/reference/glossary/#std-term-zlib
  checkpointretries: 32
  checkpointretrytimeoutms: 500
  tracklatency: false

livescan:
  queuebuffers:
    checkpointout: 2 # The bounded capacity of the async channel which passes messages between checkpoint workers and object workers.
    cpcompletions: 2 # The bounded capacity of a synchronous Tokio channel which handles backpressure between checkpoint workers and object workers. This is the maximum number of pending objects requiring RPC lookup after being loaded from a checkpoint scan.
    mongoinfactor: 1 # Multiplier used for a bounded Tokio channel which passes full Sui objects to the MongoDB writer channel. This value is multiplied by mongo.batchsize to determine the upper bound on the channel.
    last: 1
  workers:
    checkpoint: 4 # The number of checkpoint workers used in livescan mode. Not used in backfill mode.
    object: 8 # The number of object workers used in livescan mode. Not used in backfill mode.
    mongo: 2 # The number of MongoDB workers used in livescan mode. Not used in backfill mode.
  objectqueries:
    batchsize: 50 # The number of objects to request in each sui_multiGetObject() RPC invocation.
    batchwaittimeoutms: 10 # Interval between sui_multieGetObject() RPC invocations.
  mongo:
    batchsize: 1024 # The number of objects updates sent on each batched Mongo operation.
    batchwaittimeoutms: 10 # The interval between batched Mongo operations.
    retries: 4 # The number of retries before a Mongo operation fails.
    zstdlevel: 1 # On-wire MongoDB compression setting. See: https://www.mongodb.com/docs/manual/reference/glossary/#std-term-zlib
  checkpointretries: 8 # Maximum retries to fetch an individual checkpoint. App will panic if this is exceeded.
  checkpointretrytimeoutms: 250 # Interval for checkpoint fetches.
  tracklatency: true

mongo:
  # you need to set this via ENV as it's the only way to set your credentials if we don't want to keep them in this file
  # uri<EMAIL_ADDRESS>(example for Atlas Cloud).
  uri: mongodb://sui-mainnet:sui-mainnet@<IP_ADDRESS>:27017 # Example for localhost setup
  db: sui-mainnet # The name of the MongoDB database. We recommend separate databases or separate MongoDB clusters for each environment.
  collectionbase: objects # The prefix for the MongoDB collection. Turns into: format!("{}_{}_{}{}", cfg.env, cfg.net, cfg.mongo.collectionbase, suffix)

# Example Pulsar credentials for StreamNative Cloud.
pulsar:
  url: pulsar://localhost:6650
  issuer: https://auth.streamnative.cloud/
  credentials: file:///home/sudip/Projects/apache-pulsar-3.1.2/pulsar-credentials.json
  audience: urn:sn:pulsar:o-mvqin:nonprod
  topicbase: persistent://public/default/

influx:
  database: suibucket
  url: http://<IP_ADDRESS>:8086
  token: V47ACv4TeYxuqjlzChkMu30nmeRXgoRlR9Q3Zb4be7DYtkVGSprPFhEL4gg2Msu_dADRpdqYfxbueJuJ4N_5Bw==

# RPC credentials. Each network can take one or more entries to facilitate round-robin RPC invocations.
# Only the active network config will be used. "net" in this file.
sui:
  mainnet:
    - url: https://sui-mainnet.blastapi.io:443/d630037c-3f96-47c3-b39b-9b4c85bcd939
      name: ibriz-infra-node
      objectsquerylimit: 50
  testnet:
    #    - url: https://rpc-mainnet.suiscan.xyz:443
    #      name: suiscan
    #      objectsquerylimit: 50
    - url: http://<IP_ADDRESS>:9000
      name: huracan-mainnet
      objectsquerylimit: 50
  localnet:
    - url: http://<IP_ADDRESS>:9000
      name: sui-test-validator
      objectsquerylimit: 50
# Package IDs to exclude from indexing. You can copy/paste this from the Sui explorer or program logs.
# Leaving this and the whitelist disabled will index everything.
blacklist:
  enabled: false
  packages:
#    Example:
#    - 0x2::coin::Coin<0x2::sui::SUI>

# Package IDs to include in indexing. You can copy/paste this from the Sui explorer or program logs.
# Leaving this and the blacklist disabled will index everything.
whitelist:
  enabled: false
  packages:
#   Example:
#    - 0x2::coin::Coin<0x2::sui::SUI>
log:
  tokioconsole: false
  # Valid options are "logfile" or "stdout".
  output: logfile
  # Be sure to set up logrotation on your server.
  # If you are using our automation repo, this is the location Fluent-Bit is configured to forward logs from.
  logfilepath: "/tmp/indexer.log"
  level: info
  # Add filters here.
  # my_crate=info,my_crate::my_mod=debug,[my_span]=trace
  # see https://tracing.rs/tracing_subscriber/filter/struct.envfilter
  # filter:

nothing has been changed in the config file right?


ble_cmd_gap_end_procedure fails to stop when in scanning mode

Great lib btw. I ran into one major issue so far though. I can get everything working except terminating a scan in BGLib_scanner.ino (your included demo). It scans fine, etc. but pressing 2 a second time just seems to die (the call seems to go out, but no return) The scan keeps going, but there seems to be no way to stop it.
The only mod I made was changing the BLE_WAKEUP_PIN to match my wiring, and setting Serial to 38400 (I'm running on a 8mhz chip)
I was able to get the peripheral setup 100% working, paired to another BLE device, etc.

I've found the same behaviour using the Python API.
It appears that the end procedure is sent to the BLE module, but it doesn't get round to processing it until several seconds later. I presume this is due to scan response packets continuing to come in, and that they're processed with a higher priority than API commands.
I've had to change the API such that it waits for the ble_rsp_gap_end_procedure response after sending the command. It means the timeout doesn't work though (so the scan period is variable).

I think I've run into a similar issue. I terminate the scan automatically if there is no response for a while. The terminate seems to be fine ( I get an end_procedure response), but cannot reinitiate a scan (set_scan_parameters & gap_discover) - I don't get back responses from those calls.


Fixed namespace error

Changed ScansionGreek to Scansion, all ten prosody tests run OK.

I fixed this name myself, briefly before you submitted this PR. Closing w/o merge. Thx, KJ


Transaction priority slider changes

Changes to transaction priority slider,
Design suggestions are still under development - 18/07
https://xd.adobe.com/view/181f3fd2-7aca-4284-61c7-3417e1fe6d8a-6e2e/screen/6f46bd3f-2538-4cf2-abd2-8932cf0e32fa/

@hemantsain
Send screen changes for priority slider
confirmation screen
https://xd.adobe.com/view/00485057-d5b7-4b2b-641b-20216b3a38d5-7679/screen/da3e0887-326a-4cc1-8b1d-38d023ef69ec/specs/


Fix Raksh key handling

Currently Raksh key handling is broken.
The updated key handling doc is available here

https://github.com/IBM/raksh/pull/16

Fix merged


support: add dep for L Market app

📝 Description
Add dep between plugin and Ethereum app
❓ Context

Impacted projects: L Market
Linked resource(s): None

✅ Checklist

[ ] Test coverage  n/a
[x] Atomic delivery yes
[x] No breaking changes no breaking changes

📸 Demo
n/a
🚀 Expectations to reach
n/a

How to test this? Someone must confirm/verify the string is at least exactly that, exact at the character (like if there are an extra space, it's not going to work)


add IntrusiveList

I confirm that this contribution is made under the terms of the license found in the root directory of this repository's source tree and that I have the authority necessary to make this contribution on behalf of its copyright owner.
@havardpe for discussion

@arnej27959 Is this still ongoing, or should it be closed ?


Strange white line under status bar

In the maximized vscode, look at the bottom line of pixels, white in the right side, and black in the left side.
If move mouse over 2 days ago, then the white pixels is a little longer.

VSCode Version: 1.11.0
OS Version: Ubuntu 16

Steps to Reproduce:

Maximize vscode (Note: full screen F11 is okay, a continuous white line shows up)
look at the screen bottom

BTW, if there is a choice, I prefer this bottom line of pixels be black :)

@Tyriar do you see this too?

@bpasero nope. Maybe it's the Chromium glitch where the tooltip shows up in white/black?

@innerlee you see this white line all the time right, not just when hovering down there?

Yes. Hovering or not just changes the length of white lines. In full screen mode, the screen bottom is a line of white pixels.  And varies if i hover over some element in status bae or not.
Another detail: when code starts, the bottom is white line, then the middle part becomes black. Then after ui elements loaded, the white grows, and black becomes shorter.
more picutures:
window mode:

full status bar in max mode:

@innerlee do you set the zoom level in settings to any value?

I find this interesting.
black: menu hide, setting page

white and black: menu hide, normal files

white: menu hide, normal files, developer tools open

black: menu shown

zoom leve: state
0, 2, 4: black
-1, 1, 3: black & white

Ok so this is zooming related.

@bpasero I see this very often and I have zoom at 0 always.

This happens when the 'counter' span is sized to a certain fractional width depending on its contents, and is at a certain position depending on what precedes it in the status bar. I think it's a rounding error somewhere. Giving the counter span a whole number width fixes it for me. Spent some time working that out but I also see that it appears to be fixed with 3.0.

Also seeing this. If I change the "Python 2.3.2 64-bit" string (in developer tools) to "Python 2.3.1 64-bit" (which is slightly narrower) it goes away. Seems like it's coming from the warning icon element because toggling it's background: style makes it go away (while also making the icon itself go away).

I investigated this last month and found that it was due to a rounding issue in the widths of the status bar items + the -webkit-mask but it's fixed in electron 3 so not worth working around it.


Forwarding via flat-buffers not working.

I have NG built from a recent commit #4c0c102 (10/11/2019) on a Vero4K (OSMC) and an RPi3 (RaspbianLite)
Platform capture works on both devices and can be seen in the webGUI live preview.
On the Vero4K I have "forwarder" activated, with the "JSON target" and "flatbuffer target" set to the IP address of the RPi3 and the default ports.
Debug output is:
[hyperiond JSONSERVER]  Started on port 19444
[hyperiond FLATBUFCONNECTION]  Connecting to Hyperion: <IP_ADDRESS>:19401
[hyperiond NETFORWARDER]  Forward now to json targets '<IP_ADDRESS>:19446'
[hyperiond NETFORWARDER]  Forward now to flatbuffer targets '<IP_ADDRESS>:19401'
On the RPi3 I have "Flatbuffers Server" and "Protocol Buffers Server" activated, set to the same ports as above.
Debug output is:
[hyperiond JSONSERVER]  Started on port 19444
[hyperiond FLATBUFSERVER]  Started on port 19401
[hyperiond PROTOSERVER]  Started on port 19446
So how should I see the Vero4K forwarded onto the RPi3?
I assumed there would be an option in the RPI3 "remote control" to select the Vero4K as a source, but I only have the usual:
System Platform Capture: (Dispmanx)
System Effect: Warm mood blobs
It is unclear if this is a bug or operator error.
Is there something else I should be doing?
Many Thanks,

@hissingshark your ports for json and proto are somehow wrong... (json target should be 19444 for you)
Anyway, I have the same problem. The only way to make the flatbuffer forwarder work, is to change the port on sender side to something "wrong" and save settings. Then back to correct port and save. This enables the forwarding and also lights up the leds.
Disable (save) enable (save) the forwarding switches it off and requires the above steps to enable it again.
Both instances are running latest (today) source
Could this be a config issue?

@gismo2004 thanks for your feedback.
I've tried setting Flatbuffer Target 1 to <IP_ADDRESS>:19400 but no change.
Unfortunately I've not been able to reproduce your fix of wrong/right settings.  Or at least I think so.
When you have it working do you see something under Source Selection in the Remote Control, so that you can select the forwarded data?

@hissingshark sorry for late response... you know: Christmastime == Busytime :-)
however: yes i see something in SourceSelection of the "server instance". I hope i'll have some time to check this in the next two weeks.
The json forwarder is working as far as i have seen. Is this working for you? (try to load an effect on client and start it...)

@hissingshark one thing i have found out: for making it work for me, I need to switch to a "wrong" port for at least 5s, after that switching back to the correct one, enables the forwarding for me...

@hissingshark i have at least something that works now... I'm sure that my "workaround" is not what @Paulchen-Panther want will use, but for me it is working :-D
I also don't understand how componentStateChanged() should get triggered as its source is never COMP_FORWARDER but i have absolutely no clue how all this stuff "should" work g so i hope paulchen will help to fix it.
check my patch and apply it.
test.zip

I'll take a look at that, thank you.
Still not clear about the settings I need, but if I start from scratch this patch should at least rule out that quirky part.

This still isn't working for me.  I've rebuilt from master on both devices.
@gismo2004 can you confirm this has fixed it for you?  And if so could you share your settings for each device so I can see how they align?  I'm finding the labelling of the settings somewhat confusing to be honest.

@hissingshark i still need my patch (first part) to be able to switch the forwarder off and on via kodi addon! (i don't want to have the lights on when in menu...)
That's my setup:


FIX 4.4: Missing "1" in description of OptAttribute(206)

The description of OptAttribute(206) contains a list of possible values. The last sentence is as follows:
0-9 = single digit "version" number assigned by exchange following capital adjustments (0=current, =prior, 2=prior to , etc).
Add "1" and change as follows:
0-9 = single digit "version" number assigned by exchange following capital adjustments (0=current, 1=prior, 2=prior to 1, etc).

Added to SPEC-1708


Intermittent broken pipe

Bug description
We are seeing
[Envoy (Epoch 0)] [2020-05-27 20:35:08.309][32][debug][http] [external/envoy/source/common/http/conn_manager_impl.cc:452] [C1340] idle timeout
in istio-proxy logs for TCP connections.
[ ] Configuration Infrastructure
[ ] Docs
[ ] Installation
[X] Networking
[ ] Performance and Scalability
[ ] Policies and Telemetry
[ ] Security
[ ] Test and Release
[ ] User Experience
[ ] Developer Infrastructure
Expected behavior
As this is a TCP connection, we shouldn't be seeing these 60m timeouts from what I can see in the documentation - it looks as though the connection is being treat as a HTTP connection.
We upgraded recently from Istio 1.3.6 and we weren't seeing these issues.
Steps to reproduce the bug
Here is the service we're testing against:
kind: Service
metadata:
  annotations:
    service.alpha.kubernetes.io/tolerate-unready-endpoints: "true"
  creationTimestamp: "2020-05-26T07:08:07Z"
  labels:
    app: abc-opensource
    chart: abc-opensource-0.29.0
    heritage: Tiller
    product: redis
    release: abc-redis
  name: abc-redis-opensource-announce-0
  namespace: abc
  resourceVersion: "29305795"
  selfLink: /api/v1/namespaces/abc/services/abc-redis-opensource-announce-0
  uid: e3629883-79fe-4304-8cb1-9b544ed152ad
spec:
  clusterIP:  <IP_ADDRESS>
  ports:
  - name: tcp-server
    port: 6379
    protocol: TCP
    targetPort: redis
  - name: tcp-sentinel
    port: 26379
    protocol: TCP
    targetPort: sentinel
  publishNotReadyAddresses: true
  selector:
    app: abc-opensource
    release: abc-redis
    statefulset.kubernetes.io/pod-name: abc-redis-opensource-server-0
  sessionAffinity: None
  type: ClusterIP
status:
  loadBalancer: {}

Version (include the output of istioctl version --remote and kubectl version and helm version if you used Helm)
client version: 1.5.4
egressgateway version: 1.5.4
ingressgateway version: 1.5.4
ingressgateway version: 1.5.4
ingressgateway-public version:
pilot version: 1.5.4
data plane version: 1.5.1 (32 proxies), 1.5.4 (173 proxies)

Client Version: version.Info{Major:"1", Minor:"16", GitVersion:"v1.16.9", GitCommit:"a17149e1a189050796ced469dbd78d380f2ed5ef", GitTreeState:"clean", BuildDate:"2020-04-16T11:44:51Z", GoVersion:"go1.13.9", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"16+", GitVersion:"v1.16.8-eks-e16311", GitCommit:"e163110a04dcb2f39c3325af96d019b4925419eb", GitTreeState:"clean", BuildDate:"2020-03-27T22:37:12Z", GoVersion:"go1.13.8", Compiler:"gc", Platform:"linux/amd64"}

Client: &version.Version{SemVer:"v2.16.7", GitCommit:"5f2584fd3d35552c4af26036f0c464191287986b", GitTreeState:"clean"}
Server: &version.Version{SemVer:"v2.16.6", GitCommit:"dd2e5695da88625b190e6b22e9542550ab503a47", GitTreeState:"clean"}

The client uses jredis. We see the issue where the client is disconnected from sentinel:
Lost connection to Sentinel at abc-redis-opensource-announce-0:26379. Sleeping 5000ms and retrying.
The issue that is causing us most pain though, is when we ask redis client to make a new request. It seems jredis creates a connection to redis when it starts and then this connection is timed out by istio. This means when any of our apps make a new request to jredis, it doesn't have a connection to redis established and needs to create a new one. We see
redis.clients.jedis.exceptions.JedisConnectionException: java.net.SocketException: Broken pipe (Write failed)","rootCause":"Broken pipe (Write failed)"}]}}

We are seeing similar issues between other apps but finding that harder to replicate.
We weren't seeing these issues on 1.3.6 and we're still not seeing these issues on other clusters running that version
How was Istio installed?
Using operator.
Environment where bug was observed (cloud vendor, OS, etc)
EKS

Could you paste the json output for the listener in question? you can use istioctl proxy-config listeners to get that

    {
        "name": "<IP_ADDRESS>_6379",
        "address": {
            "socketAddress": {
                "address": "<IP_ADDRESS>",
                "portValue": 6379
            }
        },
        "filterChains": [
            {
                "filters": [
                    {
                        "name": "istio.stats",
                        "typedConfig": {
                            "@type": "type.googleapis.com/udpa.type.v1.TypedStruct",
                            "typeUrl": "type.googleapis.com/envoy.extensions.filters.network.wasm.v3.Wasm",
                            "value": {
                                "config": {
                                    "configuration": "{\n  \"debug\": \"false\",\n  \"stat_prefix\": \"istio\"\n}\n",
                                    "root_id": "stats_outbound",
                                    "vm_config": {
                                        "code": {
                                            "local": {
                                                "inline_string": "envoy.wasm.stats"
                                            }
                                        },
                                        "runtime": "envoy.wasm.runtime.null",
                                        "vm_id": "tcp_stats_outbound"
                                    }
                                }
                            }
                        }
                    },
                    {
                        "name": "envoy.tcp_proxy",
                        "typedConfig": {
                            "@type": "type.googleapis.com/envoy.config.filter.network.tcp_proxy.v2.TcpProxy",
                            "statPrefix": "outbound|6379||dds-redis-opensource-announce-0.abc.svc.cluster.local",
                            "cluster": "outbound|6379||dds-redis-opensource-announce-0.abc.svc.cluster.local",
                            "accessLog": [
                                {
                                    "name": "envoy.file_access_log",
                                    "typedConfig": {
                                        "@type": "type.googleapis.com/envoy.config.accesslog.v2.FileAccessLog",
                                        "path": "/dev/stdout",
                                        "format": "[%START_TIME%] \"%REQ(:METHOD)% %REQ(X-ENVOY-ORIGINAL-PATH?:PATH)% %PROTOCOL%\" %RESPONSE_CODE% %RESPONSE_FLAGS% \"%DYNAMIC_METADATA(istio.mixer:status)%\" \"%UPSTREAM_TRANSPORT_FAILURE_REASON%\" %BYTES_RECEIVED% %BYTES_SENT% %DURATION% %RESP(X-ENVOY-UPSTREAM-SERVICE-TIME)% \"%REQ(X-FORWARDED-FOR)%\" \"%REQ(USER-AGENT)%\" \"%REQ(X-REQUEST-ID)%\" \"%REQ(:AUTHORITY)%\" \"%UPSTREAM_HOST%\" %UPSTREAM_CLUSTER% %UPSTREAM_LOCAL_ADDRESS% %DOWNSTREAM_LOCAL_ADDRESS% %DOWNSTREAM_REMOTE_ADDRESS% %REQUESTED_SERVER_NAME% %ROUTE_NAME%\n"
                                    }
                                }
                            ]
                        }
                    }
                ]
            }
        ],
        "deprecatedV1": {
            "bindToPort": false
        },
        "trafficDirection": "OUTBOUND"
    }
]

apologies, I made a mistake in logging the issue. What we're actually seeing is this tcp timout

2020-06-23 14:32:55.339 | [Envoy (Epoch 0)] [2020-06-23 14:32:55.280][35][debug][conn_handler] [external/envoy/source/server/connection_handler_impl.cc:353] [C403] new connection
-- | --
2020-06-23 14:32:55.339 | [Envoy (Epoch 0)] [2020-06-23 14:32:55.280][35][debug][filter] [external/envoy/source/common/tcp_proxy/tcp_proxy.cc:381] [C403] Creating connection to cluster outbound\|26379\|\|dds-redis-opensource-announce-0.rsb.svc.cluster.local
2020-06-23 14:32:55.339 | [Envoy (Epoch 0)] [2020-06-23 14:32:55.280][35][debug][filter] [external/envoy/source/common/tcp_proxy/tcp_proxy.cc:232] [C403] new tcp proxy session
2020-06-23 15:32:56.133 | [Envoy (Epoch 0)] [2020-06-23 15:32:55.284][35][debug][conn_handler] [external/envoy/source/server/connection_handler_impl.cc:86] [C403] adding to cleanup list
2020-06-23 15:32:56.133 | [Envoy (Epoch 0)] [2020-06-23 15:32:55.284][35][debug][connection] [external/envoy/source/common/network/connection_impl.cc:192] [C403] closing socket: 1
2020-06-23 15:32:56.133 | [Envoy (Epoch 0)] [2020-06-23 15:32:55.284][35][debug][connection] [external/envoy/source/common/network/connection_impl.cc:101] [C403] closing data_to_write=0 type=1
2020-06-23 15:32:56.133 | [Envoy (Epoch 0)] [2020-06-23 15:32:55.284][35][debug][filter] [external/envoy/source/common/tcp_proxy/tcp_proxy.cc:597] [C403] Session timed out

and we can't find out how to change this hourly timeout - can't see in destination rule the option to do this.

You can try setting ISTIO_META_IDLE_TIMEOUT env variable to a duration (ie, 24h0m0s) on the Istio-proxy for this workload and that should do the trick. Let me know how that works for you.

Hi,
Thanks for the response. I added the following annotation:
        proxy.istio.io/config: |-
          proxyMetadata:
            ISTIO_META_IDLE_TIMEOUT: 24h0m0s

I tried adding this to the client and server in this scenario and it didn't stop the timeouts.
We have also tried to add this envoyfilter
apiVersion: networking.istio.io/v1alpha3
kind: EnvoyFilter
metadata:
  creationTimestamp: "2020-06-29T09:24:30Z"
  generation: 1
  name: redis-test2
  namespace: abc
  resourceVersion: "54665918"
  selfLink: /apis/networking.istio.io/v1alpha3/namespaces/rsb/envoyfilters/redis-test2
  uid: e7e60a2d-92b1-4b07-93ac-f5677ecbd751
spec:
  configPatches:
  - applyTo: NETWORK_FILTER
    match:
      context: SIDECAR_OUTBOUND
      listener:
        filterChain:
          filter:
            name: envoy.tcp_proxy
        portNumber: 6379
    patch:
      operation: MERGE
      value:
        name: envoy.tcp_proxy
        typed_config:
          '@type': type.googleapis.com/envoy.config.filter.network.tcp_proxy.v2.TcpProxy
          idle_timeout: 24h
  workloadSelector:
    labels:
      app: app

Can see this added to config:
kubectl -n rsb get envoyfilter redis-test -o yaml
---
---
---
                        "name": "envoy.tcp_proxy",
                        "typedConfig": {
                            "@type": "type.googleapis.com/envoy.config.filter.network.tcp_proxy.v2.TcpProxy",
                            "statPrefix": "outbound|6379||abc-redis-opensource.rsb.svc.cluster.local",
                            "cluster": "outbound|6379||abc-redis-opensource.rsb.svc.cluster.local",
                            "idleTimeout": "86400s"
                        }
---
---
---

However, still seeing the hourly timeouts. (if I do set above to 60 seconds, I do get 60 second timeouts so think this is a timeout on the front end rather than the one we're having issues with)
I think I need to try and set the timeout on the cluster config but I'm having difficulties doing that at the moment.

Yah I'm not sure why the annotation doesn't work (I'll check) but just add it as an env variable like I previously mentioned... add it to the client side proxy:
ISTIO_META_IDLE_TIMEOUT
24h0m0s

kubectl -n abc exec -it app-f6f79bcf6-ldjgb -c istio-proxy -- env | grep ISTIO_META_IDLE_TIMEOUT
ISTIO_META_IDLE_TIMEOUT=24h0m0s

It adds correctly using the annotation but, unfortunately, don't see any change to the timeout.

Ah okay let me check the cluster config part. There may not be a way to do that at the moment. Will report back.

Thanks. N.B. We are using Istio 1.6.2 now.

I gotta be honest, I'm not able to reproduce this. I'm getting the timeout enforced by the tcp_proxy correctly. Now.. if you do have filters on the cluster as well, we should take a look at those... can you give me the json output of this cluster outbound|26379||dds-redis-opensource-announce-0.abc.svc.cluster.local for the proxy on the client side of the connection?
Worst case, I can jump on a zoom call with you and we can take a look together.

I'm having a similar issue on Istio 1.5.8. TCP connections are dropped for various service types (SSL, postgres, redis) after 1 hour. Like @nabbott2008 , settings ISTIO_META_IDLE_TIMEOUT to 24h0m0s did not work but 30s did work. I tried to set it to 0s to disable it but it brokes connection.

+1, We are seeing exactly the same issue as @courcelm described, on Istio 1.5.6.

I know idle_timeout appears in HTTP connection manager common_http_protocol_options, route, and cluster
Using an EnvoyFilter to set the cluster level idle_timeout to 10m, users were able to trigger closed connection failure in their app, but unable to increase the duration beyond the 1 hour default:
apiVersion: networking.istio.io/v1alpha3
kind: EnvoyFilter
metadata:
  name: "cluster-idletimeout"
spec:
  configPatches:
  - applyTo: CLUSTER
    match:
      context: ANY
    patch:
      operation: MERGE
      value:
        common_http_protocol_options:
          idle_timeout: 10m

Envoy defaults all idle_timeout's to 1 hour, @howardjohn @christian-posta is the problem that users need to change the value in all places if they want it to go longer?  i.e. does a smaller default idle_timeout at the Listener level break the larger user specified idle_timeout configured at the Cluster level?

We ran into the same problem on 1.7, but we noticed that the ISTIO_META_IDLE_TIMEOUT setting was only getting picked up on the OUTBOUND side of things, not the INBOUND.  By adding an additional filter that applied to the INBOUND side of the request, we were able to successfully increase the timeout (we used 24 hours):

I'm having this 1hr timeout issue also with Postgres client. Using istio1.6.7

env ISTIO_META_IDLE_TIMEOUT is only for outbound, so it is good for ingress gateway, but not for Pod annotation. For service client, we shall use DR + KA configuration.

@Rayzhangtian We're having issues with this and connections to postgres (similar to @jsabalos). Could you please share what DR + KA configs you used that solved the issue?

I think increasing or disabling idle_timeout is only a workaround to fix this. The question is why envoy sidecar doesn't terminate the connection to application (downstream) and only terminate to server upstream

here is my topology
user -> gateway -> service (sidecar istio-proxy) -> redis

I am reducing idle timeout to simulate the problem:
apiVersion: networking.istio.io/v1alpha3
kind: EnvoyFilter
metadata:
  name: idle-timeout-1.9-ef
  namespace: istio-system
spec:
  configPatches:
  - applyTo: NETWORK_FILTER
    match:
      context: ANY
      listener:
        filterChain:
          filter:
            name: envoy.filters.network.tcp_proxy
      proxy:
        proxyVersion: ^1\.9.*
    patch:
      operation: MERGE
      value:
        name: envoy.filters.network.tcp_proxy
        typed_config:
          '@type': type.googleapis.com/envoy.extensions.filters.network.tcp_proxy.v3.TcpProxy
          idle_timeout: 3s

the first request success, it's creating TCP proxy
2021-11-02T05:14:13.260048Z	debug	envoy pool	[C47163] using existing connection
2021-11-02T05:14:13.260053Z	debug	envoy pool	[C47163] creating stream
2021-11-02T05:14:13.260066Z	debug	envoy router	[C47317][S9607723458839045519] pool ready
2021-11-02T05:14:13.260487Z	debug	envoy filter	original_dst: New connection accepted
2021-11-02T05:14:13.260556Z	debug	envoy filter	[C47318] new tcp proxy session
2021-11-02T05:14:13.260577Z	debug	envoy filter	[C47318] Creating connection to cluster outbound|6379||s-echo-redis-cache-redis-01.c.staging.internal.
2021-11-02T05:14:13.260608Z	debug	envoy upstream	transport socket match, socket default selected for host with address <IP_ADDRESS>:6379
2021-11-02T05:14:13.260621Z	debug	envoy upstream	Created host <IP_ADDRESS>:6379.
2021-11-02T05:14:13.260661Z	debug	envoy upstream	addHost() adding <IP_ADDRESS>:6379
2021-11-02T05:14:13.260667Z	debug	envoy pool	creating a new connection
2021-11-02T05:14:13.260759Z	debug	envoy upstream	membership update for TLS cluster outbound|6379||s-echo-redis-cache-redis-01.c.staging.internal. added 1 removed 0
2021-11-02T05:14:13.260772Z	debug	envoy pool	[C47319] connecting
2021-11-02T05:14:13.260777Z	debug	envoy upstream	re-creating local LB for TLS cluster outbound|6379||s-echo-redis-cache-redis-01.c.staging.internal.
2021-11-02T05:14:13.260762Z	debug	envoy upstream	membership update for TLS cluster outbound|6379||s-echo-redis-cache-redis-01.c.staging.internal. added 1 removed 0
2021-11-02T05:14:13.260778Z	debug	envoy connection	[C47319] connecting to <IP_ADDRESS>:6379
2021-11-02T05:14:13.260800Z	debug	envoy upstream	re-creating local LB for TLS cluster outbound|6379||s-echo-redis-cache-redis-01.c.staging.internal.
2021-11-02T05:14:13.260857Z	debug	envoy connection	[C47319] connection in progress
2021-11-02T05:14:13.260871Z	debug	envoy pool	queueing request due to no available connections
2021-11-02T05:14:13.260876Z	debug	envoy conn_handler	[C47318] new connection
2021-11-02T05:14:13.260896Z	debug	envoy upstream	membership update for TLS cluster outbound|6379||s-echo-redis-cache-redis-01.c.staging.internal. added 1 removed 0
2021-11-02T05:14:13.260907Z	debug	envoy upstream	re-creating local LB for TLS cluster outbound|6379||s-echo-redis-cache-redis-01.c.staging.internal.
2021-11-02T05:14:13.262126Z	debug	envoy connection	[C47319] connected

after 3 seconds of the idle timeout, it seems like closing the connection, but only to upstream redis
2021-11-02T05:14:16.262443Z	debug	envoy filter	[C47318] Session timed out
2021-11-02T05:14:16.262483Z	debug	envoy connection	[C47318] closing data_to_write=0 type=1
2021-11-02T05:14:16.262486Z	debug	envoy connection	[C47318] closing socket: 1
2021-11-02T05:14:16.262648Z	debug	envoy connection	[C47319] closing data_to_write=0 type=1
2021-11-02T05:14:16.262660Z	debug	envoy connection	[C47319] closing socket: 1
2021-11-02T05:14:16.262705Z	debug	envoy pool	[C47319] client disconnected
2021-11-02T05:14:16.262717Z	debug	envoy conn_handler	[C47318] adding to cleanup list
2021-11-02T05:14:16.262737Z	debug	envoy pool	[C47319] connection destroyed

and the second request, it's getting 502
2021-11-02T05:14:20.771115Z	debug	envoy pool	[C47171] using existing connection
2021-11-02T05:14:20.771120Z	debug	envoy pool	[C47171] creating stream
2021-11-02T05:14:20.771131Z	debug	envoy router	[C47187][S14376139327146836108] pool ready
2021-11-02T05:14:20.771559Z	debug	envoy router	[C47187][S14376139327146836108] upstream headers complete: end_stream=false
2021-11-02T05:14:20.771644Z	debug	envoy http	[C47187][S14376139327146836108] encoding headers via codec (end_stream=false):
':status', '502'
'date', 'Tue, 02 Nov 2021 05:14:20 GMT'
'content-length', '3'
'content-type', 'text/plain; charset=utf-8'
'x-envoy-upstream-service-time', '0'
'x-envoy-peer-metadata', '[REDACTED]'
'x-envoy-peer-metadata-id', 'sidecar~<IP_ADDRESS>~echo-redis-stable-5987d8dd44-kwxw8.testing~testing.svc.cluster.local'
'server', 'istio-envoy'

2021-11-02T05:14:20.771675Z	debug	envoy client	[C47171] response complete
2021-11-02T05:14:20.772082Z	debug	envoy filter	Called AuthenticationFilter : onDestroy
2021-11-02T05:14:20.772110Z	debug	envoy pool	[C47171] response complete
2021-11-02T05:14:20.772116Z	debug	envoy pool	[C47171] destroying stream: 0 remaining

and somehow, after the second request is failing, the third request success to create the TCP proxy
2021-11-02T05:14:22.059301Z	debug	envoy pool	[C47171] using existing connection
2021-11-02T05:14:22.059305Z	debug	envoy pool	[C47171] creating stream
2021-11-02T05:14:22.059314Z	debug	envoy router	[C47170][S952113864182611469] pool ready
2021-11-02T05:14:22.059671Z	debug	envoy filter	original_dst: New connection accepted
2021-11-02T05:14:22.059743Z	debug	envoy filter	[C47327] new tcp proxy session
2021-11-02T05:14:22.059799Z	debug	envoy filter	[C47327] Creating connection to cluster outbound|6379||s-echo-redis-cache-redis-01.c.staging.internal.
2021-11-02T05:14:22.059828Z	debug	envoy upstream	transport socket match, socket default selected for host with address <IP_ADDRESS>:6379
2021-11-02T05:14:22.059835Z	debug	envoy upstream	Created host <IP_ADDRESS>:6379.
2021-11-02T05:14:22.059858Z	debug	envoy pool	creating a new connection
2021-11-02T05:14:22.059886Z	debug	envoy upstream	addHost() adding <IP_ADDRESS>:6379
2021-11-02T05:14:22.059905Z	debug	envoy pool	[C47328] connecting
2021-11-02T05:14:22.059914Z	debug	envoy connection	[C47328] connecting to <IP_ADDRESS>:6379
2021-11-02T05:14:22.059973Z	debug	envoy upstream	membership update for TLS cluster outbound|6379||s-echo-redis-cache-redis-01.c.staging.internal. added 1 removed 0
2021-11-02T05:14:22.059986Z	debug	envoy upstream	membership update for TLS cluster outbound|6379||s-echo-redis-cache-redis-01.c.staging.internal. added 1 removed 0
2021-11-02T05:14:22.060000Z	debug	envoy connection	[C47328] connection in progress
2021-11-02T05:14:22.060012Z	debug	envoy upstream	re-creating local LB for TLS cluster outbound|6379||s-echo-redis-cache-redis-01.c.staging.internal.
2021-11-02T05:14:22.059988Z	debug	envoy upstream	re-creating local LB for TLS cluster outbound|6379||s-echo-redis-cache-redis-01.c.staging.internal.
2021-11-02T05:14:22.060014Z	debug	envoy pool	queueing request due to no available connections
2021-11-02T05:14:22.060059Z	debug	envoy conn_handler	[C47327] new connection
2021-11-02T05:14:22.060089Z	debug	envoy upstream	membership update for TLS cluster outbound|6379||s-echo-redis-cache-redis-01.c.staging.internal. added 1 removed 0
2021-11-02T05:14:22.060104Z	debug	envoy upstream	re-creating local LB for TLS cluster outbound|6379||s-echo-redis-cache-redis-01.c.staging.internal.
2021-11-02T05:14:22.061287Z	debug	envoy connection	[C47328] connected
2021-11-02T05:14:22.061311Z	debug	envoy pool	[C47328] assigning connection
2021-11-02T05:14:22.061328Z	debug	envoy filter	[C47327] TCP:onUpstreamEvent(), requestedServerName:
2021-11-02T05:14:22.062214Z	debug	envoy router	[C47170][S952113864182611469] upstream headers complete: end_stream=false
2021-11-02T05:14:22.062284Z	debug	envoy http	[C47170][S952113864182611469] encoding headers via codec (end_stream=false):
':status', '200'

you can see the full log (service sidecar) here:
echo-redis-03.log
I have concern why the envoy sidecar is only terminating to upstream (in this case Redis), but not terminating to downstream itself (the application where the sidecar is running)
This causes us a problem since we need to configure all our applications to set TCP idle timeout below the Envoy configuration. For example, if we have a 1-hour idle timeout, we must make sure our application that connects to Redis/Postgresql or whatever that is using TCP proxy to have an idle timeout below 1 hour so our application can initiate a TCP closing handshake. We receive lot's of complaints from devs
@howardjohn do you know about this? did we miss something?

give some diagram that might help to understand the issue

there is two expected behavior that could solve this problem:

If idle timeout is above the threshold, sidecar close connection to upstream (Redis, Postgresql, etc) but sidecar must open a new connection to the upstream
or, when idle timeout is above the threshold, the sidecar is also closing the connection to the downstream client

We try to implement TCP keepalive, but this doesn't block TCP Proxy idle_timeout for terminating the connection to upstream (redis in this case)

apiVersion: networking.istio.io/v1alpha3
kind: EnvoyFilter
metadata:
  name: idle-timeout-1.9-ef
  namespace: istio-system
spec:
  configPatches:
  - applyTo: NETWORK_FILTER
    match:
      context: ANY
      listener:
        filterChain:
          filter:
            name: envoy.filters.network.tcp_proxy
      proxy:
        proxyVersion: ^1\.9.*
    patch:
      operation: MERGE
      value:
        name: envoy.filters.network.tcp_proxy
        typed_config:
          '@type': type.googleapis.com/envoy.extensions.filters.network.tcp_proxy.v3.TcpProxy
          idle_timeout: 20s
---
apiVersion: networking.istio.io/v1alpha3
kind: ServiceEntry
metadata:
  name: echo-redis
  namespace: testing
spec:
  hosts:
  - s-echo-redis-cache-redis-01.c.staging.internal.
  addresses:
  - <IP_ADDRESS>
  location: MESH_EXTERNAL
  ports:
  - number: 6379
    name: tcp
    protocol: TCP
  resolution: NONE
  exportTo:
  - "."
---
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: echo-redis-mesh-dr
  namespace: testing
spec:
  host: s-echo-redis-cache-redis-01.c.staging.internal.
  trafficPolicy:
    portLevelSettings:
    - port:
        number: 6379
      connectionPool:
        tcp:
          tcpKeepalive:
            probes: 9
            time: 5s
            interval: 3s

I think this mostly related to

https://github.com/envoyproxy/envoy/issues/6190
https://github.com/kubeflow/kubeflow/issues/1710#issuecomment-489111847
https://github.com/envoyproxy/envoy/issues/13388#issuecomment-703716766

@ryant1986 could you share the Envoyfilter for passthrough cluster sample here.

For anyone still facing broken pipe errors due to upstream closing the connection, based on ryant1986's comment we ended up using an EnvoyFilter but in our case setting the idleTimeout to 30s did the trick and not 24h. We are on v.1.19.5.
apiVersion: networking.istio.io/v1alpha3
kind: EnvoyFilter
metadata:
  name: listener-timeout-tcp
  namespace: istio-system
spec:
  configPatches:
    - applyTo: NETWORK_FILTER
      match:
        context: GATEWAY
        listener:
          filterChain:
            filter:
              name: envoy.filters.network.tcp_proxy
      patch:
        operation: MERGE
        value:
          name: envoy.filters.network.tcp_proxy
          typed_config:
            "@type": type.googleapis.com/envoy.extensions.filters.network.tcp_proxy.v3.TcpProxy
            idle_timeout: 30s


Update .NET 9 SDK and consume Functions RunCommand changes

Description
Upgrade to a .NET 9 RC 2 SDK and 2.0.0-preview1 builds of Azure Functions so that we can consume the DotnetRunCommand changes and remove our workaround from the code.
Checklist

Is this feature complete?

[X] Yes. Ready to ship.
[ ] No. Follow-up changes expected.

Are you including unit tests for the changes and scenario tests if relevant?

[ ] Yes
[X] No

Did you add public API?

[ ] Yes

If yes, did you have an API Review for it?

[ ] Yes
[ ] No

Did you add <remarks /> and <code /> elements on your triple slash comments?

[ ] Yes
[ ] No

[X] No

Does the change make any security assumptions or guarantees?

[ ] Yes

If yes, have you done a threat model and had a security review?

[ ] Yes
[ ] No

[X] No

Does the change require an update in our Aspire docs?

[ ] Yes

Link to aspire-docs issue:

[X] No

Microsoft Reviewers: Open in CodeFlow

The tests appear to be failing:
Exception Message
System.Threading.Tasks.TaskCanceledException : Task was canceled before these messages were found: 'MyAzureBlobTrigger: blobTrigger'
---- System.Threading.Tasks.TaskCanceledException : A task was canceled.
CallStack
   at Aspire.Hosting.Tests.Utils.LoggerNotificationExtensions.WaitForAllTextAsync(DistributedApplication app, IEnumerable`1 logTexts, String resourceName, CancellationToken cancellationToken) in /datadisks/disk1/work/B4A60997/w/B42E099B/e/tests/Aspire.Playground.Tests/LoggerNotificationExtensions.cs:line 108
   at Aspire.Playground.Tests.ProjectSpecificTests.AzureFunctionsTest() in /datadisks/disk1/work/B4A60997/w/B42E099B/e/tests/Aspire.Playground.Tests/ProjectSpecificTests.cs:line 72
   at Aspire.Playground.Tests.ProjectSpecificTests.AzureFunctionsTest() in /datadisks/disk1/work/B4A60997/w/B42E099B/e/tests/Aspire.Playground.Tests/ProjectSpecificTests.cs:line 130
--- End of stack trace from previous location ---
----- Inner Stack Trace -----
   at Aspire.Hosting.Tests.Utils.LoggerNotificationExtensions.WaitForAllTextAsync(DistributedApplication app, IEnumerable`1 logTexts, String resourceName, CancellationToken cancellationToken) in /datadisks/disk1/work/B4A60997/w/B42E099B/e/tests/Aspire.Playground.Tests/LoggerNotificationExtensions.cs:line 92

The tests appear to be failing:

Yeah, I can't repro it reliably locally or in CI so it's a bit tricky to debug. The stack trace that I did see seemed to indicate that it was a result of the Functions host not launching (e.g. you get the issue about gRPC not being able to connect).
This might indicate that the RunCommand that launches the Functions host from the worker SDK wasn't actually invoked but this needs more debugging 🤔

/azp run

Looks like the test is still failing.

Looks like the test is still failing.

Yeah, I haven't poked at this any further since we last chatted. I'll planning to revisit once all the other inflight things land. In the meantime, I'll move this to draft mode.

Closing this until we have the finalized bits from Functions.


Alternative approach to mark this repository as Swift

This is just a cosmetic change, so feel free to close this PR 😄
This adds a .gitattributes file that forces linguist to update the language stats. In this case it ignores Dangerfile, making the repository 100% about Swift. With this change it was possible to simplify helloworld.swift.
It may take a while for the bar to update after merging, but you can see the updated version in the fork. There's more information about linguist including other approaches here.
Thank you for maintaining this awesome list 👏

@dmfrancisco YOU ARE MY HERO ❤
Thanks so much. It's very important to us be marked as 'Swift Repo', because a lot of developers find us by Github search based on language.
Thank you 🎉

That's awesome! Thanks for the fix 👏 👏 👏 👏

Well done


Comments are not highlighted except at beginning of file

Comments at the beginning of the file work as expected. However, line comments after a line break, and inline comments both do not work.
Working / full line

Inline

Update: Full line comment highlighting works when previous line is not empty.


Fixed whereRelation losing generic type.

[x] Added or updated tests
[x] Documented user facing changes
[x] Updated CHANGELOG.md

resolves https://github.com/nunomaduro/larastan/issues/1376

the monica tests are caused by the previous merged pr and are unrelated to this change

Thank you!


allows to setup a mapping between gameplay tags and sequence tags.

It uses the Actors that register via the FlowComponent's IdentityTags.
Within the node the designer can define the mapping
The Example Sequence:

The FlowNode:

Possible Future Improvements:

Like the Sequence Events, that are auto detected, one could check which tags are available at all. either to validate, or to prepoluate the Map (note that the map would be the other way around, then)

I'm sorry, but I'm unsure if adding Actor Bindings to the core node wouldn't be too much. This node wasn't intended to fulfill all needs of projects operating on Level Sequences. It's supposed to be a node showing basic functionality.
Actor Binding could get quite complex in specific projects. In the current version of the proposed changes, we only add bindings (although it would be sufficient in many projects!).
There's no support for SaveGames which would be essential for gameplay-driven Level Sequences. And supporting this might require more and more changes and pull requests.
This being said, I would have nothing against adding this logic in the class inheriting after "Play Level Sequence" in the example Flow Quest plugin. What do you think? :)
https://github.com/MothCocoon/FlowSolo/tree/5.3/Plugins/FlowQuest/Source/FlowQuest/Public/Flow/Nodes

Hi, I made the changes in our project, because we needed them. I felt like, it could be beneficial for others too, so this PR was born. Also another aspect: getting feedback from people more knowledgeable in the plugin and unreal than I am :D
so in this regard thanks already! You're absolutely right about the missing SaveGame support and I will address that as soon as I find time for it.
Regarding inheriting the Node to add functionality, I'm not generally opposing the idea, but wondering: Let's say my game designer is setting up our next level, if I inherit from the node, there will be two nodes in the palette, doing like 90% the same thing just that one of them supports more features. should he pick the wrong node it's also a bit annoying to replace the old one.
I feel like there is no real gain from separating them.
I'm also now thinking: is there a way to "hide" registered nodes? like, could I create a child PlayLevelSequence that has more functionality and hide the original PlayLevelSequence somehow?

Regarding inheriting the Node to add functionality, I'm not generally opposing the idea, but wondering: Let's say my game designer is setting up our next level, if I inherit from the node, there will be two nodes in the palette, doing like 90% the same thing just that one of them supports more features. should he pick the wrong node it's also a bit annoying to replace the old one.
I'm also now thinking: is there a way to "hide" registered nodes? like, could I create a child PlayLevelSequence that has more functionality and hide the original PlayLevelSequence somehow?

Yes, you can hide built-in nodes from the Palette in your project. Just add it to the NodesHiddenFromPalette list in the Flow Graph Settings. This way you don't need to modify the plugin's code. It might a way to easier for you to simply use your class.
And now I'm thinking that even adding proper SaveGame support might need additional changes in a specific project, so... I guess it's best to close this PR. I would be more open to accepting a custom node to the FlowSolo project than keep extending this "base node".


Drop older Swift version (<5.8), Bump deployment targets to support minimums

New Pull Request Checklist

[x] I have read and understood the CONTRIBUTING guide
[x] I have read the Documentation
[x] I have searched for a similar pull request in the project and found none

[x] I have updated this branch with the latest master to avoid conflicts (via merge from master or rebase)
[x] I have added the required tests to prove the fix/feature I am adding
[x] I have updated the documentation (if necessary)
[x] I have run the tests and they pass
[x] I have run the lint and it passes (pod lib lint)

This merge request fixes / refers to the following issues: -
Pull Request Description

Drops support for older Swift versions pre 5.8 (SPM will automatically fall back to older releases).
Bumps deployment targets to minimums supported by Xcode 15.

This also fixes #1375 since I bumped the minimum to watchOS 5.0...


AppInsightsModule hardcodes http path to the script

See:
https://github.com/Microsoft/ApplicationInsights-JS/blob/e739caed7bd9d9f051a54889bf2483e1e43b6db7/JavaScript/JavaScriptSDK.Module/AppInsightsModule.ts#L33
The original snippet uses protocol relative path.

Thanks! Looks like a bug.

any change this fix will be released soon to npm?


Marriage abroad amends for Oman

PT story: https://www.pivotaltracker.com/story/show/109437714
Add Oman specific outcome to the marriage abroad smart answer, and update content with new information and links.
Fact check
https://pt-109437714.herokuapp.com/marriage-abroad
Expected changes
*URL on gov.uk

Add mosque and temple as places where you can get married

Before

After

Have just rebased this with master

:+1:

Have just rebased this with master


add NatSpec comments

closes #35

:warning: Please install the  to ensure uploads and comments are reliably processed by Codecov.
Codecov Report
Attention: Patch coverage is 77.27273% with 5 lines in your changes missing coverage. Please review.

Files
Patch %
Lines

contracts/BNBPartyState.sol
0.00%
5 Missing :warning:

:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.

Files
Coverage Δ

contracts/BNBPartyFactory.sol
100.00% <ø> (+12.50%)
:arrow_up:

contracts/BNBPartyLiquidity.sol
100.00% <100.00%> (ø)

contracts/BNBPartyManageable.sol
89.28% <100.00%> (ø)

contracts/BNBPartyModifiers.sol
100.00% <100.00%> (ø)

contracts/BNBPartySwaps.sol
96.15% <100.00%> (ø)

contracts/BNBPartyView.sol
100.00% <100.00%> (ø)

contracts/token/ERC20Token.sol
100.00% <100.00%> (ø)

contracts/BNBPartyState.sol
61.53% <0.00%> (-38.47%)
:arrow_down:


Axios need to be updated

npm audit report
axios  0.8.1 - 0.27.2
Severity: moderate
Axios Cross-Site Request Forgery Vulnerability - https://github.com/advisories/GHSA-wf5p-g6vw-rhxx
No fix available
node_modules/axios
reverso-api  *
Depends on vulnerable versions of axios
node_modules/reverso-api

axios is no longer in use


Org Assets Issue in FilePicker - Your organization tab is not shown

Category
[ ] Enhancement
[x ] Bug
[ ] Question
Version
1.19.0
Expected / Desired Behavior / Question
Your organisation tab shown to get images/files provided by your organization, where filepicker has not provided props to hide
Observed Behavior
Your organization is not displayed and when you debug there are issues in the code which makes the org tab not visible
Steps to Reproduce

Your org assets are in the root site collection
Add FilePicker controls
No Your organization

Further if this helps:
The issues are in the files
FilePicker.tsx
Line 58
The condition should be (instead of && operation || should be used and sometimes we are not passing this prop and will be undefined)
if (this.props.hideOrganisationalAssetTab != undefined || !this.props.hideOrganisationalAssetTab ) {
FileBrowserService.ts
Line 268
Function buildAbsoluteUrl , need to have "/" if Library url does not start with a "/"
OrgAssetsService.ts
Line 76
Null check for function _parseOrgAssetsLibraryItem 's
libItem.ThumbnailUrl
It will be best to do null check for any property of the object, not only the item we need.
Hope that helps.
I can also take it up, if my approach of the fix sounds reasonable.
Thanks,
Rabia
Thanks!

Any news regarding this issue?

Hi @rabwill!
Thanks for reporting that and providing steps for fix!
The fix will be available in the next release.
In a meanwhile you can test it in beta version.
BTW, I've added you Rabia as a contributor as you provided the solution! Thank you!

Wohoo!! Thanks so much @AJIXuMuK !


Click Sound

The Click sound is not working after every turn.

Trimmed the clicksound.wav file This solved the clicksound bug.


Explore migration to Kubernetes for volumes

Problem:

WT has home-grown container volume management, when other solutions exist via the orchestration systems, but these do not support Fuse and WebDav
gwvolman runs privileged to mount volumes (must have SYS_ADMIN for mount and FUSE_DEV caps)
gwvolman does not handle all situations (e.g., node draining/failure)
WT runs on Openstack, so we can control the hosts, but would like to be able to deploy elsewhere (GCE).

Background:
We are considering migrating from Docker Swarm to Kubernetes. Most existing capabilities will translate easily, but volume/storage management may be challenging.
Similar to Docker, Kubernetes has a standard storage driver abstraction with a variety of common volume types. Unfortunately, Fuse and DavFS are not apparently readily supported.
In WT today, we use a home-grown container volume management. We could:

Port girderfs to a storage driver using flexVolume or CSI
Find an alternative -- maybe there's something already there (see Pangeo issue  https://github.com/pangeo-data/pangeo/issues/92)
Use the current approach, running a privileged container to manage the mounts.
Other ideas: listen to Kubernetes events

Other references:

https://karlstoney.com/2017/03/01/fuse-mount-in-kubernetes/

Task constraints:
This is an exploratory task to see what our options are -- time bounded at ~3 weeks to see if it's worth pursuing. Please document findings as you go along.

This exploration and much much more has been completed on the following branches:

https://github.com/whole-tale/wt-kubernetes/tree/dev-kube-2.0
https://github.com/whole-tale/gwvolman/tree/dev-kube-2.0

The wt-kubernetes repo provides the following:

Prototype deployment of WT under Kubernetes (initially done under GCE)
Custom Docker image definitions for Girder and gwvolman to run under Kubernetes

The gwvolman branch includes:

Changes to gwvolman to support launching Tales via the Kubernetes API
Templates for the Tale deployment that define the volume implementation (i.e., girderfs support)

The primary goal of this issue was to provide a Kubernetes-esque solution to the girderfs problem. Instead of the discussed CSI/flexVolume approach, @hategan has proposed a much simpler side-car container https://github.com/whole-tale/gwvolman/blob/dev-kube-2.0/gwvolman/templates/tale-deployment.yaml#L48-L92.  In short, for each Tale, a privileged side-car container runs gwvolman to mount and unmount girderfs fuse volumes via Pod lifecycle hooks.
This solution seems great to me and I think we can move on with the formal transition from swarm to Kubernetes. I've started putting together a design doc for comment:
https://docs.google.com/document/d/1WvlNF5wVDeaNvZSaEc022C1LZOtMnolnIo8ej7dNrno/edit

@hategan One minor question I have about your "mounter" container solution is whether you tried to use an emptyDir volume instead of a real PersistentVolumeClaim.  On the one hand the PVC seems unnecessary -- why provision a volume just to mount?  On the other hand, PVCs are problematic when we deploy on OpenStack -- our primary platform.  Dynamic volume provisioning is one of the big weaknesses on OpenStack and if we don't need a volume it would be easier.

You need actual space to unpack the tale files (e.g., .ypnb, etc.) and for whatever temporary data might be generated by the tale. We could use emptyDir/hostPath for that, but that means we can't provision for particular space requirements (we'd be at the mercy of whatever space the node has and that is neither specified by Kubernetes nor controllable by the user AFAIK). We also don't want this to be ephemeral storage, since we want to preserve changes to tale files if the pods are restarted/migrated. So, in my understanding, we need some kind of persistent volume for that.
Since the above already gives us a directory on the node, there is no point in creating another emptyDir/hostPath mount just for the FUSE mountpoints.
So it isn't as much that we need a PV for the FUSE stuff, but that we need it for the tale, and since we have it, we might as well use it for the mountpoints.

Thanks, @hategan (/cc @Xarthisius). I must be misunderstanding something -- we mount the Tale workspace via girderfs, right?  We shouldn't be downloading files outside of fuse and data generated by the Tale is stored in the fuse mounted workspace (unless they are writing somewhere else in the container, in which case it's still ephemeral).

@craig-willis not quite. One of the first steps that gwvolman takes is create_volume() (see tasks.py). This calls girder_client.downloadFolderRecursive() to get the tale files locally. So they are not part of a mount.
I don't know why this is done instead of mounting the folder. I think @Xarthisius can provide some insight there. It may very well be that we could instead mount the tale folder.
However, we would still have a need to control the scratch space that tales get.
I would also like to mention that nothing here requires dynamic provisioning. While this is how it's done now, because it is easy, static provisioning can be done equally well with what I believe would be somewhat minor changes.

@craig-willis not quite. One of the first steps that gwvolman takes is create_volume() (see tasks.py). This calls girder_client.downloadFolderRecursive() to get the tale files locally. So they are not part of a mount.

Oh, that's the narrative. Concept that I very much like, but I'm the only one in the Universe. That code is dead, i.e. there are no "real" Tales that would ever set narrativeId to something not null...

@Xarthisius I see. So to answer @craig-willis ' original question, modulo scratch space, I think we can switch to emptyDir or hostPath.

Yeah, and AFAIR current setting for girderfs cache is $TMDIR/wtdms*, so it's stored in the ephemeral space.

OK, this makes sense now.  I also like the narrative concept but sadly never did anything with it...
The scratch space question is worth revisiting. We also need to think about this in the context of OpenStack (our primary platform) v GCE.  We've never enforced quotas on tales, but it's something we'll eventually hit and we'll always have an ephemeral problem whether under /tmp, /var/lib/docker/ or /var/lib/kubelet.
Whether the storage quota is actually enforceable I believe depends on the underlying cloud infrastructure. Under OpenStack we don't want to allocate a Cinder volume per tale, as we'd quickly exhaust our volume quota.  I don't know whether local volumes will enforce the storage capacity -- i.e., if I have 100GB of local scratch and give each tale 10GB vi local volume, if the tale exceeds the 10GB storage will Kubernetes report an error?  For NFS I know this isn't the case.


Create builds for major .NET versions

The Nuget package should have dlls for at least the following versions:

4.0
4.5
4.6
Core?

I use this package constantly. And am really looking forward to the support of Async operations that this package provides. Are you interested in having any assistance from the community? Are these todo items holding up release of this to Nuget?


add support for all LP50xx controllers

Actually the LP503x driver only supports LP5030 and LP5036 devices. This PR adds support for LP5009, LP5012, LP5018 and LP5024. Therefore the driver was renamed to LP50xx.
It also adds the ability to use bank mode and set all bits in the device_config registers.
Tested on a custom board with a LP5024.

Hello @MeisterBob,
Thanks for this PR but we are already in the process of adding support for more controllers to the lp503x driver. See https://github.com/zephyrproject-rtos/zephyr/pull/59852.

That wasn't there when I started with the hardware part of my project 4 weeks ago :open_mouth: . I'll have a look into that PR.


Fix Package Name, thanks.

Which package(s) are showing incorrect data?

https://swiftpackageindex.com/William-Weng/WWSignInWith3rd_Weibo

Please explain what data is incorrect and what you expected to see
This SPM name is WWSignInWith3rd+Weibo, thanks.
https://swiftpackageindex.com/William-Weng/WWSignInWith3rd_Weibo
Screenshots

This will be fixed via https://github.com/William-Weng/WWSignInWith3rd_Weibo/pull/1
It will take a couple of hours to update after that PR is merged, but it will update automatically. Thanks for adding your packages!