ValueType.INT metric instrument integer overflow

JavaScript integer numbers are coerced to floating-point values implicitly if the value goes over the Number.MAX_SAFE_INTEGER. A metric instrument with ValueType.INT should stick to integer values if possible.
Spec: https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/metrics/supplementary-guidelines.md#integer

JS can only safely represent numbers between -(2^(53) - 1) and 2^(53) - 1. Outside this range, adding and subtracting integers will have an imprecise effect on the value. Small additions and subtractions may even have no effect at all.
Options:

Overflow at 2^53 to -2^53 - 1 (stay within JS safe range)
Reset at 2^53 to zero
Overflow at 2^31 to -(2^31 - 1) (emulate 32-bit signed int)

The proto defines numeric integer metric values as signed 64-bit ints (sfixed64 in proto3). I think option 1 is most likely to be incorrectly handled by a backend (may be assumed to be a 64-bit int once it goes above 2^53 - 1). Option 2 is likely to be detected by most backends as a reset and I think should be pretty safe. Option 3 may be correctly detected as an overflow by some backends if they have overflow detection support and may be detected as a reset by others.
Personally I think option (2) is the safest, but (3) is also reasonable.

We can also use BigInt which is supported in major browsers and node since 10.5
https://node.green/#ES2020-features-BigInt
https://caniuse.com/bigint
When converting to proto we would need to be sure to properly overflow numbers larger than 2^64 - 1

We can also use BigInt which is supported in major browsers and node since 10.5

I'm not sure if its related but we had an issue to support int64 here: https://github.com/open-telemetry/opentelemetry-js/issues/104, maybe can we tackle both a the same time ? Just serializing it in proto differently depending on the value ?

We can also use BigInt which is supported in major browsers and node since 10.5

I'm not sure if its related but we had an issue to support int64 here: #104, maybe can we tackle both a the same time ? Just serializing it in proto differently depending on the value ?

Now that we don't have 8,10,12 we can use BigInt there too

How do we want to handle this? I don't want to just use BigInt for everything since numbers larger than 2^53 aren't the most common and there is a significant performance hit vs using number because BigInt can't take advantage of built in hardware arithmetic.
Here is my proposal:
/cc @open-telemetry/javascript-maintainers especially @legendecas
Int Gauge
Accept number or BigInt in the API. Do not do any conversions, and exporters should handle both cases. No arithmetic is needed in gauges and the user should expect to get out the precision they put in.
Int Sum
Accept number or BigInt in the API. If the user provides BigInt store internal representation as BigInt. If the user provides number then continue to use number until reaching 2^53 and convert to BigInt. Once the internal representation has been converted to BigInt never convert back to number. Above 2^63 (maximum signed 64-bit int) wrap to -2^63.
Histograms and float gauge/sum
No need for special handling as the API for histograms specifies float input. Bucket counts should never reach above MAX_SAFE_INTEGER.

Once we agree on a strategy i'm happy to work on this one

I would be inclined not to introduce implicit conversion between numbers and bigints. Conversion from numbers to bigints is easy, but the interoperability between numbers and bigints is not trivial as all the operands must be a bigint. Lots of places must be aware of this implication and it can complicate the common path:

Number.isInteger(0n) === false: https://github.com/open-telemetry/opentelemetry-js/blob/main/experimental/packages/opentelemetry-sdk-metrics-base/src/Instruments.ts#L29
TypeError on arithmetic operation between numbers and bigints: https://github.com/open-telemetry/opentelemetry-js/blob/main/experimental/packages/opentelemetry-sdk-metrics-base/src/aggregator/Sum.ts#L31

I'd suggest introducing a series of APIs explicitly involved with the bigints, like meter.createBigIntCounter.

The proto defines numeric integer metric values as signed 64-bit ints (sfixed64 in proto3). I think option 1 is most likely to be incorrectly handled by a backend (may be assumed to be a 64-bit int once it goes above 2^53 - 1).

@dyladan Would you mind clarifying why backends that support signed 64-bit ints can not handle resets from 2^53 - 1 to -(2^53 - 1)?
Either way, as the overflow has to be manually reset, resetting 2^53 - 1 to -(2^53 - 1) or 0 both sound good to me. Overflowing to the lower bound of the safe integer range might be a common choice for the other language implementations.

I'd suggest introducing a series of APIs explicitly involved with the bigints, like meter.createBigIntCounter.

Generally other languages have dedicated method for each type so i would be in favor to have different methods too

The proto defines numeric integer metric values as signed 64-bit ints (sfixed64 in proto3). I think option 1 is most likely to be incorrectly handled by a backend (may be assumed to be a 64-bit int once it goes above 2^53 - 1).

@dyladan Would you mind clarifying why backends that support signed 64-bit ints can not handle resets from 2^53 - 1 to -(2^53 - 1)?

It may be interpreted as a 64 bit overflow not a 53 bit overflow as 53 bits is a weird time for integers to overflow.

I'd suggest introducing a series of APIs explicitly involved with the bigints, like meter.createBigIntCounter.

I like this idea. We actually don't need to overflow the regular counter at all if we do this because we can simply document that any int instrument that goes larger than Number.MAX_SAFE_INTEGER should use the bigint version

Would it be better to have a separate method or to have a ValueType.BIGINT?
Option 1
meter.createBigIntCounter("my_big_int_counter", { description, unit });

Option 2
meter.createCounter("my_big_int_counter", { description, unit, valueType: ValueType.BIG_INT });

I wonder which one would be preferable for for platform that doesn't support bigint ? specially old browser version or edge platform that use old engines ?
I personally prefer option 1 though

I wonder which one would be preferable for for platform that doesn't support bigint

I guess it depends what you want your fallback to look like. Would option 1 fail or return a regular int counter on platforms with no BigInt? If it returns a regular int counter then we are back to the complexity of an API that has to support multiple input types in order to support the fallback behavior.
For both options, we need to decide if we're going to allow BigInt as an input, or just use it as the internal representation. For me, option 1 means we have to allow it as an input. Option 2 keeps the same number-based API, but just changes the internal representation which makes the fallback easy (just use number). Using the number-based API, you would not be able to safely do a single add of more than 2^53, but that seems like a minor issue.

I guess it depends what you want your fallback to look like. Would option 1 fail or return a regular int counter on platforms with no BigInt? If it returns a regular int counter then we are back to the complexity of an API that has to support multiple input types in order to support the fallback behavior.

I would have suggested to make new functions for bigint that are optional in the API but its not great as UX

Would option 1 fail or return a regular int counter on platforms with no BigInt?

I would prefer a more explicit and fail-early approach for feature absence.

For both options, we need to decide if we're going to allow BigInt as an input, or just use it as the internal representation. For me, option 1 means we have to allow it as an input.

For both options, my idea is that their internal representation is what their name/flag suggests. I don't have a strong opinion on allowing numbers on bigint counters yet, but I'd find a naive start with no implicit conversion would be great.

Would option 1 fail or return a regular int counter on platforms with no BigInt?

I would prefer a more explicit and fail-early approach for feature absence.

So just use BigInt and it might throw. User is responsible for doing any feature detection?

Would option 1 fail or return a regular int counter on platforms with no BigInt?

I would prefer a more explicit and fail-early approach for feature absence.

So just use BigInt and it might throw. User is responsible for doing any feature detection?

Yeah, as we don't provide any polyfill for BigInt, I don't think we can do many things without BigInt support.

I did a little digging because I was curious how you would pass BigInt to the protocol buffers implementation. It looks like we are using protobuf.js implementation and the typescript stubs it generates look like this:
/** Properties of a NumberDataPoint. */
interface INumberDataPoint {
    // ....
    /** NumberDataPoint asDouble */
    asDouble?: (number|null);

    /** NumberDataPoint asInt */
    asInt?: (number|Long|null);
    // ....
}

the asInt variant accepts Long, which after doing a little digging seems to be from long.js, which is being pulled in as one of protobuf.js dependencies anyway.

Am I missing some way that protobuf.js already accepts BigInts? I couldn't verify if you can just pass a string. For OTLP JSON, I know you should use a decimal string.
I'm wondering if we've considered using Long instead of BigInt? Since we are limited to 64 bits in OTLP, we don't really need BigInt beyond that. Not sure how these two compare performance wise, but having BigInt as a builtin is certainly a pro. OTOH, long.js will be pulled in for anyone using the OTLP protobuf exporter anyway.

Would option 1 fail or return a regular int counter on platforms with no BigInt?

I would prefer a more explicit and fail-early approach for feature absence.

So just use BigInt and it might throw. User is responsible for doing any feature detection?

Yeah, as we don't provide any polyfills, I don't think we can do many things without BigInt support.

We wouldn't really need to provide polyfills. We could just accept number | BigInt for the counter APIs and do a simple typeof inp === 'number' check. If that check fails we assume we have a BigInt. For our own internal representation we would do a feature detection and fall back on number if BigInt was not available.

Whats the solution?


JAVA-2444

I forgot to mention a few things missing:

Please add an entry to the changelog.
Change the commit message to include the Jira ticket number and its title (note that I updated the title since it was a bit misleading).
Change the PR title before merging to also include: Jira ticket number + title.

Good points, @adutra .  I've added this change to the changelog (for some reason I consistently forget to do that) and have updated the title of this PR to include the JIRA title.  I'll do a squash merge once everything is addressed and update the commit message to be JIRA ID + title at that time.
I think... that covers everything?


[feature request] Support batch receive and ack

Motivation
You can refer to PIP-38.
Solution
We already support batch receive in the C++ client https://github.com/apache/pulsar-client-cpp/pull/21,  In the Node.js client side, we can wrap its interface for support.

Hi @shibd - was trying to give this a go and notice there are no methods regarding the new batching implementation in https://github.com/apache/pulsar-client-cpp/blob/main/lib/c/c_Consumer.cc
I was thinking the implementation would follow a similar pattern of calling methods found there in https://github.com/apache/pulsar-client-node/blob/master/src/Client.cc - am I completely off the mark?
Also would this implementation still require the use of ConsumerReceiveWorker? Thanks

was trying to give this a go and notice there are no methods regarding the new batching implementation in https://github.com/apache/pulsar-client-cpp/blob/main/lib/c/c_Consumer.cc

Yes, we need to support the batch receive method on the c interface first.

I saw that #357 was merged — I'm curious when the next release of the Nodejs Pulsar client might be? Or is there an outstanding todo for batch receive?
Thanks for all your contributions. 🙂

Looks like this just landed in v1.10.0. Thank you! We're eager to try it out and see performance benefits from the batching.


Local images not shown

Describe the bug
I am trying to integrate cross platform images in my tamagui app.
I started from create-tamagui-app, and now I am trying to add an Image component, so I added an assets folder to my app

Then inside my packages/app/features/home/screen.ts file I am trying to require it
const logo = require('../../assets/logo.png')`

and to render it with
<Image  style={{ width: 100, height: 100 }} source={{ uri: logo }}></Image>

or
<Image  style={{ width: 100, height: 100 }} source={{ logo }}></Image>

But there is no way to make it show up.
I also tried to import the Image component directly from react-native instead of tamagui without luck.
What is the proper way to render local assets?
Thank you
To Reproduce
Try to render a local image
System Info (please complete the following information):
System:
OS: macOS 12.6
CPU: (16) x64 Intel(R) Core(TM) i9-9880H CPU @ 2.30GHz
Memory: 22.40 MB / 16.00 GB
Shell: 5.8.1 - /bin/zsh
Binaries:
Node: 16.17.0 - /usr/local/bin/node
Yarn: 3.2.0 - ~/.nvm/versions/node/v16.17.0/bin/yarn
npm: 8.15.0 - ~/.nvm/versions/node/v16.17.0/bin/npm
Browsers:
Chrome: 105.0.5195.125
Firefox: 104.0.2
Safari: 16.0

Sorry @dividenconquer , it was just a copy/paste mistake, what you said is what I did

After further investigation I think it is a assets resolution problem:
if inside the native app, I return a component which renders an image located in the native project (eg: /apps/expo/src/assets) it works
if inside the shared project directory and add here an asset file, it doesn't work

In addition it doesn't work neither in the next js project

Hello @natew ,
I just installed the beta 177, there a lot of improvements and fixes, but the Image component keep working bad.
It works now on react native side, but the shared screen on the web doesn't show the image.
Could it be related to where assets are stored? where shared assets should be put in an app created by create-tamagui-app?

I also just tried from a fresh app created with create-tamagui-app, on the web there is no way to make the image show up.
Here you can find a repository with the bug reproduction, it's just a fresh tamagui app with an image added in /packages/app/features/home/screen.tsx

Hello @natew , any update on this?
At the moment, I ended up creating an Image.web.tsx and Image.native.tsx components, rendering next/image on web and  Image from tamagui on mobile.
There are some problems related to how next-js and react native handles images sizing, but it works for now.
In the attempt to understand what is causing the problem, I went through the source code and I found that your Image component just renders the Image component from react-native, but I'm not sure it is gonna work: if I use the react-native's Image component directly in the next-js app it doesn't work, so I was wondering if the actual implementation was supposed to work on both platforms.

Hey! Same problem with me. I tried putting my image in a folder inside packages/app/features/assets. It only renders the image on mobile. I have tested this with both Image components from 'tamagui' and 'react-native'. If the source is from the web then RN and Next app load the image normally.

@apperside it goes to react-native-web which handles the image.
I think this is an issue in the starter perhaps react native only allows images from within expo directory? If so the fix is just with the monorepo, you could maybe just move the app directory directly inside of expo and rename expo to app or something creative. Or perhaps there's some metro plugin or something.
But moving to discussion as the monorepo template could have infinite development, and we'd need a separate section or something for all those. Would happily accept a PR that works around this.


Deprecated CRDs still being installed by Istio 1.6.0

Bug description
(cluster)rbacconfigs and servicerole(binding)s CRDs still being added by Istio 1.6 installer (even with a fresh install).
The upgrade documentation mentions these CRDs are no longer used and can be removed.
Expected behavior
CRDs should not be added if these are deprecated and when documentation mentions these can be removed.
Steps to reproduce the bug
Do a fresh Istio 1.6 installation
Version (include the output of istioctl version --remote and kubectl version and helm version if you used Helm)
1.6.0
How was Istio installed?
istioctl install
Environment where bug was observed (cloud vendor, OS, etc)
GKE

I think this was removed in #23668 and missed the 1.6 release

I think this was removed in #23668 which didn't make 1.6

Right, the CRD is removed for 1.7 and I don't think we will backport it to 1.6.
The upgrade doc probably should be fixed to not to delete the RBAC CRD in 1.6 to avoid spamming the istiod logs, closing this one and addressing it in https://github.com/istio/istio/issues/24035.


fix: exit VHD release job when input is missing

https://msazure.visualstudio.com/CloudNativeCompute/_releaseProgress?_a=release-environment-logs&releaseId=44239&environmentId=538480


Updated "Formatting Code Automatically" section in Readme

Moved linting packages to dev dependencies

the build probably didn't fail because of the readme file...

These packages are intentionally installed as dependencies instead of dev dependencies. See: https://github.com/facebook/create-react-app/issues/2696


unable to save metrics: duplicate pod received

manager.go:127] unable to save metrics: duplicate pod podns/podname received
We have noticed when there is a duplicate pod, metric server skips storing metrics for the pods

https://github.com/kubernetes-incubator/metrics-server/blob/v0.3.5/pkg/manager/manager.go#L127

Further, the sink logic is from here https://github.com/kubernetes-incubator/metrics-server/blob/v0.3.5/pkg/provider/sink/sinkprov.go#L134
Previously reported issues:
https://github.com/kubernetes-incubator/metrics-server/issues/179
https://github.com/kubernetes-incubator/metrics-server/issues/186
It would be good to exclude duplicate pod check for the pod's node status is not ready, specifically if there is a container runtime issue, kubelet healthcheck goes down and the node becomes not ready, but the metric server still be able to scrape the cadvisor metrics. Often, user force deletes such pod to get the statefulset back in action.
Currently the only solution to find such nodes and fix the runtime issue. If this is not done the HPA reports false metrics which causes false scaling, sometimes no scaling which is a big issue.

@olagacek just checking are these issues being reviewed?

@sureshvis In metrics-server release 3.6 there is a change in sinkprov.go: https://github.com/kubernetes-incubator/metrics-server/blob/v0.3.6/pkg/provider/sink/sinkprov.go#L135
Duplicate pod is skipped, but metrics from the other pods are not skipped and stored. Does it solve your issue?

Release v0.3.6 should resolve it, please re-open if you still have this issue.


Make the pf_reqs field of ContextBuilder public.

Its type PixelFormatRequirements is already public with public fields.

This field was made private on purpose, although I don't remember why :-/

According to https://github.com/tomaka/glutin/pull/608 it's because the members of PixelFormat were not considered stable that the time.

According to https://github.com/tomaka/glutin/blame/209ab925f5325c35b8c35020e2d9a85f519f84c3/src/lib.rs#L817 the struct members have not changed in 3 years.

@jdm thanks for investigating this!
@SimonSapin are you still interested in this?

Yes, this would allow fixing a bug in some code in WebRender’s Wrench, even though nothing happens to "exercise" that bug at the moment.
This was for https://github.com/servo/webrender/pull/2529 where I forked some of Glutin’s src/api/egl/mod.rs in order to create an (E)GL context, but with statically-linked ANGLE. So this code receives ContextBuilder as a parameter, and needs to access its details.
The work-around was to use PixelFormatRequirements::default(), which was ok because the only user of this code happened not to use any ContextBuilder API that would change the pixel format requirements from the defaults.
Forking this EGL code would not be necessary in the first place if Glutin itself could support statically-linked EGL/ANGLE. I attempted that in https://github.com/tomaka/glutin/pull/998, but it resulted in an awkward public API.

Okay, cool. I'm not opposed to this, so provided you add a CHANGELOG entry we can merge this.


Simulon support

Context:
To improve StarshipEngine to allow for multiple backends when sending remote jobs.
Description of the Change:
Benefits:
Possible Drawbacks:
Related GitHub Issues:

@zzzeid is this one needing a review?

@co9olguy yes that is correct.

This PR should be merged into demo ASAP, to decouple StarshipEngine from chip0.


feat: Added D1 Support

This is a continuation of #270.
@FlareLine made the following statement the existing PR:

I'd be more than happy if you wanted to contribute some more tests to the PR - I've unfortunately come down with something so haven't had time to come back to this.

I made a PR on his fork, but it haven't had a response.  I'll see if I can moe this PR along and would be happy to close this PR if they can come back.
Summary
These changes add D1 support to the worker create, resolving #221.
I've added some integration tests to worker-sandbox and left a few comments to see how to proceed. @zebp let me know your thoughts and thank you for your time.

Hey @logankeenan! I've just commented on the original PR - I would be happy to merge these changes into the main PR if you're happy with that? I believe there's still some conversations going on with the D1 team, which is why the PR hasn't been merged / worked on recently.

Hey @logankeenan! I've just commented on the original PR - I would be happy to merge these changes into the main PR if you're happy with that? I believe there's still some conversations going on with the D1 team, which is why the PR hasn't been merged / worked on recently.

That sounds good to me, thank you!


helm fetch from local repo should not require an HTTP server

Currently helm fetch requires an HTTP server to be running even for local charts in ~/.helm.
Not a deal breaker - but it would make development less painful if you did not have to run helm serve

@technosophos Is this satisfied by the new local file path requirement?

How would this look from a user's point of view? helm fetch /tmp/charts/mychart.tar.gz --untar would untar the chart into your local directory as mychart/?
I'm not completely sure what the use case for this would be that cp or tar -xf can't already solve for local dev. If it's for the chart requirements, then yes the local file path requirement should suffice.

"requirements.yaml can reference and fetch charts from subdirectories"
Do you have an example?


🐛 [BUG] - GAnalytics and Discord links

Hey, I'm happy to see Velociraptor's docs theme used elsewhere!
Could you please update the Discord invite link and Google Analytics tracking ID though? They're still pointing to vr's instances so our tracking data is being mixed with yours and disoriented Discord users are coming to our server 😄
Thanks!

No worries @jabinb, thanks for the quick response! 🙂


Parameter Value Error Overlap

When having a parameter instance with a Validation and it's not met, the outline of the box's red outline is covered by a row below. (Sorry for bad explaining, see below);

it works fine when you select it;

Scope:Map {
	Header = { Text = "Parameters" },
	Sections = {
		{ Key = "Scale", Value = { Text = "0", Validation = "%d+" } },
		{ Key = "Name", Value = "CoolName" } :: any,
		{ Key = "Type", Value = "MyType" } :: any,
	}
},

hey i didnt see this issue until now. That definitely isn't right.


requirements.txt refactor

I refactored requirements.txt so that it can be installed with a single pip install --upgrade -r requirements_[cpu,gpu].txt command for the different environments we have.

pulled the Tensorflow CPU and GPU binaries into separate requirements_cpu.txt and requirements_gpu.txt files which inherit from requirements_base.txt, so you just pick either cpu or gpu to install
pinned versions for shapely, tflearn, and h5py
added missing entries for pyosmium, requests, and s3cmd

Great, I had meant to figure out how to deal with this.


Fixes for #442 and #443

This PR contains cosmetic fixes to the HTML report, the most important of which is because the match object's keys are now Uppercase, and the appinspector.js file had references to them all in lowercase, so it was causing the UI to break.

/azp run

Nice catch Mike.


fix: makefile comment highlighting

In makefiles comment lines starting with a tabulation are not highlighted, here is a fixed regex

This PR fixes #

Thanks for your PR!
Can you post a before/after screenshot?
Thanks!

Hey there,
According to @zephvr's research, "\t" and "    " don't have the exact same meaning:
build:
 \t # Say "Hello World!"
 \t @echo "Hello World!"

outputs
$ make
# Say "Hello World!"
Hello World!

whereas
build:
    # Say "Hello World!"
 \t @echo "Hello World!"

outputs
$ make
Hello World!

and finally
build:
    # Say "Hello World!"
    @echo "Hello World!"

outputs
$ make
Makefile:3: *** missing separator.  Stop.

Therefore, "[\t]+#" comments are shell-comments and "[ ]*#" comments are makefile-comments.
Should the two kinds of comments be colored differently?
Shell comments:

Makefile comments (and all comments after merging):

Note: This behavior is not well-documented, but there is an explanation on https://stackoverflow.com/a/2131227
Note 2: Should the .RECIPEPREFIX variable be handled?

Ok, this is more complex than I thought - thanks for the explanation!
Can you please open an issue and post your explanation there again?
That way, we can separate the discussion for the fix from the discussion of the problem.
Thanks!

Therefore, "[\t]+#" comments are shell-comments and "[ ]*#" comments are makefile-comments.

But doesn't this mean that this PR is invalid?

But doesn't this mean that this PR is invalid?

I think so, the difference between colors is a visual hint that something is wrong with the comment

I agree with @GauBen I will close this PR


Not able to deploy  EnterpriseAWSSSOPipelineStack

Hi team, i am trying to run this command cdk deploy EnterpriseAWSSSOPipelineStack  but this shows error.
Attaching screenshot here.

apologies, this was missed.
the error is happening because cdk.json has been updated to point to app.py instead of cdkpipelines_app.py. this mistake is now fixed and will soon be merged back into the main branch

fix has been merged.


lxc exec continues to run after container is deleted

Required information

Distribution: Ubuntu
Distribution version: 22.04.1
LXC Info attached

Issue description
LXD container was started as part of a charmcraft pack command.  This resulted in the following command being executed in a container (note command is from the host)
lxc --project charmcraft exec local:charmcraft-osm-nbi-3875820-0-0-amd64 -- env PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/snap/bin CHARMCRAFT_MANAGED_MODE=1 systemctl is-system-running

I exec'd into the container and did not see that command running:
USER         PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root           1  0.0  0.0 168852  7340 ?        Ss   Apr01   0:02 /sbin/init
root          37  0.0  0.0  35296  6784 ?        Ss   Apr01   0:00 /lib/systemd/systemd-journald
root          53  0.0  0.0  21620  2928 ?        Ss   Apr01   0:00 /lib/systemd/systemd-udevd
root          58  0.0  0.0   3640  1088 ?        Ss   Apr01   0:00 snapfuse /var/lib/snapd/snaps/charmcraft_1171.snap /snap/charmcraft/1171 -o ro,nodev,allow_other,suid
root          60  0.0  0.0   3508  1060 ?        Ss   Apr01   0:00 snapfuse /var/lib/snapd/snaps/core20_1852.snap /snap/core20/1852 -o ro,nodev,allow_other,suid
root          61  0.0  0.0   3736  1344 ?        Ss   Apr01   0:03 snapfuse /var/lib/snapd/snaps/snapd_18596.snap /snap/snapd/18596 -o ro,nodev,allow_other,suid
systemd+      64  0.0  0.0  26808  4972 ?        Ss   Apr01   0:01 /lib/systemd/systemd-networkd
systemd+      98  0.0  0.0  24160  9108 ?        Ss   Apr01   0:01 /lib/systemd/systemd-resolved
message+     102  0.0  0.0   7000  2272 ?        Ss   Apr01   0:00 /usr/bin/dbus-daemon --system --address=systemd: --nofork --nopidfile --systemd-activation --syslog-only
root         104  0.0  0.0 1984216 25812 ?       Ssl  Apr01   0:23 /usr/lib/snapd/snapd
root         105  0.0  0.0  16856  4704 ?        Ss   Apr01   0:00 /lib/systemd/systemd-logind
root         122  0.0  0.0   4392  1064 pts/0    Ss+  Apr01   0:00 /sbin/agetty -o -p -- \u --noclear --keep-baud console 115200,38400,9600 vt220
root        1103  0.0  0.0   6000  2604 pts/1    Ss   16:11   0:00 bash
root        1106  0.0  0.0   7648  1936 pts/1    R+   16:11   0:00 ps auxww

I force deleted the container
xargs lxc delete --force --project charmcraft charmcraft-osm-nbi-3875820-0-0-amd64

Yet the lxc exec command remains:
jenkins  1237595  0.1  0.1<PHONE_NUMBER>0 ?        Sl   Apr01   6:21  |           |       \_ /snap/charmcraft/1171/bin/python3 -u /snap/charmcraft/1171/bin/charmcraft pack --format json --verbosity brief
jenkins  1250132  0.0  0.0 1614104 11824 ?       Sl   Apr01   0:30  |           |           \_ lxc --project charmcraft exec local:charmcraft-osm-nbi-3875820-0-0-amd64 -- env PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/snap/bin CHARMCRAFT_MANAGED_MODE=1 systemctl is-system-running

lxc-info.txt

Please can you advise the lxd version?

Oh you snuck it in at the bottom :)

Can you show the hosts process list when this occurs please?

ps fauxw: https://paste.ubuntu.com/p/gwRjZXQS6y/

To be clear: the lxc exec command is still running.  The container is not - it has been deleted

Nothing useful from strace either
jenkins@osm-cicd-3:~$ sudo strace -p 1250132
strace: Process 1250132 attached
futex(0x12aeb88, FUTEX_WAIT_PRIVATE, 0, NULL

Attempted to get a stack trave via gdb, but it looks like lxc being a snap, symbols are all not readable
(gdb) bt
#0  0x000000000046cb23 in ?? ()
#1  0x0000000000434876 in ?? ()
#2  0x00000000012aeb88 in __bss_start ()
#3  0x0000000000000080 in ?? ()
#4  0x0000000000000000 in ?? ()

Thanks!

The build system is once again in this state, although I will have to clean it in order to allow upstream OSM builds to continue.
From the host running LXD, a ps shows this
jenkins  2535554  0.0  0.0   2888  1004 ?        S    08:48   0:00  |           \_ sh -c echo $$ > '/home/jenkins/workspace/devops-stage_2-merge_v13.0@2/installers/charm/osm-ng-ui@tmp/durable-7107b688/pid'; jsc=durable-8006a5ee6d68877407a2a9defca6baca; JENKINS_SERVER_COOKIE=$jsc '/home/jenkins/workspace/devops-stage_2-merge_v13.0<EMAIL_ADDRESS>> '/home/jenkins/workspace/devops-stage_2-merge_v13.0<EMAIL_ADDRESS>2>&1; echo $? > '/home/jenkins/workspace/devops-stage_2-merge_v13.0<EMAIL_ADDRESS>jenkins  2535568  0.0  0.0   2888   996 ?        S    08:48   0:00  |               \_ /bin/sh -xe /home/jenkins/workspace/devops-stage_2-merge_v13.0<EMAIL_ADDRESS>jenkins  2535570  0.1  0.1<PHONE_NUMBER>8 ?        Sl   08:48   0:51  |                   \_ /snap/charmcraft/1171/bin/python3 -u /snap/charmcraft/1171/bin/charmcraft pack --format json --verbosity brief
jenkins  2551868  0.0  0.0 1614104 13424 ?       Sl   08:48   0:04  |                       \_ lxc --project charmcraft exec local:charmcraft-osm-ng-ui-4422700-0-0-amd64 -- env PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/snap/bin CHARMCRAFT_MANAGED_MODE=1 systemctl is-system-running

So the host is waiting for this command to finish:
lxc --project charmcraft exec systemctl is-system-running
Running the command from the host CLI works, the command completes quickly.  Exec'ing into the container shows that the command exited already:
lxc --project charmcraft exec local:charmcraft-osm-ng-ui-4422700-0-0-amd64 -- env PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/snap/bin CHARMCRAFT_MANAGED_MODE=1 bash

ps auxww

USER         PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root           1  0.0  0.0 168848  7388 ?        Ss   08:48   0:00 /sbin/init
root          37  0.0  0.0  35300  7220 ?        Ss   08:48   0:00 /lib/systemd/systemd-journald
root          53  0.0  0.0  21620  2924 ?        Ss   08:48   0:00 /lib/systemd/systemd-udevd
root          59  0.0  0.0   3508   996 ?        Ss   08:48   0:00 snapfuse /var/lib/snapd/snaps/core20_1852.snap /snap/core20/1852 -o ro,nodev,allow_other,suid
root          60  0.0  0.0   3640  1080 ?        Ss   08:48   0:00 snapfuse /var/lib/snapd/snaps/charmcraft_1171.snap /snap/charmcraft/1171 -o ro,nodev,allow_other,suid
root          61  0.0  0.0   3740  1328 ?        Ss   08:48   0:03 snapfuse /var/lib/snapd/snaps/snapd_18596.snap /snap/snapd/18596 -o ro,nodev,allow_other,suid
systemd+      66  0.0  0.0  26808  5152 ?        Ss   08:48   0:00 /lib/systemd/systemd-networkd
systemd+      99  0.0  0.0  24160  9220 ?        Ss   08:48   0:00 /lib/systemd/systemd-resolved
message+     102  0.0  0.0   7000  2328 ?        Ss   08:48   0:00 /usr/bin/dbus-daemon --system --address=systemd: --nofork --nopidfile --systemd-activation --syslog-only
root         104  0.0  0.1 1983512 36108 ?       Ssl  08:48   0:04 /usr/lib/snapd/snapd
root         105  0.0  0.0  16856  4708 ?        Ss   08:48   0:00 /lib/systemd/systemd-logind
root         122  0.0  0.0   4392  1144 pts/0    Ss+  08:48   0:00 /sbin/agetty -o -p -- \u --noclear --keep-baud console 115200,38400,9600 vt220
root         328  0.0  0.0   6000  2684 pts/1    Ss   16:38   0:00 bash

So what I see is the command executed inside the container and completed, but it looks like a lxc exec bug where it is not getting notified of command completion and the host command hangs indefinitely.  In fact, to make things worse, the container can be terminated, and the command still hangs on.  For example, this command is still running on the host:
lxc --project charmcraft exec local:charmcraft-osm-grafana-2591404-0-0-amd64 -- env PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/snap/bin CHARMCRAFT_MANAGED_MODE=1 ln -sf /run/systemd/resolve/resolv.conf /etc/resolv.conf

But the container is terminated, and trying to execute that command again on the host gives a clear "Error: Instance is not running".

Let's find out if the lxc command is blocking on the server by reloading the lxd service when it occurs next. If that unblocks it we know it was connected to the server and waiting for something there.

Issued systemctl reload snap.lxd.daemon.  Process is still stuck in the same state.
jenkins@osm-cicd-2:~$ sudo systemctl reload snap.lxd.daemon
jenkins@osm-cicd-2:~$ ps auxwwf | grep charm
jenkins  1804850  0.0  0.0   2888   976 ?        S    Apr08   0:00  |           \_ sh -c echo $$ > '/home/jenkins/workspace/devops-stage_2-merge_v13.0/installers/charm/prometheus@tmp/durable-680e06c1/pid'; jsc=durable-46e99575e515557aa80548b67e70ab52; JENKINS_SERVER_COOKIE=$jsc<EMAIL_ADDRESS>><EMAIL_ADDRESS>2>&1; echo $? ><EMAIL_ADDRESS>jenkins  1804852  0.0  0.0   2888   964 ?        S    Apr08   0:00  |           |   \_ /bin/sh -xe<EMAIL_ADDRESS>jenkins  1804853  0.1  0.1<PHONE_NUMBER>8 ?        Sl   Apr08   6:10  |           |       \_ /snap/charmcraft/1171/bin/python3 -u /snap/charmcraft/1171/bin/charmcraft pack --format json --verbosity brief
jenkins  2964796  8.0  0.0 1096060 15084 ?       Sl   17:39   0:00  |           |           \_ lxc --project charmcraft exec local:charmcraft-osm-prometheus-2591944-0-0-amd64 -- env PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/snap/bin CHARMCRAFT_MANAGED_MODE=1 getent hosts snapcraft.io
jenkins  2535554  0.0  0.0   2888  1004 ?        S    08:48   0:00  |           \_ sh -c echo $$ > '/home/jenkins/workspace/devops-stage_2-merge_v13.0@2/installers/charm/osm-ng-ui@tmp/durable-7107b688/pid'; jsc=durable-8006a5ee6d68877407a2a9defca6baca; JENKINS_SERVER_COOKIE=$jsc '/home/jenkins/workspace/devops-stage_2-merge_v13.0<EMAIL_ADDRESS>> '/home/jenkins/workspace/devops-stage_2-merge_v13.0<EMAIL_ADDRESS>2>&1; echo $? > '/home/jenkins/workspace/devops-stage_2-merge_v13.0<EMAIL_ADDRESS>jenkins  2535568  0.0  0.0   2888   996 ?        S    08:48   0:00  |               \_ /bin/sh -xe /home/jenkins/workspace/devops-stage_2-merge_v13.0<EMAIL_ADDRESS>jenkins  2535570  0.1  0.1<PHONE_NUMBER>0 ?        Sl   08:48   0:57  |                   \_ /snap/charmcraft/1171/bin/python3 -u /snap/charmcraft/1171/bin/charmcraft pack --format json --verbosity brief
jenkins  2964845 11.0  0.0 1096060 15176 ?       Sl   17:39   0:00  |                       \_ lxc --project charmcraft exec local:charmcraft-osm-ng-ui-4422700-0-0-amd64 -- env PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/snap/bin CHARMCRAFT_MANAGED_MODE=1 systemctl is-system-running
jenkins  2965040  0.0  0.0   7004  2104 pts/0    S+   17:39   0:00              \_ grep --color=auto charm
root     1807694  0.0  0.0 5338012 15492 ?       Ss   Apr08   0:00 [lxc monitor] /var/snap/lxd/common/lxd/containers charmcraft_charmcraft-osm-prometheus-2591944-0-0-amd64
jenkins  1808867  0.0  0.0   3640  1056 ?        Ss   Apr08   0:00      \_ snapfuse /var/lib/snapd/snaps/charmcraft_1171.snap /snap/charmcraft/1171 -o ro,nodev,allow_other,suid
root     2546835  0.0  0.0 5338012 15648 ?       Ss   08:48   0:00 [lxc monitor] /var/snap/lxd/common/lxd/containers charmcraft_charmcraft-osm-ng-ui-4422700-0-0-amd64
jenkins  2547740  0.0  0.0   3640  1080 ?        Ss   08:48   0:00      \_ snapfuse /var/lib/snapd/snaps/charmcraft_1171.snap /snap/charmcraft/1171 -o ro,nodev,allow_other,suid

I stand corrected.  After an arbitrary amount of time (well, basically within 5 minutes as that was when I last checked), the lxc exec must have completed, and the rest of the charmcraft pack actually finished without errors after hanging for 2 days:
https://osm.etsi.org/jenkins/job/devops-stage_2-merge/job/v13.0/48/console

That sounds like there is a LXD server side operation being held open which is keeping the lxc process running and will also prevent LXD from reloading for up to 5 minutes (the default value of core.shutdown_timeout https://linuxcontainers.org/lxd/docs/master/server/).
It would be good if you can get the debug server logs when this occurs by configured LXD as follows before it happens:
sudo snap set lxd daemon.debug=true; sudo systemctl reload snap.lxd.daemon

And then send the contents of:
/var/snap/lxd/common/lxd/logs/lxd.log

After it has got stuck.
Also the next time it gets stuck can you show the output of lxc operation list, thanks.

Worth noting that we've seen cases of lxc exec hanging around like that without any reason on the LXD side.
Instead what was happening was that lxc exec was stuck waiting on its stdin, not stuck waiting on LXD. This can happen in some CI systems where stdin for some reason isn't /dev/null (as it ought to be for non-interactive workloads).

Unfortunately I did not get daemon.debug=true set.  However, I do have the output of the curl.  Here is what is running on the host:
jenkins  2229342  0.0  0.0 1540332 16244 ?       Sl   08:52   0:04 /snap/lxd/24758/bin/lxc --project charmcraft exec local:charmcraft-mysqld-exporter-k8s-4404246-0-0-amd64 -- env PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/snap/bin CHARMCRAFT_MANAGED_MODE=1 systemctl is-system-running

lxc operation list shows nothing in progress.
pprof.txt
ps.txt

Thanks, this part will be interesting to know:

Also the next time it gets stuck can you show the output of lxc operation list, thanks.

Your pprof output shows a few go routines waiting on events, which may be stuck operations, but would be good to see that operations list while the command is still stuck before its released after 5 minutes.

Ah, unfortunately we don't know it's stuck until long after when the job takes too long to complete.

It's stuck again, but did not catch it in time.  lxc operation list shows nothing again

lxd.log.gz
LXD log from today.  Issue occurred sometime between 15:00 and 16:00 UTC

Does this still occur with lxd 5.14, as it has a new websocket implementation.

Hi @markbeierl are you still experiencing this with lxd 5.15?

Are you able to try with latest/candidate (which is LXD 5.16)?

@markbeierl any news on this one? Did you find the issue remains? Thanks

Hi @markbeierl I am going to close this one now as we've not heard from you.
However if you do experience this again on LXD latest/stable, 5.0/stable or 5.21/stable please let us know. Thanks!


Handle promises?

Hi, This library is almost perfect for my needs but I need the rows to render different content after resolving a promise... testing this with a simple setTimeout within the renderRow function seems to work for initial load but not after scrolling.... I'm guessing this might have something to do with the dom diffing?
Any suggestions?

I think I found a solution by adding a unique ID to the elements upon initial render then using jquery to search/select for that id if it still exists after the promise/timeout resolves.


Add external-logical-cluster-admin

Currently the logical cluster admin kubeconfig is used to access both the external front-proxy endpoint, and also the shard directly via the baseURL - this won't work in the case where different CA certs are used for shard and front-proxy such as in the templates maintained in this repo.
Requires https://github.com/kcp-dev/kcp/pull/2882
Fixes: #32

/hold
hold until https://github.com/kcp-dev/kcp/pull/2882 merges

https://github.com/kcp-dev/kcp/pull/2882 now merged, and this has been updated after debugging an issue with the new client cert (thanks @s-urbaniak for the help) - I think this should be ready for review now and it's working fine for me using the latest main KCP image


Respect EnumMemberAttribute value when converting enums

The query language's enum type conversion currently ignores EnumMemberAttribute values, if they are present.
For instance, given an enum:
public enum TestEnum
{
    [EnumMember(Value = "MY_VALUE")]
    MyValue
}

Currently, the value can be accessed via "MyValue" case insensitively, e.g. myField == "myvalue".
However, the enum can not be accessed via its EnumMemberAttribute value - myField == "MY_VALUE" does not work.
Do we want to support the EnumMemberAttribute value when converting enum values? If so, I would be willing to provide a PR.

You can try to make a PR.

Hello,
I will close this issue, I'm not sure if a pull has been provided or not.
If no pull has been provided, we will be happy to merge it
Best Regards,
Jon

Performance Libraries
context.BulkInsert(list, options => options.BatchSize = 1000);
Entity Framework Extensions • Entity Framework Classic • Bulk Operations •  Dapper Plus
Runtime Evaluation
Eval.Execute("x + y", new {x = 1, y = 2}); // return 3
C# Eval Function • SQL Eval Function


Federation should use namespace scoped service accounts to talk to underlying clusters

 Issue by nikhiljindal
Friday Apr 21, 2017 at 00:43 GMT
Originally opened as https://github.com/kubernetes/kubernetes/issues/44743

Background: Federation today uses a single identity to send all its requests to a cluster. This requires that single identity to have the authorization to do everything that federation is being used for.
For ex: if 2 teams are using federation to federate resources in 2 namespaces, they need to create a service account for federation that has CRUD access to both namespaces. This single service account becomes more powerful then the service accounts of each teams (which have access to only a single namespace). This is not good.
Solution:
A way to fix this is by updating federation to accept multiple service accounts (one per namespace) instead of only a single one. Federation will then use the corresponding service account while sending requests in that namespace.
Things I need to figure out:

How will create federated namespace work?
How to give federation access to service accounts? Pass the token? Does deleting the service account revoke it?
Are SA's namespaced by default?
Does editor on namespace include authorization to CRUD SA in that ns?

Filing this early while I figure out the details to get any high level feedback early.
cc @kubernetes/sig-auth-misc @kubernetes/sig-federation-feature-requests @erictune @smarterclayton @liggitt

 Comment by ericchiang
Friday Apr 21, 2017 at 00:47 GMT

I drew up some RBAC roles yesterday in attempt to limit the federated credentials to a couple namespaces: https://gist.github.com/ericchiang/dfdfcf092c4c66ff9215b217e19ed5a7
I don't think it's strictly necessary to support multiple service accounts. You should be able to create one then give it access to the target namespaces.
Maybe that's relevant to this conversation?

 Comment by nikhiljindal
Friday Apr 21, 2017 at 00:57 GMT

Who will create this service account that has access to both the namespaces?
If a team has access to only one namespace, can they create a service account that has access to more than that namespace?

 Comment by liggitt
Friday Apr 21, 2017 at 01:05 GMT

If they have the ability to grant access to a service account at all, they could do so for a single service account across both namespaces.

 Comment by nikhiljindal
Monday Apr 24, 2017 at 06:23 GMT

Yes you are right. I still need to grant access to the service account after creating it. I assumed creating an SA in a namespace gives that SA access to the namespace it is in by default. But as you said thats not true.

 Comment by nikhiljindal
Monday May 01, 2017 at 21:56 GMT

@ericchiang Realized that restricting the federation credentials to specific namespaces wont work (controllers assume that they have access to all namespaces). Filed https://github.com/kubernetes/kubernetes/issues/45189 to fix that.

 Comment by fejta-bot
Monday Jan 08, 2018 at 17:25 GMT

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
Prevent issues from auto-closing with an /lifecycle frozen comment.
If this issue is safe to close now please do so with /close.
Send feedback to sig-testing, kubernetes/test-infra and/or @fejta.
/lifecycle stale

cc @nikhiljindal


Bump to 17.4.1

Minor version bump to get n times for Publishing API test helpers.

I think this should be 17.5.0 as you've added functionality in a backwards compatible manner: http://semver.org/

I'll close this and reopen with a new branch then.


better cli help

Could the bin possibly use yargs to document commands and options? I would be happy to help make this happen, just want to make sure that this type of update would be accepted as a pull request. My thought is that yargs does a really nice job of self documenting commands and options and the current '-h' help option is pretty lacking.

@GuidoS I agree with you completely about the poor --help output. We've been meaning to switch to commander for a while but haven't gotten around to it. Would you be willing to do that instead of yargs?

Since October in fact! https://github.com/tessel/t2-cli/issues/356

I would like to convince you that yargs is a better choice:

It's a more  active a project (last updated 19 days ago) (from npmcompare)
it's got json argument passing, similar to what you have already done in nomnom

nomnom
    .option('timeout', {
        abbr: 't',
        metavar: 'TIMEOUT', // not sure what this is for?
        help: 'Set timeout in seconds for scanning for networked tessels',
        default: 5
    })

commander
  .option('-t, --timeout', 'Set timeout in seconds for scanning for networked tessels')
  // no default options

yargs
  .option('size', {
    alias: 't',
    describe:'Set timeout in seconds for scanning for networked tessels',
    default: 5
  }

I have used yargs on other projects and it is very newb friendly
Pirate themed, but no actual pirates (cause real pirates were frightening and not fun)

Sounds reasonable to me! :+1:

To be clear, if i spend the time making this update, and it works, you can
assure me that it will be accepted?
On Sun, May 1, 2016, 7:19 AM Jon<EMAIL_ADDRESS>wrote:

Sounds reasonable to me! [image: :+1:]
—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
https://github.com/tessel/t2-cli/issues/722#issuecomment-216035553

Yeah, I am okay with it but I don't have much experience with yargs. @rwaldron or @LinusU or @Frijol or @HipsterBrown might have more experience and thus objections. I'd say wait 24 hours and if you don't hear any dissent from them, we're good to go.

I believe we were looking to switch to commander because of deprecation notice in the nomnom repo. Based on @GuidoS's reasoning, it looks like yargs would be an easier transition and more approachable for new contributors. :+1: for the update.

I've only ever used meow, but if Sindre recommends yargs (https://github.com/tessel/t2-cli/issues/356#issuecomment-146196189), then I say that would be good enough for us. 👍

Re: metavar... https://github.com/harthur/nomnom#metavar

@guido since nobody has strong opinions, let's move forward with 'yargs'.

OK, I will get going on this next week, I'm slammed right now...

I am new to contributing code with these community tools. I have setup a branch on my personal fork and am working there:
https://github.com/GuidoS/t2-cli/tree/bin-yargs-integration
Once I have the functionality fully functional I will do a pull request. Is this the correct way to do this? Is there a CONTRIBUTE.md somewhere?

Yes, it is just in a different repo: https://github.com/tessel/project/blob/master/CONTRIBUTING.md
And then you will also need to sign the CLA.

I have signed it ;)
On Fri, May 13, 2016, 8:05 AM Neil Kistner<EMAIL_ADDRESS>wrote:

Yes, it is just in a different repo:
https://github.com/tessel/project/blob/master/CONTRIBUTING.md
And then you will also need to sign the CLA
http://dojofoundation.org/about/claForm.
—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
https://github.com/tessel/t2-cli/issues/722#issuecomment-219025115

@GuidoS were you able to make any progress on this?

@johnnyman727 @GuidoS I'm a little biased, so not going to make too noisy of a pitch for yargs. But, I'm here to help if you need me.

This has been back burnered for me. I will make some time this weekend to get the ball rolling and would be happy to get support from others.

looks like this was deprecated, so I will happily close this.


 Likely, the proposal has been finalized (check 'vscode.d.ts') or was abandoned.
log.js:236 CRITI Extension 'vscode.vscode-api-tests' wants API proposal 'notebookEditorEdit' but that proposal DOES NOT EXIST. Likely, the proposal has been finalized (check 'vscode.d.ts') or was abandoned

There is actually still this one:
Extension 'vscode.vscode-api-tests' wants API proposal 'notebookEditorEdit' but that proposal DOES NOT EXIST. Likely, the proposal has been finalized (check 'vscode.d.ts') or was abandoned.

@rebornix @roblourens ?

Fixed


New version: Grassmann v0.1.4

Registering package: Grassmann
Repository: https://github.com/chakravala/Grassmann.jl
Created by: @chakravala
Git reference: register/Grassmann/v0.1.4
Version: v0.1.4
Commit: 33060499ebfafc9ea5fcdce9169612c4d27ad57c
Reviewed by: @chakravala
Reference: https://github.com/chakravala/Grassmann.jl/commit/33060499ebfafc9ea5fcdce9169612c4d27ad57c#commitcomment-33526017

Can you add
[compat]
julia = "1"

?

If I need to re-commit, then I'm gonna work on some performance improvements first before retagging

@fredrikekre What is the correct way to re-enable coveralls submit? I have updated my .travis.yml but it only submits to codecov now

I mean, you are calling Codecov.submit so why would it submit to something else? https://github.com/chakravala/Grassmann.jl/blob/33060499ebfafc9ea5fcdce9169612c4d27ad57c/.travis.yml#L16

Can Coveralls.submit go on the same line, or does it need to run separately?

I don't know, look at some other packages.

The compat issue is now fixed, along with some type-stability fixes, so this should be ready now

Consider enabling TagBot to make sure the release is persistent in your repo, see https://discourse.julialang.org/t/ann-tagbot-creates-tags-and-releases-for-your-julia-packages-when-theyre-registered/23084


feat: redirect to 500px service

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


[Web] EventKit

Description
Creates an EventKit like the BrandKit.

use markdown files for content

59 change files of which

21 markdown files
9 snapshot files
20 ts / tsx files

Tested
manually Confirmed that changes to existing page tests did not result in visual regressions.
new

Related issues

Fixes https://github.com/celo-org/celo-labs/issues/457
fixes https://github.com/celo-org/celo-labs/issues/456
fixes https://github.com/celo-org/celo-labs/issues/455
fixes https://github.com/celo-org/celo-labs/issues/460
fixes https://github.com/celo-org/celo-labs/issues/458
fixes https://github.com/celo-org/celo-labs/issues/459
fies https://github.com/celo-org/celo-monorepo/issues/3690

Backwards compatibility
brand new

Looks good, just a few nits.
Is this the record for most tickets closed with a single PR?

possibly?


Outputs in created transactions gets removed

Hi i just tried to make a transaction with coinb.in .

As you can see the outputs of the transaction get removed.

That's because your address is invalid. So you are not generating any outputs.

One way you can tell this is that if you had created a valid output with 4.99999950 BTC to it, you would see the pattern ce64cd1d00000000 before the output.
Since you don't see this pattern, nowhere in the tx does it refer to "4.99999950 BTC"

Also your input seems to be weird... you might be inserting the incorrect information for the "Address, WIF key or Multisig Redeem Script" part as well.

Hi i am using testnet addresses in that the problem?
I am not using the "Address, WIF key or Multisig Redeem Script" part as i dont know how to use it.
It have worked fine before.
The output address is not invalid , from my bitcoin core testnet:
￼
validateaddress n1yrPA1kpyrndJ98yR7PtbvdFsjer84UoP
{
"isvalid" : true,
"address" : "n1yrPA1kpyrndJ98yR7PtbvdFsjer84UoP",
"ismine" : true,
"isscript" : false,
"iscompressed" : true,
"account" : ""
}
Is it because the address is compressed?
I will try to make a new transaction:
from txid: 38b262280c88b6ef02a6414b2bccc488687ea3d10a538cc47b600297b23fe14d

Txid: 38b262280c88b6ef02a6414b2bccc488687ea3d10a538cc47b600297b23fe14d
N:0
Script: eaf5647755757e9710eb0cbd4f0e2e28bd76ca5a

As you can see, the same result.

Nope, it's not because it is compressed. It is because it is testnet.
Unfortunately, coinbin is not testnet enabled.

Ok Its good to know what the problem is. But i have been able too do this before without problem back when i told you about the lack of testnet support. I want to use your solution because it is easier than bitcoin core client and but i don't want to have to use real bitcoin to test different types of transactions.

Testnet isnt supported, yet. Please read this post https://github.com/OutCast3k/coinbin/issues/2#issuecomment-96614487


missing a word/phrase?

Under the Authoring, design, and branding in SharePoint section, I think there is something missing after the word "any" in the following sentence:
The content-creation workflow is revised so that you can create content using any —and author great content.

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

ID: 0058942b-7257-da9b-e294-70966abed977
Version Independent ID: df4bb886-a309-ec22-3e80-840bfe3ee5d7
Content: Build sites for SharePoint
Content Source: docs/general-development/build-sites-for-sharepoint.md
Product: sharepoint
GitHub Login: @spdevdocs
Microsoft Alias: spdevdocs

Hi,ttplaya. Thanks for your post. Relevant guys will research this and update the docs later.


"Signature verification raised", yet jwt.io says "Signature Verified"

Hey
Having an odd issue that I cannot seem to replicate very easily.
token = "eyJhbGciOiJIUzI1NiJ9.eyJkYXRhIjp7InVzZXJfaWQiOjEsInZlcmlmaWVyIjoiM2ExZGNlODItN2YwNC00Mjk1LTljN2QtYzUzYmQ4OGVjNTI3In0sImV4cCI6MTYxMTYyMjMxOH0.7HYR9jAsNeOjQFGGbmUBNalOqmUeLRK9eMldMjGQo38"

secret = "c61a64edec22c03a25f3b984910ac2da216a2963a379f4eaf58abac06f6c975572690925e85a1c52721d388b3c2ab75698e67acc3ec483e23abb98a88b140fd7"

JWT.decode(token, secret, true, { algorithm: 'HS256' })

This throws a JWT::VerificationError (Signature verification raised)
However, if i head over to jwt.io, and type in those exact same values (try it, just copy them from above) it says "Signature Verified"
Any ideas what is wrong here?

Hey @scottrobertson
The given token is invalid.
When entering the token into jwt.io and passing the password the last part of the token changes. The website manipulates the  pasted token. It is not clearly visible. You really need to look. It's confusing.
First you need to paste the password and then paste the token. This ensures that the token is validated and not created with the given password. Doing this in the described order will display the "Invalid Signature" message.
Please check with the issuer of the token. There is something wrong in the creation process.

Hey @scottrobertson
The given token is invalid.
When entering the token into jwt.io and passing the password the last part of the token changes. The website manipulates the  pasted token. It is not clearly visible. You really need to look. It's confusing.
First you need to paste the password and then paste the token. This ensures that the token is validated and not created with the given password. Doing this in the described order will display the "Invalid Signature" message.
Please check with the issuer of the token. There is something wrong in the creation process.

Ah that makes total sense then.  It will be an issue on my end, thank you.

Ah that makes total sense then.  It will be an issue on my end, thank you.

Thanks for the fast response.
Have a great day.

Thanks for the fast response.
Have a great day.


Support token aware feature.

As scylla supports token aware and shard aware features in CQL driver, it maybe a good try to support such feature in alternator load balancing lib as well to achieve better performance?

Sounds like a worthy idea.
The token ownership in the cluster (which tokens belong to which node) can change over time, but it's still worthwhile to use even using slightly outdated information - because if we send a request to the "wrong" node it will still work just like it works today.
We'll need to add a new request, like we have "/localnodes" today, to return the token ownership information. The client library would need to periodically refresh its knowledge.
Shard awareness is also possible, similar to how we do it in CQL - the client can control which shard will receive its request by controlling the port number used for the outgoing request.
There is one important implementation difficulty, though. The client library would need to parse and understand the request before routing it - determine if this is the type of request that accesses only a single item and which item this is. We'll probably need to modify/inject/monkey-patch the AWS library at different places than we do right now, and it might be hard to do in certain languages. But it might be worth a try.

Token-ownership awareness is useful for every GetItem (and Query) and PutItem request to avoid an extra hop, but it is extra useful for PutItem that uses LWT to avoid https://github.com/scylladb/scylladb/issues/16261:
For LWT, the coordinator which receives the write is responsible for serializing different attempts to write to the same partition concurrently. If multiple coordinators receive writes to the same partition, they "contend" with each other and cause errors (https://github.com/scylladb/scylladb/issues/16261) and slowness (https://github.com/scylladb/scylladb/issues/13078). Instead of solving this somehow in Alternator (see also https://github.com/scylladb/scylladb/issues/5703), we can fix in the the driver:

As for non-LWT PutItem, we send the request to one of RF replicas instead of to a random now, which already lowers the chance of contention.
Even better, specifically for LWT PutItem, we should send the request to a specific coordinator. We could always send it to the "primary owner" (first on the replica list) of this token, but even better - look at token % RF and if the result is x, take the x'th replica for this token. All clients will use the same algorithm so will send a write to the same partition to the same node - but all RF nodes will be sent requests for different tokens.
Obviously, even if we "prefer" a specific coordinator, we should try the next one (in cyclic order) if the preferred coordinator is down.

By the way, my previous comment mentioned the need to "parse and understand the request before routing it". Even better would be to get the request before it's serialized and not need to parse it. For example A PutItem call probably specifies the table name and partition key as separate parameters, and we shouldn't (if we can..) wait until we have the HTTP request as a string and then parse it again.
CC @dkropachev

In my previous comment I described a further optimization beyond token-aware load balancing, which is to pick not just one of RF replicas - but consistently pick the same one for a specific partition key. Let's call it the "consistent-coordinator" optimization.
But it's important to note that there is a tradeoff between this consistent-coordinator optimization and rack-aware load balancing (issue #31). Reads and non-LWT writes are better done with rack-aware load balancing to reduce the cross-rack networking costs. But for LWT-using writes, there are two cases:

If partition contention (two concurrent writes to the same partition) is known to be high, the consistent-coordinator optimization is better. It will avoid two different coordinators getting LWT writes and causing the slowness of https://github.com/scylladb/scylladb/issues/16261, https://github.com/scylladb/scylladb/issues/13078.
However, if the likelihood of contention is known to be low, the consistent-coordinator optimization is not helpful and will just cause more cross-rack network traffic that the rack-aware load balancing avoids.

So if we implement this extra consistent-coordinator optimization, it should be made optional to enable, and either be made user-configurable (with documentation explaining when to enable it), or could in theory also be made automatic when we detect high rates of LWT contention.


gravity press animation.

on progress change, change property 0.1.2, 0 is default, 1 is halfway pressed, 2 is all the way down. model animation.

done


Extension non-functional in vscode.dev

I installed the extension in vscode.dev (this repo and commit if it matters) version v0.24.4. The sidebar item did create, but the menu showed empty menus.
Chrome developer console showed the following error.
Activating extension 'cschleiden.vscode-github-actions' failed: process is not defined.
$onExtensionActivationError @ mainThreadExtensionService.ts:111

As of v0.25.0, opening the view and pressing the refresh button generates the following error in the developer console.
Access to fetch at 'https://api.github.com/' from origin 'https://v--1etn2pi73v74vnspogot0atvvustoe9d1bbh4j2hontitvgtqo2l.vscode-cdn.net' has been blocked by CORS policy: Request header field x-github-api-version is not allowed by Access-Control-Allow-Headers in preflight response.


compatibility issue

Version
3.5.0
Reproduction link
https://cli.vuejs.org/zh/guide/cli-service.html
Environment info
win 7

Steps to reproduce
The newly created project is incompatible with IE11 and reports an error in the referenced package
'SCRIPT1002: 语法错误'
What is expected?
Run successfully
What is actually happening?
Run failure

Seems like a duplicate of #3616

3.5.1 released, please check if it has fixed this issue


.github/pr-check-license.yaml: fix the license check issue

This PR is to quickly fix the license check issue

@dongx1x I move your license fix to this PR to avoid blocking other PRs scan.


Intersect interfaces instead of union

TypeScript Version:  3.4.0-dev.201xxxxx
Search Terms: Intersection interfaces, Ternary operator, Intersect interfaces instead of union
Code
const someCondition = true

interface Func1Options { name: string }
interface Func2Options { age: number }

function Func1 (options: Func1Options) { console.log(options) }
function Func2 (options: Func2Options) { console.log(options) }

const selectedFunc = someCondition
 ? Func1
 : Func2

selectedFunc({
    age: 20,
    name: 'Alastar'
})

Expected behavior:
selectedFunc accepts Func1Options
Actual behavior:
selectedFunc accepts Func1Options & Func2Options
Playground Link: Playground

But that would produce invalid results. If selectedFunc would be an intersection, then it would be appear as an overloaded function, even tho it's not.
For example if you manually force an intersection:
const someCondition = false

interface Func1Options { name: string }
interface Func2Options { age: number }

function Func1 (options: Func1Options) { console.log(options.name) }
function Func2 (options: Func2Options) { console.log(options.age) }

type BothFunc = typeof Func1 & typeof Func2
const selectedFunc = (someCondition ? Func1 : Func2) as BothFunc
const obj: Func1Options = { name: 'Bob' }

selectedFunc(obj)

The compiler will assume it calls Func1, because that's what the obj parameter matches to. But it actually calls Func2 which gets an invalid object passed along.

Is this issue saying that selectedFunc should be of type typeof Func1 because the condition in the ternary is statically known to be true?  If so, that is working as intended as per #14206.  As far as I know, the type of x ? y : z is always (equivalent to) typeof y | typeof z regardless of whether x is known to be truthy or falsy.

Or is this issue saying that selectedFunc should be of type typeof Func1 | typeof Func2, but that you should be able to call it with a Func1Options | Func2Options argument?  If so, then this is working as intended, as implemented in #29011, which is a partial fix for #32978.   It is not safe for a union of functions to accept a union of arguments, because function arguments are contravariant.  Consider the following code:
function Func1(options: Func1Options) {
  options.name.toUpperCase();
}
function Func2(options: Func2Options) {
  options.age.toFixed();
}
const selectedFunc = Math.random() < 0.5 ? Func1 : Func2;
selectedFunc({ age: 20 });

At runtime, selectedFunc may turn out to be Func1.  Inside the selectedFunc({age: 20}) call, options.name.toUpperCase() will end up trying to call a method on undefined, and you will get a runtime error.  It's not safe.  Unless you can narrow selectedFunc to either typeof Func1 or typeof Func2, the only safe thing you can pass it as an argument is Func1Options & Func2Options.  That way you know no matter which function it turns out to be, it will have an argument that meets its needs.

@MartinJohns’s comment shows why it the current behaviour is the correct one.
More details can be found here:  #29011

Is this issue saying that selectedFunc should be of type typeof Func1 because the condition in the ternary is statically known to be true? If so, that is working as intended as per #14206. As far as I know, the type of x ? y : z is always (equivalent to) typeof y | typeof z regardless of whether x is known to be truthy or falsy.
Or is this issue saying that selectedFunc should be of type typeof Func1 | typeof Func2, but that you should be able to call it with a Func1Options | Func2Options argument? If so, then this is working as intended, as implemented in #29011, which is a partial fix for #7294. It is not safe for a union of functions to accept a union of arguments, because function arguments are contravariant. Consider the following code:
function Func1(options: Func1Options) {
  options.name.toUpperCase();
}
function Func2(options: Func2Options) {
  options.age.toFixed();
}
const selectedFunc = Math.random() < 0.99 ? Func1 : Func2;
selectedFunc({ age: 20 }); // 99% guarantee of kaboom

At runtime, selectedFunc may turn out to be Func1. Inside the selectedFunc({age: 20}) call, options.name.toUpperCase() will end up trying to call a method on undefined, and you will get a runtime error. It's not safe. Unless you can narrow selectedFunc to either typeof Func1 or typeof Func2, the only safe thing you can pass it as an argument is Func1Options & Func2Options. That way you know no matter which function it turns out to be, it will have an argument that meets its needs.

Thank you, for description. Now I understand kind of philosophy of ts,


My android app stop running without error after I setup react-native-notification

"react-native": "0.61.5",
"react-native-notifications": "^3.1.2",

No errors whatesoever? I'm using the same versions with my project and didn't have this issue when I installed it.
Did you follow the Android installation guide? https://wix.github.io/react-native-notifications/docs/installation-android

They may be related to #456 or #492, there is a PR  https://github.com/wix/react-native-notifications/pull/496 which may help

They may be related to #456 or #492, there is a PR #496 which may help

the notification is not empty. the issue is no notification popup(alert) on android  and I can't set alert action

Same issue
{
  "react-native": "0.61.5",
  "react-native-notifications": "^3.1.2",
}


Sentinel failover not detected when connection hangs

I have stumbled onto the same issue as these:

https://github.com/luin/ioredis/issues/556
https://github.com/luin/ioredis/issues/1021
https://github.com/luin/ioredis/issues/1059

After some investigating, I concluded that ioredis currently relies on Redis closing the connection as described here
However, when the failover is initiated with the Redis DEBUG SLEEP command or docker pause, the connection simply hangs, but doesn't terminate.
This could be solved by subscribing to sentinel messages on the +switch-master channel. Described in the Sentinel docs as "the message most external users are interested in"
I've created a reproducible example: https://github.com/mjomble/ioredis-sentinel-issue
This example listens to the message outside ioredis.
Once received, it uses internal/undocumented fields to call client.connector.stream.destroy() because redis.disconnect(true) (which calls stream.end()) leaves the connection open in this scenario.
Ideally, this could all happen inside ioredis. I could probably submit a PR if needed.

Hi Andres, thanks for raising this and the detailed explanation! A PR would be welcome.

@luin I'm thinking of two different approaches here:

Listen to the +switch-master message on all sentinels.
Listen to the message only on the first successfully reached sentinel (the same one used to resolve the master).

The first one seems more reliable, but could get complicated when some sentinels are up and some are down. Also, it might not work well with the existing SentinelIterator logic.
The second one should integrate more naturally with SentinelIterator, but might miss the message if the sentinel hangs as well. Which can happen easily if it's on the same machine as the master. Maybe we should add a ping loop to it?
Any thoughts/recommendations?

Yeah it's more complex than I thought. I'd go with subscribing to all sentinels because in case of a partition, as you said, it's very likely that the connected sentinel and the old master are in the same network, so we won’t be able to get events from that sentinel.
As for implementation details, I think SentinelConnector will get a lastActiveSentinel property, which defaults to null. Once a node is resolved, the connector will subscribe to all sentinels provided by user (I don’t think it need to be dynamic in v1 as it seems non-trivial to implement). Not sure if it’s necessary but a reasonable connection count limit may be applied to avoid user provides too many sentinels.
When a +switch-master is received, we set lastActiveSentinel to the one that got the event, and disconnect so Redis#connect() will kick in. Next time SentinelConnector will try lastActiveSentinel (and then reset it) first. Wdyt?
@ohadisraeli @leibale btw do you have any inputs on the correct behaviors about whether clients should subscribe to all sentinels or not? Or may be it should behind an option so users can enable/disable?

Hi, i use the version 4.27.6 and the issue still exists actually. What is the best option to avoid this issue ?

Can you create a reproducible example? Otherwise it's extremely difficult to pinpoint the exact cause of the issue.

Hi, i use the version 4.27.6 and the issue still exists actually. What is the best option to avoid this issue ?

Can you create a reproducible example? Otherwise it's extremely difficult to pinpoint the exact cause of the issue.

Thanks for quick response.
Well steps are :

create a node project with ioredis and a key with ttl and listen to this expiration for example
connect ioredis with a config of at least 2 sentinels ( 1 master 1 slave )
trigger a redis failover on your redis server  ( pass master responsability to slave )
you will see that the listener doesn't continue and stays stuck on the dead sentinel

and listen to this expiration

I'm not familiar with this feature, could you provide a code example?

Are you sure it's the same issue and ioredis fails to detect the failover?
Or could it be that the failover is actually detected and the problem is more specifically about the subscription?
You could try adding extra code, for example something that increments a Redis value every second and logs the new value to the console.
If the listener fails, but the value incrementing still works, then failover detection is fine and you can create a new, more specific issue about the listener.

I think the subscription should be reset to another sentinel if we have a failover.
From my view i think it's related. Maybe I'm wrong you can tell me.

We're seeing this issue in version 5.3.1. I have verified it by gracefully shutting down redis master instance, then new election happens, and sentinel announce new master, our application also creates a new connection to the master, everything works as it should.
I have also tried executing the sleep command on the redis master instance, and that results in the same master election happening, with sentinel announcing new master, but our application does not initiate a reconnect, so commands are still trying to execute against old master.


Use of undefined constant VERSION

Running getstream with Symfony 5.2 on PHP 7.4.
This notice appears frequently:
NOTICE: PHP message: PHP Warning: Use of undefined constant VERSION - assumed 'VERSION' (this will throw an Error in a future version of PHP) in /srv/http/vendor/get-stream/stream/lib/GetStream/Stream/Feed.php on line 67
Best regards.
gz#10568

@kevin-lot what is the version of the SDK you're using?

We are using get-stream/stream 4.1.1.

@kevin-lot I believe it's fixed on master, will do a release today.

@ferhatelmas Sorry, we still have this issue. Even after the last update.

@ferhatelmas I did that https://github.com/GetStream/stream-php/pull/102

Class based approach definitely will work. Thanks for preparing a PR :+1:


Some Build Review Fixes

Standalone compile error (we no longer need to instruct them to switch to UWP before building)
Ryan's suggestion to update SpectatorView.Setup
Updated ResetSamples.bat to launch ResetSamples.ps1 as admin
Build2019Sample - Updated MRTK references to exclude Tests and Examples in attempt to mitigate long path issue.

I think this documentation change is good. I am hesitant to take the verifier in the 1.0.0-beta release compared to the 8/15 milestone. The impact of the verifier change may be small considering its only in the build 2019 demo, but I would prefer if this change baked in master for a bit compared to getting added to our upcoming stabilization payload.


Defining AccountID

@pamistel : Thanks for your contribution! The author(s) have been notified to review your proposed change.

#sign-off

@pamistel: I'm sorry - only the author of this article, @msftradford, can sign off on your changes. But we do have an exception process - if you are on the Microsoft content or product team for this product area, you can ask the PR review team to review and merge it by sending mail to the techdocprs alias.

Hi @pamistel - This pull request was opened in the public repo. PMs should work in the private repo, per the Microsoft Docs contributor guide. We can keep this PR open for review and merge, but would you make future content updates in the private repo? Thank you!

Hi @pamistel - The article author has left feedback in the pull request for when you have a chance to take a look and respond. Thanks!

Hi @pamistel - The article author has left feedback in the pull request for when you have a chance to take a look and respond. Thanks!

Hi @pamistel - The article author has left feedback in the pull request for when you have a chance to take a look and respond. Thanks!


Error running Marvel sample

Hello,
When I try to run the marvel example the following error occurs:
"No file or variants found for asset: assets/configurations.json."
What I can do?
Thanks.
Regards,
Jose

@jamolina2021 In the Readme you have the instructions to make it work. You need to create the config file yourself with your API Key
https://github.com/rrousselGit/river_pod/tree/master/examples/marvel#installation


Number of classes generated

This is more of a question, and request for information, rather than a specific issue - however in terms of development maintenance and code readability you could class it as an issue.
I have created a component using react-primitives, comprising some common elements.
<Touchable onPress={() => console.log("Button Press")}>       <View style={styles.button}>         <View style={styles.icon}></View>         <Text style={styles.label}>{label}</Text>       </View>     </Touchable>
All works great, react-primitives library is great.
My question/query is - what is the need for so many generated classes?
For example, in development workflow the classes great in number:

Even in a production build, the number of classes is great:

As I said, it's not necessarily a bug, it could be considered an issue in terms of development maintenance and code readability. I'm more asking for opinions and advice (if there is a way to optimise further).
Thanks in advance.

See https://github.com/necolas/react-native-web/blob/master/docs/guides/style.md, and rely on React Dev Tools to edit styles

Perfect, thanks.... always read the instructions

Sorry but I didn't find the answer to this question:

what is the need for so many generated classes?

Or better said: Will this library generate a clean HTML output without all those classnames?
Besides this, I've tried react-primitives and it looks like an awesome project!!. I'm so looking forward to trying it in our company and create universal components that we can easily import in React Sketch. The problem is that our app is a bit too heavy, so if we use this, our HTML will be humongous :(

In short: it has been made for perfs. https://github.com/necolas/react-native-web/issues/307


feat: add dependabot with github-action and cargo checks to repo

Let me know if you all are looking for any additional config outside of this.

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.

Let me know if you all are looking for any additional config outside of this.

Nope, that's exactly what I was thinking of. Thank you!

No problem at all!


multiple tiers of runnability for user-yield-blocked threads

currently it is black-and-white to decide whether a thread in userspace is stuck in a yield or xchg loop. however, the heuristic for deciding this (TOO_MANY_YIELDS=10) is imprecise and may result in false positives, which could eventually result in a false claim of deadlock.
for now, we simply rely on a large enough value for TOO_MANY_YIELDS. however, using a large value has its own drawback in an increased state space size -- the transitions by a blocked thread before TOO_MANY_YIELDS is reached themselves may be seen by DPOR as non-independent, and result in extra pointless interleavings.
as a difficult-to-implement compromise, we could use a dangerously small value for TOO_MANY_YIELDS, but instead, decide the thread is "probably not runnable", with the option to see what happens if it actually was runnable if all other threads appear to be deadlocked. if the deadlock was real, that thread would simply have to go through TOO_MANY_YIELDS_2_ELECTRIC_BOOGALOO yields again before we proclaim a real deadlock. if the deadlock was false, we may be able to do something like retroactively marking the yielding thread as runnable (during all past yielding transitions) before re-running DPOR, to hit branches that were missed.

Partly implemented for the special case of user_mutex_blocked_on_addr in an incoming commit.
One thing that would be nice to do is, when false-positive deadlock detection begins, set a flag in ls->save.current, and when printing FAB traces, when we see this flag, print "Note, I'm pretty sure the system is deadlocked here. The rest is probably all identical."


I can see issue with status here

How did you install the Amplify CLI?
No response
If applicable, what version of Node.js are you using?
No response
Amplify CLI Version
1
What operating system are you using?
unix
Did you make any manual changes to the cloud resources managed by Amplify? Please describe the changes made.
Issues here may be automatically closed with
"This issue has been automatically locked since there hasn't been any recent activity after it was closed. "
But there are closed issue which is getting constant updates and comments about it not actually been fixed:
https://github.com/aws-amplify/amplify-category-api/issues/92#issuecomment-1352666540
I see an issue with it having 'closed' status. I think it should be open if so much people report that it is not fixed.
Describe the bug
Issue is closed while people are still actively on it, commenting every few hours, providing links and such
Expected behavior
If it not fixed and people active enganged, commenting and providing possible solutions, this should be open.
Reproduction steps
open
https://github.com/aws-amplify/amplify-category-api/issues/92#issuecomment-1352666540
see people active and angry over issue not been fixed
Project Identifier
No response
Log output
No response
Additional information
You surely will close this issue fastly, but we are here struggling with
https://github.com/aws-amplify/amplify-category-api/issues/92#issuecomment-1352666540
so much that we trying to get attention to that in any ways. With no solution in sight, the only thing I am considering to get rid of amplify too, and this is the 'story' I will tell if ever asked about it.
Before submitting, please confirm:

[X] I have done my best to include a minimal, self-contained set of instructions for consistently reproducing the issue.
[X] I have removed any sensitive information from my code snippets and submission.

+1million

Hey @Alex-Github-Account :wave: thanks for raising this!! I'm going to take a deeper look at this one 🙂

Hey @Alex-Github-Account wave thanks for raising this!! I'm going to take a deeper look at this one slightly_smiling_face

That is great, thank you! You provide a hope. I hope for the best!
With Amazon spending $67 000 000 000 (sic!) on R&D (source ) I'd expect such years-long issues  to not happen in first place, as well as cognito to not have bugs like that one from 2018 where any user can change email to any without confirming it (sic!).
Honestly, I cant imagine why just not spend 0.00001 of a budget (still half a million $) to fix every opened issue with current software products. Will it hurt?

Hello,
I am seeing the error resource is not in the state stackUpdateComplete continually. Most recently, I erroneously added MaxRecieveCount to an SQS queue, instead of BatchSize on the lambda that consumes it. Nbd, I'll just remove it -- nope, even after deleting the single offending property in cloudformation, I can't push because amplify errors on extraneous key [MaxReceiveCount] is not permitted. Even though it is long deleted. I have tried amplify checkout env <myenv>, then amplify push, amplify pull (overwriting all local changes) then amplify push, and I still run into the same issue. Any assistance is appreciated.

any update on this issue? smaller bugs/quirks I can understand (although time consuming for a developer). However I wouldn't call having to delete the project/wipe data a workaround for this one...

Lets try to mentoin assignee @josefaidt
@josefaidt, any updates?

i am stuck in the loop too
🛑 ["Index: 1 State: {\"preRollback\":\"previousDeploymentReadyCheck\"} Message: Resource is not in the state stackUpdateComplete"]

https://github.com/aws-amplify/amplify-category-api/issues/92 has been re-opened. Please move discussion there.


docs: add click for preset previews

🔗 Linked issue

close: #115
❓ Type of change

[x] 📖 Documentation (updates to the documentation, readme or JSDoc annotations)
[ ] 🐞 Bug fix (a non-breaking change that fixes an issue)
[ ] 👌 Enhancement (improving an existing functionality like performance)
[ ] ✨ New feature (a non-breaking change that adds functionality)
[ ] 🧹 Chore (updates to the build process or auxiliary tools and libraries)
[ ] ⚠ Breaking change (fix or feature that would cause existing functionality to change)

📚 Description

Bind the preview component to the click event.
As for hover, it seems a bit messy to add it, so I haven't added it yet.
📝 Checklist

[x] I have linked an issue or discussion.
[ ] I have added tests (if possible).
[x] I have updated the documentation accordingly.

Thanks! We will have to remember to do the same in the docs migration https://github.com/vueuse/motion/pull/198


Questions about pre-allocated kv_cache.

Thanks for your great repo. I want to know if the function [initialize_past_key_values()] must be used.
If I do not pre-allocate kv_cache, will the acceleration effects be worse?

I want to know if the function [initialize_past_key_values()] must be used.

It's not mandatory. The pre-allocated kv_cache is not used in modeling_eagle.py.

If I do not pre-allocate kv_cache, will the acceleration effects be worse?

The speedup ratio will not decrease because the pre-allocated kv_cache is used in the target model, which makes both the baseline (vanilla autoregressive) and EAGLE faster. The absolute value of the generation speed will decrease.


Matrix lib

add templated matrix library
add linear kalman using the matrix
add altitude_estimation using kalman on acceleration and sonar

With the Kalman template, shouldn't we suppress the kalman.c/.h files implementing a 2D Kalman filter?

Thanks for fixing the sonar!


Added more customisation to container and the overlay

I changed the opacity prop to overlayBackground
Also, I added a way to customise the container (containerStyle prop), so i renamed the original style prop to modalStyle for easy differentiation

@charliesbox thanks! looking good, although could you modify the readme as well?

@bodyflex done!

awesome, thanks!


Inverse semigroup approach for deltas

This is an attempt to implement what Lukas suggested in the comment to my previous PR:
https://github.com/mintlayer/mintlayer-core/pull/586#issuecomment-1367360036
Imho it looks and works better than the previous version: all tests are passing and the result of combining deltas is cleaner and less debatable.

Not sure what parts were up for review and which are still subject to change so commented everything

I started this branch as an experiment based on the previous branch. My initial idea was that we want to quickly decide whether we want this approach or not. But now it seems that it's better to change the base to master and drop previous PR (applying all comments from there)

Finally merging this to master... Thank you guys for the support!

Finally merging this to master... Thank you guys for the support!

The most important thing to remember is that we don't give up until things are provably correct. Cheers!


use _configuration for locks instead of Handlebars type

As mentioned in https://github.com/rexm/Handlebars.Net/issues/131 I went for reusing _configuration for locking instead of creating a separate lock variable, because _configuration is used within those locks and probably two instances with the same underlying configuration shouldn't interfere between each other.

Changes included in the 1.8.0 release now live on NuGet


Failure to report query errors

Consider the following query
SELECT
    repo_name,
    toDate(created_at) AS day,
    count() AS stars
FROM github_events
WHERE event_type = 'WatchEvent'
GROUP BY
    repo_name,
    day
ORDER BY stars DESC
LIMIT 1 BY repo_name
LIMIT 50

If i execute on the playground i hit a quota limit i.e.
Code: 241. DB::Exception: Memory limit (for query) exceeded: would use 18.65 GiB (attempt to allocate chunk of 4718592 bytes), maximum: 18.63 GiB: While executing AggregatingTransform. (MEMORY_LIMIT_EXCEEDED) (version <IP_ADDRESS>64)
Executing in Grafana i dont receive an error i.e.

Pending fix in the SDK:  https://github.com/grafana/grafana-plugin-sdk-go/pull/462


Can you add a search bar in the master missions tab?

Preparation

[X] No one has asked for this feature before in other issues (even the closed ones)

Describe the feature
Basically the title. A search bar will make using this much better.
And also maybe can you put the traits in alphabetical order?
Sorry if my english is bad

Sorry wrong githud


Waypoint: Generate Random Whole Numbers with JavaScript

The first paragraph needs fixing.

Something else...
It isn't until the NEXT Waypoint (31) that the discussion about how to generate a random number between two numbers is introduced.

Yeah this is an ordering issue I'll take a look at this now!

It should be fixed now!


Database "ermrestddl" does not exist error while creating a Catalog

@karlcz I got this error while creating a new catalog.
Request:
POST /ermrest/catalog HTTP/1.1
HOST: dev.isrd.isi.edu
cookie: ermrest=C6KFIQn2JS37CGovofWnjKfu

Response:
409 Conflict
The request conflicts with the state of the server. FATAL:  database "ermrestddl" does not exist

This was a server config problem not an ermrest bug. It should be fixed now.


Disable Signal Registration Logging Events

Add a flag such that these events will be suppressed from being shown on the console/log file

This should also suppress being shown as the output


Support  update PR body of dependabot

Is there an existing issue for this?

[X] I have searched the existing issues

Feature description
Hi team, I want to update the pr body of dependabot to add some message , and then i wrote some golang code to update it, just got the error of nvalid Message:Only the pull request author may change the maintainer_can_modify value, this issue is request for dependabot can be setting for the maintainer_can_modify to true and then i can update the PR from golang code,Thanks! Remind me if i missed something!

i can use the command of gh pr edit -R user/repo 123 --body hello to update the pr, so this is not the dependabot issue, closing...


Invalid resource type staging::file

Hi,
After successfully running ./deps.sh and build.sh, doing vagrant up halts with a puppet error:
nicu@nmarasoiu:~/tools/consul-cluster-puppet$ vagrant up
Bringing machine 'consul0' up with 'virtualbox' provider...
Bringing machine 'consul1' up with 'virtualbox' provider...
Bringing machine 'consul2' up with 'virtualbox' provider...
Bringing machine 'webui' up with 'virtualbox' provider...
Bringing machine 'demo' up with 'virtualbox' provider...
Bringing machine 'foo0' up with 'virtualbox' provider...
Bringing machine 'foo1' up with 'virtualbox' provider...
==> consul0: VirtualBox VM is already running.
==> consul1: VirtualBox VM is already running.
==> consul2: Importing base box 'trusty64'...
==> consul2: Matching MAC address for NAT networking...
==> consul2: Setting the name of the VM: consul-cluster-puppet_consul2_1431592945090_95794
==> consul2: Clearing any previously set forwarded ports...
==> consul2: Fixed port collision for 22 => 2222. Now on port 2202.
==> consul2: Clearing any previously set network interfaces...
==> consul2: Preparing network interfaces based on configuration...
consul2: Adapter 1: nat
consul2: Adapter 2: hostonly
==> consul2: Forwarding ports...
consul2: 22 => 2202 (adapter 1)
==> consul2: Running 'pre-boot' VM customizations...
==> consul2: Booting VM...
==> consul2: Waiting for machine to boot. This may take a few minutes...
consul2: SSH address: <IP_ADDRESS>:2202
consul2: SSH username: vagrant
consul2: SSH auth method: private key
consul2: Warning: Connection timeout. Retrying...
consul2: Warning: Remote connection disconnect. Retrying...
consul2:
consul2: Vagrant insecure key detected. Vagrant will automatically replace
consul2: this with a newly generated keypair for better security.
consul2:
consul2: Inserting generated public key within guest...
consul2: Removing insecure key from the guest if its present...
consul2: Key inserted! Disconnecting and reconnecting using new SSH key...
==> consul2: Machine booted and ready!
==> consul2: Checking for guest additions in VM...
==> consul2: Setting hostname...
==> consul2: Configuring and enabling network interfaces...
==> consul2: Mounting shared folders...
consul2: /vagrant => /home/nicu/tools/consul-cluster-puppet
consul2: /tmp/vagrant-puppet/modules-6a51abd267c5ea0234a37cae97c7e310 => /home/nicu/tools/consul-cluster-puppet/puppet/modules
consul2: /tmp/vagrant-puppet/manifests-768747907b90c39ab6f16fcb3320897a => /home/nicu/tools/consul-cluster-puppet/puppet
==> consul2: Running provisioner: puppet...
==> consul2: Running Puppet with server.pp...
==> consul2: stdin: is not a tty
==> consul2: Error: Puppet::Parser::AST::Resource failed with error ArgumentError: Invalid resource type staging::file at /tmp/vagrant-puppet/modules-6a51abd267c5ea0234a37cae97c7e310/consul/manifests/install.pp:23 on node consul2.local
==> consul2: Wrapped exception:
==> consul2: Invalid resource type staging::file
==> consul2: Error: Puppet::Parser::AST::Resource failed with error ArgumentError: Invalid resource type staging::file at /tmp/vagrant-puppet/modules-6a51abd267c5ea0234a37cae97c7e310/consul/manifests/install.pp:23 on node consul2.local
Host OS: Ubuntu 14.04 LTS
uname: 3.13.0-52-generic #86-Ubuntu SMP Mon May 4 04:32:59 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
Vagrant version: 1.7.2
Please advice,
Nicu

You should have https://forge.puppetlabs.com/nanliu/staging in your puppet modules path as it is mentioned on the dependencies page. https://forge.puppetlabs.com/KyleAnderson/consul/dependencies


[FEATURE] Implement vSwitch for Internally routed networks

Moving from VMware ESXI to Harvester and one thing that I find strange is that there is no internal switching in the cluster.
All network connections appear to have to switch via an external vlan aware switch through a single ethernet connection.
Implementing https://www.openvswitch.org/ would allow switching to occur internal to each host and an assigned uplink for each vSwitch would allow connectivity to each vlan

vSwitch is a beast... We might bring it in later, but we've decided to keep the network model simple at first and focus more on providing support to the guest Kubernetes's network.

All network connections appear to have to switch via an external vlan aware switch through a single ethernet connection.

Is this accurate? Specifically, is it necessary to have a metal, VLAN-aware switch to effect layer 2 isolation with Harvester VM network VLANs?

Any news about this?
It is possible to create virtual nic not attached to a physical interface? Or configure virtual switches?

At the moment, there is no existing, easy solution to confiure virtual nic/vSwitch directly in Harvester.
On the other hand, back to the concern here:
The VLAN based isolation, is switched inside Harvester NODE when traffic is bettwen VMs in same NODE, there is one/some Linux Bridge(s) used, the same-NODE traffic is not depending on a physical switch.

Any news about this? It is possible to create virtual nic not attached to a physical interface? Or configure virtual switches?

If you create a dummy network interface via a yaml file in /oem, you can then use the Harvester API (https://$IP/v1/harvester/network.harvesterhci.io.vlanconfigs) to attach the dummy interface to a cluster network and now you have a usable private network you can use to connect VMs together without having to have a physical interface or VLAN attached.
I use a simple yaml file like this:
name: "dummy0"
stages:
  initramfs:
  - files:
    - path: /etc/sysconfig/network/ifcfg-dummy0
      permissions: 384
      owner: 0
      group: 0
      content: |
        STARTMODE='hotplug'
        BOOTPROTO='none'
      encoding: ""
      ownerstring: ""


Operator Status Condition

/question
Can we have the Argo CD operator status to be reported in a standard Kubernetes way  with status -> conditions[*], that will help the automation tools like Ansible or others to query the install status of the Operator/CR and do the needed actions.

This is a good suggestion @kameshsampath and has been in my thoughts to change for a while.


Added support for previewing subscription changes

@shawnspeak thanks for the pull request. Could we some more information in the description about what is going on here and how it can be tested?

The other recurly libraries have a means of previewing a subscription change (https://docs.recurly.com/api/subscriptions#sub-change-preview). This pull request add's that capability.
A PreviewChange() method was added to the Subscription class that to will POST changes made to the given Subscription instance to the "preview" endpoint. The response is then used to create a new instance of Subscription which contains a Invoice and Adjustments from Recurly.
I'll have to study the current test code more to provide a recommendation for a unit test.

@shawnspeak sorry we fell behind on this. If you do a rebase with the latest changes I can look at getting this in this week.

we are going to pick this up here: https://github.com/recurly/recurly-client-net/pull/116