This application is not an Angular application.  Fail on function check I think.

Augury: 1.24.0
Date: Thu, 05 Dec 2019 12:46:42 GMT
OS: Win32
Demo test application:
import { Component, OnInit } from '@angular/core';
declare const getAllAngularTestabilities: Function;
declare const getAllAngularRootElements: Function;
declare const ng: any;
@Component({
selector: 'app-show-me',
templateUrl: './show-me.component.html',
styleUrls: ['./show-me.component.css']
})
export class ShowMeComponent implements OnInit {
constructor() {
const myThing: Function = function add(x,y){return x+y};
console.log ("getAllAngularTestabilities = " + typeof getAllAngularTestabilities);
console.log ("getAllAngularRootElements = " + typeof getAllAngularRootElements);
console.log ("ng = " + typeof ng);
console.log ("myThing = " + typeof myThing);

}
ngOnInit() {
}
}
Description of issue:
-- Include (clipped) screenshot images if possible.

Angular version (required): ???
Angular CLI: 8.3.20
Node: 13.1.0
OS: win32 x64
Angular: 8.2.14
... animations, common, compiler, compiler-cli, core, forms
... language-service, platform-browser, platform-browser-dynamic
... router
Package                           Version
@angular-devkit/architect         0.803.20
@angular-devkit/build-angular     0.803.20
@angular-devkit/build-optimizer   0.803.20
@angular-devkit/build-webpack     0.803.20
@angular-devkit/core              8.3.20
@angular-devkit/schematics        8.3.20
@angular/cli                      8.3.20
@ngtools/webpack                  8.3.20
@schematics/angular               8.3.20
@schematics/update                0.803.20
rxjs                              6.4.0
typescript                        3.5.3
webpack                           4.39.2
Steps to reproduce:

Create new project using ng new
ng serve
connect on browser
click augury section in debug

Additional details:
I am getting this error on every Angular project I try Augury on.  Just downloaded and installed all the components in the last week so they are all pretty current.
I created a brand new project using ng new testAugury and then hit enter twice.  Launched this and augury told me it was not an angular project.  Restarted chrome and server same results.
Deleted project ran ng new testAugury again but this time said Y to "add Angular routing?" got same results.
I pulled the source for Augury from Git and found this code in src/backend/utils/app-check.ts
declare const getAllAngularTestabilities: Function;
declare const getAllAngularRootElements: Function;
declare const ng: any;
export const isAngular = () => {
return typeof getAllAngularTestabilities === 'function'
&& typeof getAllAngularRootElements === 'function';
};
basically put that code into console.log on my project and it logs them as "undefined" (see attached screen shots).
Tried both chrome and firefox dev edition.
Google Chrome is up to date
Version 78.0.3904.108 (Official Build) (64-bit)
Firefox Browser Developer 72.0b2(64 bit)
Seems like there is something weird going on with the latest stuff or I am just looking at the Augury code completely wrong.  I am completely new to this typescript/javascript/angular world so I very well may be looking at it wrong, or be missing some include or some other special thing I have no knowledge of.
Thanks and hope I wasn't too long winded, being doing dev for a lot of years and more information is most often better.  ;)

@AlvaPowell This is related to IVY. Can you check if you have IVY enabled in your angular.json?

Sorry hate to be a bone head but I am not even sure how to check that.
The only thing I can find that references IVY is in<EMAIL_ADDRESS>which has this:
"enableIvy": {
"description": "When true, creates a new app that uses the Ivy rendering engine.",
"type": "boolean",
"default": false
or in<EMAIL_ADDRESS>which has this:
"bin": {
"ivy-ngcc": "./ngcc/main-ngcc.js",
"ngc": "./src/main.js",
"ng-xi18n": "./src/extract_i18n.js"
},
any help would be appreciated.

This is my Angular.json file:
angular.zip
and all the .json files in the project.
AllJSON.zip

Do you have a link to your code in github?

Just made a repository with it:
https://github.com/AlvaPowell/AuguryTest

Hi Alva, What command do you use to build your code?

I updated to the version 1.24.1 and it seems to be working now.


[BUG]: Docker images not supporting platform  linux/arm64/v8

What is the bug related to?
Registry Core
What went wrong?
When using docker images on Apple Macbook Air M1, getting warnings as below
⠴ keycloak The requested image's platform (linux/amd64) does not match the detected host platform (linux/arm64/v8) and no specific platform was requested  0.0s
⠴ registry The requested image's platform (linux/amd64) does not match the detected host platform (linux/arm64/v8) and no specific platform was requested  0.0s

Keycloak image does not work
Registry image is too slow

What did you expect to see?
Docker images to support platform  linux/arm64/v8
Additional Context
Additionally noted that Dockerfile not present in Keycloak repo
Relevant logs/output (if any)
No response

PR resolving this issue: https://github.com/Sunbird-RC/sunbird-rc-core/pull/260

@itsvick can you also share some documentation of the changes that you have done. @holashchand if we need to build and publish a new keycloak revision, please ensure that this is done as well.

@srprasanna vikastc/sunbirdrc-keycloak:apple-silicon is Apple M1 keycloak base image which is required to build sunbird-rc-keycloak revision. Using that base image the keycloak image can be built from our systems as well. This should be published as new revision, since base images are different. we can push that image to git packages and then reference if we don't want base image to be maintained on dockerhub.
The below steps can be followed -

Move base image vikastc/sunbirdrc-keycloak:apple-silicon to git packages
Build and publish new revision of sunbird-rc-keycloak specific for Apple silicon versions.


Double logging happens when using the syslog-release

Issue
Due to the teeing of output to the logger command (via the tee_output_to_sys_log function), when syslog-release is used to send all log files to syslog, we get double entries in syslog.
Possible Fix
Stop teeing output to logger?

Hi @jpalermo, good to hear from you.
Which log files are you referring to in particular and for what jobs? e.g. router/gorouter.log?
Can I assume that this doesn't require a change to our existing behavior with regard to local logging and streaming via metron agent?

For out particular use case, it was /var/vcap/sys/log/route_registrar/route_registrar.log and /var/vcap/sys/log/route_registrar/route_registrar.err.log since we are only co-locating the route_registrar job.
However, it seems like this is done in most of the routing control scripts currently.
I don't think it would require any behavior changes to local logging or streaming via metron agent.
The mysql team just made a similar change, we in fact had the exact same tee_output_to_sys_log function that we just changed to output_to_logfiles by removing the tee and logger portions:
https://github.com/cloudfoundry/cf-mysql-release/commit/6f9092f1ad502afbd174b342568b3f975d96d47c#diff-42cc39d7414a1cfa8dacaf8f775ec671
This allowed us to remove any syslog code and properties from our release, and simply rely on the syslog-release to send all log files in /var/vcap/sys/log to syslog for us.

Hello @shalako @shubhaat,
Just curious if there's any chance you'll prioritize this issue? It's just a bit odd that we're double-syslogging routings' log messages.

To be honest, we're not likely to get to it soon. If you've got the bandwidth to make a PR, it would be welcome as long as it doesn't impact logging behavior otherwise. @aaronshurley

Once we switch to using BPM (stories), this issue should be resolved

👍

We have completed the adoption stage for BPM. Are you still seeing this issue?

@jpalermo @menicosia Given that the BPMification of our jobs should have fixed this and that there are no new updates, I'm going to close this for now. Please re-open or reach out to our team if you have any updates. :)
Thanks!


Add Github Project Description

Capybara is a Storefront UI based theme for Vue Storefront. Always Open Source, MIT license. Made with :green_heart: by Vue Storefront.


Does prometheus have a thread leak other CPU usage bug?

What happened?
Installed Prometheus Operator via a helm chart v 9.3.1 . after a few days we get CPUThrottling alerts.
looking at the Kubernetes / Compute Resources / Pod dashboard in grafana over 7 days I can see a gradual rise in CPU until I start throttling see image attached

Did you expect to see some different?
expected no alerts. we are not adding more work to the system or more exports and servicemonitors
How to reproduce it (as minimally and precisely as possible):
deploy prometheus-operator to an environment and watch it for a few days
Environment
Production

Prometheus Operator version:
quay.io/coreos/prometheus-operator:v0.38.1

kubectl -n monitoring describe deployment prometheus-prometheus-oper-operator
Name:                   prometheus-prometheus-oper-operator
Namespace:              monitoring
CreationTimestamp:      Tue, 29 Sep 2020 08:49:40 +1000
Labels:                 app=prometheus-operator-operator
                        chart=prometheus-operator-9.3.1
                        heritage=Tiller
                        release=prometheus
Annotations:            deployment.kubernetes.io/revision: 1
Selector:               app=prometheus-operator-operator,release=prometheus
Replicas:               1 desired | 1 updated | 1 total | 1 available | 0 unavailable
StrategyType:           RollingUpdate
MinReadySeconds:        0
RollingUpdateStrategy:  25% max unavailable, 25% max surge
Pod Template:
  Labels:           app=prometheus-operator-operator
                    chart=prometheus-operator-9.3.1
                    heritage=Tiller
                    release=prometheus
  Service Account:  prometheus-prometheus-oper-operator
  Containers:
   prometheus-operator:
    Image:      quay.io/coreos/prometheus-operator:v0.38.1
    Port:       8080/TCP
    Host Port:  0/TCP
    Args:
      --manage-crds=true
      --kubelet-service=kube-system/prometheus-prometheus-oper-kubelet
      --logtostderr=true
      --localhost=<IP_ADDRESS>
      --prometheus-config-reloader=quay.io/coreos/prometheus-config-reloader:v0.38.1
      --config-reloader-image=docker.io/jimmidyson/configmap-reload:v0.3.0
      --config-reloader-cpu=0
      --config-reloader-memory=0
    Environment:  <none>
    Mounts:       <none>
   tls-proxy:
    Image:      squareup/ghostunnel:v1.5.2
    Port:       8443/TCP
    Host Port:  0/TCP
    Args:
      server
      --listen=:8443
      --target=<IP_ADDRESS>:8080
      --key=cert/key
      --cert=cert/cert
      --disable-authentication
    Environment:  <none>
    Mounts:
      /cert from tls-proxy-secret (ro)
  Volumes:
   tls-proxy-secret:
    Type:        Secret (a volume populated by a Secret)
    SecretName:  prometheus-prometheus-oper-admission
    Optional:    false
Conditions:
  Type           Status  Reason
  ----           ------  ------
  Available      True    MinimumReplicasAvailable
  Progressing    True    NewReplicaSetAvailable
OldReplicaSets:  <none>
NewReplicaSet:   prometheus-prometheus-oper-operator-6dd4fd7466 (1/1 replicas created)
Events:          <none>

Kubernetes version information:
Client Version: version.Info{Major:"1", Minor:"19", GitVersion:"v1.19.3", GitCommit:"1e11e4a2108024935ecfcb2912226cedeafd99df", GitTreeState:"clean", BuildDate:"2020-10-20T14:12:21Z", GoVersion:"go1.15.3", Compiler:"gc", Platform:"linux/amd64"} Server Version: version.Info{Major:"1", Minor:"17+", GitVersion:"v1.17.9-eks-4c6976", GitCommit:"4c6976793196d70bc5cd29d56ce5440c9473648e", GitTreeState:"clean", BuildDate:"2020-07-17T18:46:04Z", GoVersion:"go1.13.9", Compiler:"gc", Platform:"linux/amd64"}

Kubernetes cluster kind:
AWS EKS v 1.17
insert how you created your cluster: kops, bootkube, tectonic-installer, etc.
terraform using this module terraform-aws-eks

Manifests:

insert manifests relevant to the issue

Prometheus Operator Logs:

Insert Prometheus Operator logs relevant to the issue here

Prometheus Logs:

Insert Prometheus logs relevant to the issue here

Anything else we need to know?:
I have not added any rules other than the defaults that come with prometheus-operator helm chart. I see the same behaviour in an brand new EKS kubernetes environment with nothing deployed except propmetheus-operator and nginx-ingress and external-dns

I realize this may be a big ask, but do you think you could collect a couple of cpu profiles and share them? Ideally at different points where the CPU usage is low and high.

Hi Sorry I missed your question, ok. but what do you mean specifically?  CPU profile of the Pod? or the underlying host?

I'll get a profile when I restart the POD when it always is low and another 9 days later.

My apologies, I should have elaborated a bit more. Prometheus has an HTTP endpoint that allows taking CPU profiles. We also have a small debug command in promtool. You can grab promtool by downloading a latest Prometheus release, and unpack the tarball. Then port-forward your Prometheus server:
kubectl -n monitoring port-forward prometheus-k8s-0 9090

And run
promtool debug all http://localhost:9090/

And then share the result here.

With that tool it wasn't a big ask at all :-) here are the two debug traces one busy and throttling after 8days of running the other 5 mins after I bounced the prometheus pod. Hope it helps :-)
not_busy_cpu_restart_5mins_debug.tar.gz
busy_cpu_8days_debug.tar.gz

I had a quick glance at it appears to me that the "busier" server has a lot more churn of series going active and stale.
brancz at localhost in ~/Downloads/busy_cpu_8days_debug
$ cat metrics.txt | grep prometheus_tsdb_head_series
# HELP prometheus_tsdb_head_series Total number of series in the head block.
# TYPE prometheus_tsdb_head_series gauge
prometheus_tsdb_head_series 68849
# HELP prometheus_tsdb_head_series_created_total Total number of series created in the head
# TYPE prometheus_tsdb_head_series_created_total counter
prometheus_tsdb_head_series_created_total 132071
# HELP prometheus_tsdb_head_series_not_found_total Total number of requests for series that were not found.
# TYPE prometheus_tsdb_head_series_not_found_total counter
prometheus_tsdb_head_series_not_found_total 0
# HELP prometheus_tsdb_head_series_removed_total Total number of series removed in the head
# TYPE prometheus_tsdb_head_series_removed_total counter
prometheus_tsdb_head_series_removed_total 63222

brancz at localhost in ~/Downloads/busy_cpu_8days_debug
$ cat ../not_busy_cpu_restart_5mins_debug/metrics.txt | grep prometheus_tsdb_head_series
# HELP prometheus_tsdb_head_series Total number of series in the head block.
# TYPE prometheus_tsdb_head_series gauge
prometheus_tsdb_head_series 68871
# HELP prometheus_tsdb_head_series_created_total Total number of series created in the head
# TYPE prometheus_tsdb_head_series_created_total counter
prometheus_tsdb_head_series_created_total 68871
# HELP prometheus_tsdb_head_series_not_found_total Total number of requests for series that were not found.
# TYPE prometheus_tsdb_head_series_not_found_total counter
prometheus_tsdb_head_series_not_found_total 0
# HELP prometheus_tsdb_head_series_removed_total Total number of series removed in the head
# TYPE prometheus_tsdb_head_series_removed_total counter
prometheus_tsdb_head_series_removed_total 0

Could you share graphs of prometheus_tsdb_head_series,  prometheus_tsdb_head_series_created_total, and prometheus_tsdb_head_series_removed_total over time? That should correlate to the CPU graphs.

Is this what you need? remember I bounced the prometheus pod to get the low cpu debug info.
prometheus_tsdb_head_series:
prometheus_tsdb_head_series{endpoint="web",instance="<IP_ADDRESS>:9090",job="prometheus-prometheus-oper-prometheus",namespace="monitoring",pod="prometheus-prometheus-prometheus-oper-prometheus-0",service="prometheus-prometheus-oper-prometheus"} | 60900

prometheus_tsdb_head_series_created_total:
prometheus_tsdb_head_series_created_total{endpoint="web",instance="<IP_ADDRESS>:9090",job="prometheus-prometheus-oper-prometheus",namespace="monitoring",pod="prometheus-prometheus-prometheus-oper-prometheus-0",service="prometheus-prometheus-oper-prometheus"} | 110206

prometheus_tsdb_head_series_removed_total
prometheus_tsdb_head_series_removed_total{endpoint="web",instance="<IP_ADDRESS>:9090",job="prometheus-prometheus-oper-prometheus",namespace="monitoring",pod="prometheus-prometheus-prometheus-oper-prometheus-0",service="prometheus-prometheus-oper-prometheus"} | 49306

I'm going to guess the first graph(s) are from the high CPU Prometheus server?

Looking quickly at the CPU profile, it looks like most of the time is spent in rules evaluation. From the collected metrics, the group that takes the longest time to evaluate is kube-apiserver.rules. I suspect you're hitting something similar to #503.

ok so what do I do about it? I just have the rules as set by the Prometheus operator helm chart. do I need to override them or just wait for another release?

FYI that first graph was after the High CPU prometheus was restarted

FYI I stopped monitoring apiserver and CPU dropped nicely. Thanks guys. I'll Close this Issue for now, we will be migrating to a later version of prometheus-operator (now kube-prometheus-stack) after our Christmas code freeze. I'll re-instate the monitoring of api server then to see if the fixes mentioned in #503 worked for us too


How to determine the number of matches

go version:1.12

package main

import (
	"fmt"
	"regexp"
	"sync"
)

func main() {
	r := "^(?Px){1,3}(?P123){0,2}(?Px){1,3}$"

	getParams(r, "xxx")
}

// Regex store complier
var Regex sync.Map

func getParams(regEx, str string) (paramsMap map[string][]string) {
	var compRegEx *regexp.Regexp
	tmp, ok := Regex.Load(regEx)
	if !ok {
		compRegEx = regexp.MustCompile(regEx)
		Regex.Store(regEx, compRegEx)
	} else {
		// panic
		compRegEx, ok = tmp.(*regexp.Regexp)
		if !ok {
			return nil
		}
	}

	match := compRegEx. FindStringSubmatch(str)
	if len(match) == 0 {
		return nil
	}
	fmt.Println(match)
	return nil
}

my question is:
how  to determine the number of matches of "x" ,the first regix mode "(?Px){1,3}"  matched quantity how much？and the second the mode "(?Px){1,3}" get how much?
i dont konw how to determine。who can tell me ？thank you very much

Hello @congci, unlike other projects, we do not use the issue tracker for questions such as these. It is only used for bugs and feature proposals. I will close this issue, but please feel free to ask it in any of these forums below:

Stack Overflow with questions tagged "go"

The Go Forum, a web-based forum

Gophers Slack, use the invite app for access. The #general channel is a good starting point.

Go Community on Hashnode with questions and posts tagged with "go"

The golang-nuts mailing list

IRC channel #go-nuts on Freenode

Thanks


Add support for a PID file

This PR adds support for a PID file containing the PID of the foreman process. This makes it very easy to put a foreman process in the background and stop it when needed.
for example, you can do something like this:
nohup foreman start --pidfile foreman.pid >/dev/null 2>&1 &
and close the terminal which keeps the process running. You can then do kill $(cat foreman.pid) in a different terminal and the process will cleanly shut down

This seems useful. Even a -d to daemonize would be cool

foreman is made to run in the foreground for development and is not meant to be a production-level process supervisor itself. Please use foreman export to export configuration files for production-level process supervisors.


FIX: repeating groups

@penberg @mstanichenko repeating groups is the only thing i believe is really beneficial at this point to FIX engine. there are certain messages that has repeating groups and yet performance critical (i.e. mass quote).
maybe you guys can think of a design for this? any suggestions on how API should look like?

I think we preserve the order of fields in struct fix_message so could probably have something like this:
struct fix_repeating_group {
    /* Number of fields in the group: */
    size_t count;
    /* Index of the first field in the group: */
    size_t start_idx;
};

int fix_get_group(struct fix_message *msg, int group_tag, struct fix_repeating_group *grp);
struct fix_field *fix_group_get_field_at(struct fix_message *msg, struct fix_repeating_group *grp, size_t idx);

@mstanichenko, thoughts?

we also need to unparse groups @penberg thx!

Hi guys,
Let me start with a side note. We already have something similar implemented in the FAST part of our library. We call it a sequence there not a repeating group but the underlying logic should be simular. I was thinking if we could apply it here but haven't found an elegant solution so far.
@divaykin, could you please tell what exactly you are looking for? Can't you work with repeating groups at all? Or just looking for a nice API to deal with them?
Generally, you should be able to deal with repeating groups. It works as following,

For an incoming message,  look for a field which tells you the number of elements in the group. Then read each element one by one. You can even skip an element by finding the field which starts the next element.
For an outgoing message, you are responsible to prepare fields array.

I totally agree with Pekka that from performance point of view we'd better not to modify fields' layout withing a message. We can just add extra functionality to deal with repeating groups upon request. I could imagine the following interface:
struct fix_group_meta {
   int count_tag;
   int begin_tag,
   struct fix_field *cur_entry
};

struct fix_group_meta group_meta = {
   //NoQuoteSets(296)
   296,
   //QuoteSetID(302)
   302,
   NULL
};
struct fix_field *group_entry;
size_t group_count;
int i;

msg = fix_session_recv(fix_session, recv);

group_count = fix_msg_group_count(msg, &group_meta);
for (int i = 0; i < group_count; ++i) {
    group_entry = fix_msg_group_next(msg, &group_meta);
    /*
     * Alternative variant which I don't like much
     * group_entry = fix_msg_group_entry(msg, &group_meta, i);
     */
}

fix_msg_group_count and fix_msg_group_next are easy to implement, for example
size_t fix_msg_group_count(fix_message *msg, struct fix_group_meta *group_meta)
{
  struct fix_field *field = fix_field_by_tag(msg->fields, group_meta->count_tag);
  if (field)
     return field->int_value;
  else
     return 0;
}

struct fix_field *fix_msg_group_next(msg, &group_meta)
{
  struct fix_field *start = group_meta->cur_entry ? group_meta->cur_entry : msg->fields;
  return fix_field_by_tag(start, group_meta);
}

struct fix_field *fix_msg_group_next(msg, &group_meta)
{
  struct fix_field *start = group_meta->cur_entry ? group_meta->cur_entry : msg->fields;
  group_meta->cur_entry = fix_field_by_tag(start, group_meta);

  return group_meta->cur_entry;
}

thanks @penberg @mstanichenko
@mstanichenko you right, probably it's possible to deal with groups by iterating fields in order, etc.
i'll follow your design, would make a parsing part of it. in terms of unparsing - probably i'd need just to increase max buffer length & number of fields to accommodate this.
or maybe i add user sized extra buffer to template?


seasocks::Server as both REST-server and WebSocket-server on single port runtime?

Can I run seasocks::Server as both REST-server and WebSocket-server on single port?
I want to make my server with REST-API and WebSockets API both in runtime.
Sample of my code:
seasocks::Server server(logger);
 auto restHandler = std::make_shared<MyRESTHandler>();
 server.addPageHandler(restHandler);
 auto wsHandler = std::make_shared<MyWSHandler>(&server);
 server.addWebSocketHandler("/path?ws", wsHandler);
 if(!server.startListening(my_port)) return EXIT_FAILURE;
 server.loop();

But requests like 'http://localhost:my_port/path' and 'ws://localhost:my_port/path?ws' routes into restHandler only. WebSocket-requests cannot routes to wsHandler =(
I don't understand the gist of seasocks kernel. Help me, please!

Yes, absolutely. This is how I ran it at my last company; several RESTful endpoints and one or two websocket endpoints.
The problem with your setup is you're trying to add a handler associated with a query string. The query string is not part of the path of the URL, and Seasocks doesn't support distinguishing websockets from regular REST requests on the query part.
It should work if you remove the ?ws part from both the addWebSocketHandler and the Javascript code you're using. Give it a try and let me know how you get on. Failing that I have some ideas on how to fix up the MyRESTHandler part.
Sorry this isn't more clear!

So, if I set different urls for REST-handler and WebSocket-handler (for example, /path and /ws), seasocks can work with both protocols?

That should work, yes.

Unfortunately all requests redirect into path handler, ignore websocket handler =(

Although, it's been a while... perhaps your handler needs to return a Response::unhandled() for anything it doesn't recognise...

Yes, it looks like you need to check for Websocket requests in your RESTful endpoint, and ignore:
if (request.verb() == Verb::WebSocket) return Response::unhandled();

should do the trick (or something similar!)

Hooray! Thanks for your patience, I hadn't remembered that the REST handlers get every request and are expected to indicate when they're not interested.


Fixed modal height

Fixed height of modal.

Description

[x] Visual changes (if any) are shown using screenshots/recordings of before and after.

Code style

[ ] composer cs command has been run.

Testing

[x] Changes have been tested.

Documentation

[x] Documentation is up-to-date.

Please npm run build and clear your browser cache


Next-step-suggestions

From an existing knowledge-base it should be possible to offer next-step suggestions to users. For clesperanto this is technially implemented but not yet available in the user-interface. For other libraries this should be more challenging. To simplify future development, it makes sense to implement it in a central place, e.g. here in napari-workflows. See also:

https://github.com/clEsperanto/pyclesperanto_assistant
https://www.biorxiv.org/content/10.1101/2<IP_ADDRESS>6565v1

This was implemented in the napari-assistant in this PR.


Remove extra scroll bar from Contributor's profile page.

There is an extra scrollbar in profile page.

@rithviknishad Please assign this issue to me.


Update test_costmodel.sh

Overview
Describe the big picture of your changes here. If it fixes a bug or resolves a feature request, be sure to link to that issue.
Changes
Describe the changes that your code introduces to FormS. Have you made corresponding tests and added the appropriate documentation for your changes? Do the commits pass the tests and follow the guidelines described here?
Example Output
Describe the expected behavior of your changes. If applicable, please include a screenshot.

close

delete


Item Consumable roll for healing/damage create unexpected error when clicking damage or heal

V10.291
PF2e 4.6.4
https://user-images.githubusercontent.com/47077661/211208564-91bfde51-44ba-4d4f-8a99-a63a3f07d490.mp4

I don't think this is a Target Damage issue as much as a PF2e issue. Reimport the elixir and try again.


Call service using payload properties

I'd like the ability to call a service (e.g. light.turn_on) and set the entity ID based on a msg property (e.g. msg.payload.entity_id).

This has been supported for awhile now and it's usage is documented on the call service node's info tab.  All you have to do is pass in the override, but it needs to be nested within the data property.  Example: msg.payload = { data: { entity_id: 'light.office_1'} }

Great! Thanks.

Apologies if this is a dumb question, but how do I pass multiple data points to a service call? ie setting the volume, I've tried a few variations of this...
"{ data: { 'entity_id': 'media_player.stereo'},{'volume_level': '0.55' } }"


Hidden not working on v 1.6.0

Hi,
I've just upgraded to v 1.6.0 and I think the 'hidden' property doesn't appear to work.
After setting 'hidden' the html contains
<div class="tp-lblv tp-v-hidden">...
The css contains
.tp-v .tp-v-hidden { 	display: none }
So the input is not hidden? Either the input needs the .tp-v class or the css needs additional rules?
Chris

Thank you for reporting the issue. Fixed the problem and just released the latest version 1.6.1.
https://github.com/cocopon/tweakpane/releases/tag/1.6.1

Thanks - you are great, so quick.
Tested, issue fixed!
Chris


Feature: state saving

Dear Mike,
Here are the changes we implemented in Excimontec to allow state saving. There are some changes to be made before we can merge as for example, the tests do not currently run as we added the random seed to the OSC_Sim::init() function. Also the changelog still has to be modified and a test is still to be written for the import and export occupancy functions.
The code does run without problems on our cluster as is.
I would very much like to hear your opinion on our changes and your ideas on what we should add before we can merge to the main repository.
Kind regards,
Marten

I did a major refactor and got everything working now in preparation to get this into a v1.1 beta release.  It would be good if you could test out this new version on your cluster to make sure it works well.
Right now the generator seed is set via command line arguments like so,
Excimontec.exe parameters.txt -seed 100
which sets the seed to 100. Enabling a steady transport test to be resumed is also done via command line argument.  Running a steady transport test will automatically create a site energy file and state files during the equilibration phase. The occupancy information in the state file is compressed using run length encoding so they take fairly little space and don't use much IO.  You can adjust the state saving interval in the parameter file to your liking, but a value of 10,000 events is used by default. You can resume a steady transport test by having the state files (STT_equilibration_state_#latest.txt) and the site energies files (site_energies#.txt) in the working directory and restarting the simulation like so
Excimontec.exe parameters.txt -seed 100 -resume_stt
When resuming the simulation, it will start where it left off in the equilibration phase and continue the steady transport test.  You do not need to worry about if the processors get out of sync since they will each get resumed and continue to the same stopping condition.


Docs: Dead links to "contribution guidelines" page

Page URL:

https://www.typescriptlang.org/docs/handbook/declaration-files/consumption.html#searching
https://www.typescriptlang.org/docs/handbook/declaration-files/publishing.html#publish-to-types

Issue:
These two pages include links to this URL, which currently returns a 404 page: https://www.definitelytyped.org/guides/contributing.html
I was searching for a reference that showed how to create a @types package for a NPM module that already had an org (e.g. @some-lib/button-component). (Used the "Search for typed packages" to find out that it looks like it works as @types/${orgName}__${packageName}).
There are two pages that include links to the "Contribution Guidelines" page
https://github.com/microsoft/TypeScript-Website/blob/d4f04091f8d4386f6927b20906667e847d9d3471/packages/documentation/copy/en/declaration-files/Publishing.md?plain=1#L182
https://github.com/microsoft/TypeScript-Website/blob/d4f04091f8d4386f6927b20906667e847d9d3471/packages/documentation/copy/en/declaration-files/Consumption.md?plain=1#L44
Recommended Fix:
I'm not sure, did the page just get moved and links need updating? Or was it removed altogether and these sections should be deleted?

Looks like that domain expired and got taken over, we should drop all references to it.

Is there any existing page that documents the @types npm namespace?

The definitely typed readme is probably a good enough  link I think


Fix bug in level control move [bug fix]

Command chip-tool levelcontrol move 0 0 1 1 42 2 throws error Stop reason: signal SIGFPE: integer divide by zero because of division by zero in rate handling in LevelControl cluster. This PR checks if rate equal to zero, and if it is, consider it to be null.

 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.

Closing as duplicate of https://github.com/project-chip/connectedhomeip/pull/32539


[FeatureRequest]: Add url for cloud build when the build starts

Contact Details
<EMAIL_ADDRESS>Is your feature request related to a problem? Please describe
When the cloud build of the image starts, I must manually navigate to it in the browser if I want to see the progress.
Describe the solution you'd like
In the output, e.g.
✅ Reading and validating wanna yaml config
ℹ GCP profile 'wanna-dev' will be used.
ℹ Profile details: profile_name='wanna-dev' project_id='...' zone='europe-west1-b' region='europe-west1' labels=None bucket='...' service_account='...' network='...'
subnet='...' kms_key=None docker_repository='wanna-dev' docker_registry=None env_vars=None
ℹ Building train_serve_all docker image in GCP Cloud build

I would like to see the linkhttps://console.cloud.google.com/cloud-build/builds;region=europe-west1?project=...
The same would be nice for the JupyterLab in Vertex AI Workbench
Describe alternatives you've considered
No response
Additional context
No response

Featured added to the 0.3.3 release


No GPS lock on TTGo TBeam V1.1

Hi I'm able got get the Lora radio to connect to hotspots and can see the join requests and acceptance packets in the helium console. However the GPS never gets a lock so I cannot send data to the mappers integration point. The version 1.1 and version 1.0 use the same pins for the GPS module. Has anyone else been able to resolve this issue of no GPS lock?

Hi Everyone I was able to resolve it. Turns out my GPS module was not outputting NMEA. I used the following v3 sketch by eriktheV-King to resolve this: https://github.com/eriktheV-king/TTGO_T-beam_GPS-reset


Check for collections.abc.Mapping instead of dict when converting a…

… pydantic field to a dict.

Change Summary
We would like to be able use a custom immutablefrozendict in fields as pydantic and have dict() continue to work as expected. So we should use a more generic type like collections.abc.Mapping instead of dict to make sure that we still convert it to a dict.
Related issue number
N/A
Checklist

[x] Unit tests for the changes exist
[x] Tests pass on CI and coverage remains at 100%
[x] Documentation reflects the changes where applicable
[x] changes/<pull request or issue id>-<github username>.md file added describing change
(see changes/README.md for details)
[x] My PR is ready to review, please add a comment including the phrase "please review" to assign reviewers

please review

please review

If I have
    class Model(BaseModel):
        a: MyCustomMap[str, int]

I expect my value in the dict representation to be a instance of MyCustomMap, not a dict.
Please open an issue before to talk about this


Chef Server Analytics Queue Depth Should Be Capped When No Consumer Present

As a customer, I want the chef server to be as resilient as possible to unexpected conditions.
An unexpected, but common condition that occurs is that the Analytics server goes offline and stops consuming messages from the "/analytics/alaska" and potentially other queues. When this happens, the messages build up without limits and eventually fill all available disk space and cause a failure of the chef server system, by swapping, rabbitmq paging out to disk, and other general expected unpleasantness.
To remedy this situation, whatever chef server component writes to these queues should stop writing if it detects no consumption and that the queue is growing.
Zendesk 3070 and https://github.com/chef/omnibus-analytics/issues/179

A better solution here may just be to set the rabbitmq max queue length for the relevant queues:
http://www.rabbitmq.com/maxlength.html

Cool, sounds like a good addition for all queues. If the expander stops working for any reason, the incoming node.save and other objects can and have overrun chef server systems in the past. So, the issue is not limited to just Analytics.

This is currently implemented at a few customer sites
rabbitmqctl set_policy -p /analytics max_length '(alaska|notifier.notifications|notifier_config)' '{"max-length":1000}' --apply-to queues

The problem with setting a max depth for the analytics queue is that we'll miss messages, which won't work for people that are using Analytics for compliance etc. I'm implementing a opscode-analytics-ctl plugin that will remove the queue and/or /analytics vhost and allow for reconfiguration if desired.

@metadave I may not be understanding all the details here.  How will these -ctl commands help us in the face of a analytics server that temporarily gone offline?
What is the customer expected behavior?  If the customer expect that we will never lose analytics data even in the face of a network partition or temporary analytics outage, I think we need something that informs the chef-server "no more writes until analytics catches up."

uh, backpressure can be tricky.
The opscode-analytics-ctl commands are for users that want to disable analytics. For temporary outages, a max-depth is probably fine for users that aren't using compliance features. We'll have to give compliance some thought.

Zendesk 3070 , 3385, and 3297, all Sev1/2 have resulted from unlimited access to queues.

Cool, thanks for patching up customers on the Sev1/2's. We're committed to cleaning up scalability and reliability quite a bit this quarter.

@metadave jhs had the same thought. Compliance customers could be considered to be in a class of their own. It would seem everyone else's chef server would benefit from this addition. Then, we just allow opscode-omnibus changes when full durability is prescribed for the Compliance config case.

@metadave I spent a lot of time replicating this problem after one of the more recent severe outages and I completely agree with what @sean-horn is saying.
All rabbitmq queues need to be capped by default in order to provide the best experience with least surprise. This cap can still be reasonably large enough to avoid losing messages in most situations while still preventing worst case situations like filling the disk with persistent messages.
Capping the queues by default doesn't necessarily mean messages will be lost. Messages will only get lost if that cap is reached and if that happens then something else is wrong in the first place and needs to be addressed.
The Compliance/Audit use case should be treated as the exception and a tool should be created to disable the cap or adjust its size and Compliance/Audit related documentation should clearly point to the need for using that tool. The documentation should also make it clear the dangerous potential that awaits the uncapped queue. They potentially have a lot more to lose than messages with an uncapped queue.
In my opinion, the tool shouldn't even remove the cap. Even in the Compliance/Audit use case the cap could (should) still remain to safe guard against filling the disk or otherwise cause problems. Analytics consumers shouldn't be down for such a long time that the cap gets hit if the user really cares about the data. If consumers need to be down then the user should appropriately account for this by reducing the amount of messages created (e.g. reducing number of chef-client runs, etc) to avoid hitting the cap.
Without capped queues you run the risk of either filling disks and breaking the system in much worse ways or running into rabbitmq memory problems or eventually restarting rabbitmq only to find out it takes an unreasonable amount of time to start because it is reindexing hundreds of GBs of messages. All of these situations require unexpected downtime and some even raise the potential for corrupting data.
We have seen all of these situations in real world installs. Once these situations occur you simply can not manage rabbitmq queues because rabbitmq isn't able to fully start and bind to the management ports. In every instance I know of we had to resort to deleting the persistent messages from disk manually in order to restore a functional Chef Server. Obviously this resulted in lost messages anyway and a lot worse experience.

I agree analytics queues should be capped. Not a fan of capping the expander queue, because that leaves the index in an inconsistent state until it is rebuilt by hand.

I'm closing this out as I think it was handled by Dave's work in 4a4b05c6c826967ecb4c303cf944c69ed0024e6c which caps the analytics queue to 10000 messages by default.


DPID Schema Extraction

Just wondering if anyone could explain how the schemas are stored in flash.
I found the SSID/password and some other JSON strings, and I can see that the data at 0x1EF000 changes after the device has connected. However, I can't quite figure out how the schemas are encoded... Are they stored as cJSON structs or something? How does the binary data correspond with the JSON files in the device profiles?
I've been finding this project super interesting, so any insight would be appreciated 🙂

The data stored in the upper flash blocks is encrypted using AES with a key derived from some constant strings AND an encrypted key stored in another block.
The encrypted part is a proprietary Tuya key-value storage format, that contains raw JSON data, including the UUID, AuthKey, PskKey as well as the firmware key and version numbers, and the data point descriptions.
So, having a dump should make it possible to not only find right code addresses, but also extract the device schema, without connecting to Tuya servers.
Note that the device schema is likely present after pairing the device first.

bk7231tools has been updated to include storage dumping.  If the device has a user_param_key array, pin mappings will be contained in that section (Most devices do, but not all.  It is possible [and likely] a device must be paired with Smart Life for that data to exist)

Thanks for the update! I just tested storage extraction on a dump I had lying around and it seemed to work well 🙂
It looks like most of the juicy details I was interested in can be found in storage.py, so I'll close this issue.


GraphQL route for dumping entity changes in subgraph and block

Closes https://github.com/graphprotocol/graph-node/issues/3274.
The GraphQL API implemented here looks like the following (a bit different from #3274's first draft; after collecting feedback):
type Query {
  entityChangesInBlock(subgraphId: String!, blockNumber: Int!): EntityChanges!
}

type EntityChanges {
  updates: [EntityData!]!
  deletes: [String!]!
}

type EntityData {
  name: String!
  fields: [EntityField!]!
}

type EntityField {
  field: String!
  valueAsJSON: String!
}

@jannis I'm also removing __typename since it's redundant data.


Update the list for mappings in Admin UI after curation has been submitted

Describe the bug
A clear and concise description of what the bug is.
To Reproduce
Steps to reproduce the behavior:

Go to Admin UI
Click on Curation Mappings - Diagnosis - Missing mappings
Choose a mapping
Close the Window as prompted
See that list of unmapped diagnosis disappears

Expected behavior
The list of unmapped diagnosis (or drugs) should remain for further curation
Screenshots

not relevant as will have a new implementation. closing


Guide - Wrong folder name for static files

What happened?
In the guide, section Static files, the document said that the

Reposilite creates public directory in workdir.

and

Using public directory you can implement frontend on your own. Because assets have lower priority, you have to disable frontend in the local configuration file:

However, when I created a folder name public/ and put my custom frontend, it didn't work
Instead, I found that the folder name static/ is created, and when I put to that folder, it works!
So, I request you to update the Guide, section Static files with that information.
Reposilite version
3.x
Relevant log output
No response

Thanks, fixed :ok_hand:


Modularize the Jenkins build indexing and publishing code

The current code in the Jenkinsfile relies upon as combination of https://github.com/Knowledge-Graph-Hub/go-site/blob/master/scripts/directory_indexer.py and setting up local directories to be copied to S3, but at minimum it should also (ideally as a modified version of the directory_indexer) index all directories/files on the bucket but not present locally.
Given a bucket and a directory name, this should just make an index in that directory. In the current Jenkins setup this may mean  running another s3cmd put to upload the new index.
In the slightly longer term, the entire process of indexing and uploading can be its own modular script.
See https://github.com/Knowledge-Graph-Hub/kg-obo/blob/552192a22e47b2a0a0860a509fed32983e079a96/kg_obo/upload.py#L253

This is already quite modular - it has no KG-IDG dependencies.


ss58 decoded lengths

@kratico pointed out an interesting constant in the PolkadotJS util crypto source. Does this suggest some behavior which is currently unaccounted for? Worth revisiting.

We can get rid of this check; addresses can be invalid in a multitude of other ways, and so we'll just let it all error downstream.

@kratico was this resolved by #751? If so, please close.


A rough idea of a code structure

This PR is in responses to #3 and an outline to what was discussed there. It contains no implementation details.
Perhaps, it would be worthwhile to have an additional enum that would contain the different types of interfaces so that we can abstract away what type of interface we actually have.
enum Interface {
    Serial(SerialInterface),
    OpenOCD(OpenOCDInterface),
    JLink(JLinkInterface)
}

fn create_interface(cli_args: ...) -> Interface {
    ...
}

But then, it would be a bit inconvenient to then call any type of function defined in BoardInterface, and the whole concept of BoardInterface and Interface kinda overlap as a concept.
let interface = create_interface(cli_args);

interface.open(); // doesn't work as Interface does not implement 'BoardInterface'

match interface {
    Interface::Serial(serial) => serial.open();
    ...
}

As an alternative, we could hide the whole match call into an implementation of BoardInterface for Intreface. Possibly, a macro could also be helpful here.
We could then again forget about the enum altogether and just use function parameters that implement the BoardInterface trait:
fn listen(interface: &impl BoardInterface) {
    ....
}

But this way we need different code paths for all the the interfaces:
if cli_args.has_openocd_flag() {
    listen(create_openocd(cli_args));
} else ...

Suggestions?

After some research, I've realized enum_dispatch could be useful for us. I'm still a bit unsure about the naming, BoardInterface and Interface names are quite similar and overlap in their purpose.

The code structure looks ok, but I don't really understand the need for the enum_dispatch.
Otherwise, on the long term it might be a good idea to separate the traits (such as board_interface) and the implementations (such as jlink) if many trait instances will appear.

enum_dispatch isn't needed, but it will minimize the amount of code written. Let me exemplify why.
So, we have 3 interfaces (structs): JLinkInterface, OpenOCDInterface and SerialInterface, all of which implement the trait BoardInterface. Let's imagine how we could use them. We know we want to be able to interact with a board in any way the user desires - for example if I hook up my board to my PC, I can tell (python) tockloader specifically if I want to use OpenOCD or Serial, and the way I do it is by specifying --serial as a command line argument or not.
The rust-equivalent code would look something like this:
/* cli parsing */
if cli_args.has_flag("serial") {
   /* Initialize Serial Interface*/
} else {
   /* Initialize OpenOCD Interface*/
}

The problem now comes, how do we initialize them? We can't do
let interface = if cli_args.has_flag("serial") {
    OpenOCDInterface {port: 22} // "port" is just an example struct member. We could have a function here instead, idk
} else {
    SerialInterface {port: 22}
};

interface won't have a type known at compile-time. So we could use Box<dyn BoardInterface> to solve the issue:
fn get_interface(args: ...) -> Box<dyn BoardInterface> { /*...*/ }

let interface = get_interface(cli_args);
interface.open();

But this has two downsides:

Performance overhead. enum_dispatch explains a bit why that is.
Using a Box<dyn ...> is messy when passing is as an argument to other functions (which we might need to do)

fn get_data_from_interface(interface: &(impl BoardInterface + ?Sized)) -> u32 { /* ... */ }
// ...
let data = get_data_from_interface(interface.as_ref());

A (cleaner) alternative would be using an enum ( as I have in this PR).
pub enum Interface {
    Serial(SerialInterface),
    OpenOCD(OpenOCDInterface),
    JLink(JLinkInterface),
}

fn get_interface(args: ...) -> Interface { /*...*/ }
fn get_data_from_interface(interface: Interface) -> u32 { /* ... */ }

let interface = get_interface(cli_args);
let data = get_data_from_interface(interface);

The issues with this comes when we try to interact with the BoardInterface trait. Although all variants of this enum implement BoardInterface, Interface enum doesn't implement it. So doing interface.open() is not possible. We could then implement the trait on it:
impl BoardInterface for Interface {
    fn open(&mut self) -> Result<(), TockloaderError> {
        match self {
          Interface::Serial(a) => a.open(),
          Interface::OpenOCD(b) => b.open(),
          Interface::JLink(c) => c.open(),
        }
    }
}

This isn't that bad, it's quite readable code. The issue comes when we have many traits with many defined methods.
enum_dispatch is a programmatic macro crate which takes care of this code repetition.
Personally, I think enum_dispatch is the best option out of the ones I have presented (and that I know of).

It makes sense. Thanks for the explanation. The only thing that remains on long term is splitting the traits and the implementations into separate folders if needed.

@valexandru Is this (latest commit)) what you had in mind?

I was thinking, maybe we should use anyhow::Error instead of TockloaderError. Or maybe both? After working with TockloaderError, it definitely felt a bit... useless, or extra code for little reason. Most of the error cases would be errors from other crates.

Okay, after some research I've narrowed down our possibilities of error-handling:
1. Keep going as is with std error
I'm not a fan of this, but it is the most lightweight version. Furthermore, if we do keep the tbf-parser library in here, their error-handling would be similar (as the other options may require the use of std, which we should avoid to maintain potential compatibility with the version on the tock repo.)
2. anyhow crate
Anyhow would be a simple solution. Whenever we get an error - just bail!() - we don't care what it is that went wrong or why it originated. Eventually, we give some context clues to the user via an error message.
3. thiserror crate
This would make the creation of errors a bit nicer, but then again a non-trivial effort. Not to mention if anyone not used to rust were to come work on the project, they might be required to introduce a new error. Learning a bit of thiserror might be an extra step, although not a huge one.
Reports?
Rust does have a new, experimental, feature called Reports. It's supposed to work in conjunction with the regular errors as opposed to a replacement. I'm not sure how useful it would be to us since we won't really have nested errors (or at least not deep enough for a error trace to make much sense). The additional costs in maintaining it aren't worth the advantages it brings, but I did consider worth mentioning here, just to bring it into discussion.
My suggestion
I would personally opt to use thiserror. While anyhow might be the most logical choice, we have binary app, and we want to return error messages to the user, not another application, I still believe that a tight type system feels more rust-like. Although I am not certain that this is actually the best option. I could easily see the following scenario repeat again and again: adding a variant which would only be used in a single place. Unless a non-trivial amount of time is put into the design of TockloaderError to have generic, multi-use variants, I could certainly see hyper-specific enum variants pop up every other pull request. Not amazing.
Any suggestions?


used ebpf to record container behavior, but found that I could not record syscall in the shell script running process in the container.

What happened:
Hello, I recently used ebpf to record container behavior, but found that I could not record syscall in the shell script running process in the container. As a result, some functions of pod could not be used normally after I mounted JSON files.
What you expected to happen:
Syscall can also be recorded normally during script execution in the container。
How to reproduce it (as minimally and precisely as possible):
Execute shell script inside POD
Environment:
Linux k8s-master-node-1 5.13.0-39-generic #44~20.04.1-Ubuntu SMP Thu Mar 24 16:43:35 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux

Cloud provider or hardware configuration:
OS (e.g: cat /etc/os-release):
Kernel (e.g. uname -a):
Others:

Hey @longpi1, may I ask you to share the container image for the reproducer?


Fix Gitbook links

I copied sections of our github url, rather than our gitbook url, when predicting the url. My bad.

This change is

Coverage remained the same at 82.609% when pulling cb2f7b39e891d1311c67b1787b7e5249e17d0071 on Judahmeek:master into 37712eeb351767ab90ebfb1eb6d1134565550369 on shakacode:master.


What if the array of objects on the backend change?

For instance if I have an endpoint where I'm patching a list of customers where the subset array of object changes relatively often, how do I know that the patch is on the correct array of objects?

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

ID: 593f528c-61b9-7021-335d-c1c0ec1814d1
Version Independent ID: 6a88d237-1a03-b865-e3c5-20ceedef2a1f
Content: JsonPatch in ASP.NET Core web API
Content Source: aspnetcore/web-api/jsonpatch.md
Product: aspnet-core
Technology: aspnetcore-webapi
GitHub Login: @tdykstra
Microsoft Alias: tdykstra

@GSUFan513 Thanks for the question. You'll probably get a faster answer on a support forum, such as StackOverflow, or a support chat, such as Slack or Gitter. If you post the question elsewhere, please update this issue with the link.


[FX-4613] Delete InputLabel component

FX-4613
Description
This pull request deletes the InputLabel component instead of migrating it to Tailwind because it is not used anywhere.
How to test

Temploy
Search for InputLabel usages via https://github.com/search?q=org%3Atoptal "InputLabel"&type=code, there should be no usages by actual consumers
Visual tests should pass (there is one failing test, but it is a usual flaky suspect)

Development checks

[x] Add changeset according to guidelines (if needed)
[x] Read CONTRIBUTING.md and Component API principles
[N/A] Make sure that additions and changes on the design follow Toptal's BASE design, and it's been already discussed with designers at #-base-core
[N/A] Annotate all props in component with documentation
[N/A] Create examples for component
[N/A] Ensure that deployed demo has expected results and good examples
[N/A] Ensure the changed/created components have not caused accessibility issues. How to use accessibility plugin in storybook.
[x] Self reviewed
[N/A] Covered with tests (visual tests included)

Breaking change

[N/A] codemod is created and showcased in the changeset
[x] test alpha package of Picasso in Staff Portal https://github.com/toptal/staff-portal/pull/12731 (Check:Lint, Build Image, pass Test:Jest, and Test:Cypress failures are not related to change)
[x] test alpha package of Picasso in Client Portal https://github.com/toptal/client-portal/pull/9060 (all diffs in Happo (client-portal) are about fonts rendering)

All development checks should be done and set checked to pass the
GitHub Bot: TODOLess action

PR commands

List of available commands:

@toptal-bot run package:alpha-release - Release alpha version
@toptal-anvil ping reviewers - Ping FX team for review

PR Review Guidelines

When to approve? ✅
You are OK with merging this PR and

You have no extra requests.
You have optional requests.

Add nit: to your comment. (ex. nit: I'd rename this variable from makeCircle to getCircle)

When to request changes? ❌
You are not OK with merging this PR because

Something is broken after the changes.
Acceptance criteria is not reached.
Code is dirty.

When to comment (neither ✅ nor ❌)
You want your comments to be addressed before merging this PR in cases like:

There are leftovers like unnecessary logs, comments, etc.
You have an opinionated comment regarding the code that requires a discussion.
You have questions.

How to handle the comments?

An owner of a comment is the only one who can resolve it.
An owner of a comment must resolve it when it's addressed.
A PR owner must reply with ✅ when a comment is addressed.

@toptal-bot run package:alpha-release

@toptal-anvil ping reviewers


Support BearerAuthentication as Security option

Is your feature request related to a problem? Please describe.
swag does not have support to generate security scheme based on Bearer Authentication
Describe the solution you'd like
Provide option to have bearer auth as security scheme

True and at the same it's normal because swag is OAS2 spec and you are providing the link to OAS3 spec.
Duplicate https://github.com/swaggo/swag/issues/1100


Username + email index is too long for production InnoDB implementation

MariaDB tops out at 767 bytes for index keys. We have a username limit of 100 characters and an email limit of 200. Since we're using utf8mb4, that would require 1200 bytes for keys. This blocks conversion of the user table to InnoDB in production, from MyISAM, so #649 isn't quite complete.
The longest email address we have is 78 characters. The longest username we have is the full 100 characters, but the three accounts >= 72 characters all appear to be spam accounts anyway.
My suggestion here is to add a patch that bumps the username column down to 72 characters max, and email down to 100. If we want to notify the (suspected spam) accounts of their new usernames, easy enough to do so. In this patch we should rerun the InnoDB conversion for the user table so that when it's run in production we get rid of that last MyISAM table.

When I see that right these are two indices. One for the username (100 characters * 4 = 400 byte so that shouldn't be an issue to convert) and one for the email-address (200 characters * 4 = 800 byte).
The index for the email-address therefore is 33bytes or 9 characters to long.
I'd therefore propose to reduce the email-address field to 190 characters.

We have an index that includes a combination of username and email.
MariaDB [joindin]> show indexes from user\G
*************************** 1. row ***************************
        Table: user
   Non_unique: 0
     Key_name: PRIMARY
 Seq_in_index: 1
  Column_name: ID
    Collation: A
  Cardinality: 69859
     Sub_part: NULL
       Packed: NULL
         Null:
   Index_type: BTREE
      Comment:
Index_comment:
*************************** 2. row ***************************
        Table: user
   Non_unique: 0
     Key_name: idx_username
 Seq_in_index: 1
  Column_name: username
    Collation: A
  Cardinality: NULL
     Sub_part: NULL
       Packed: NULL
         Null: YES
   Index_type: BTREE
      Comment:
Index_comment:
*************************** 3. row ***************************
        Table: user
   Non_unique: 0
     Key_name: idx_email_1
 Seq_in_index: 1
  Column_name: email
    Collation: A
  Cardinality: NULL
     Sub_part: NULL
       Packed: NULL
         Null: YES
   Index_type: BTREE
      Comment:
Index_comment:
*************************** 4. row ***************************
        Table: user
   Non_unique: 0
     Key_name: idx_email
 Seq_in_index: 1
  Column_name: email
    Collation: A
  Cardinality: NULL
     Sub_part: NULL
       Packed: NULL
         Null: YES
   Index_type: BTREE
      Comment:
Index_comment:

You didn't. I did. Got confused by the fact that we have two indexes on email (we should only have one). 190 characters would solve the problem.

Interesting question is: where does the second index on the email-address come from!

Looks generic; idx_email_1 is the name of the index. Looks to be an exact duplicate, so we can drop that extra index as part of this patch/fix.

In fact this can be resolved by setting the ROW_FORMAT of the table to DYNAMIC.
The server has to support Baracuda as the innodb_file_format, which should be the case in most installations.
It can easily be solved by using ROW_FORMAT=DYNAMIC when creating or modifying the table.
At a server level you can set innodb-default-row-format in the servers config to default to dynamic, byt this only works on mariadb 10.2.2, 10.1.32 and MySQL 5.7 upwards.
setting
innodb_file_format      = Barracuda
innodb_file_format_max  = Barracuda
innodb_file_per_table   = 1
innodb_large_prefix     = ON
in the servers configuration allows for this to be the defaults from mysql 5.6 upwards.

As long as that works in the dev-setup as well, that's OK...


use cluster names to check existing clusters

requires https://github.com/RedHatQE/openshift-cli-installer/pull/141

/verified

/lgtm


Add wrapper allowing error object to be used as resolved value

Made throwing an optional behavior instead of doing it by default.


fix(executor): emissary works with nonroot sidecars + input/output params & artifacts

This fully fixes emissary + nonroot.
I've tested sidecars, input/output parameters and artifacts
Checklist:

[ ] My organization is added to USERS.md.

Tips:

Your PR needs to pass the required checks before it can be approved. If the check is not required (e.g. E2E tests) it does not need to pass
Sign-off your commits to pass the DCO check: git commit --signoff.
Run make pre-commit -B to fix codegen or lint problems.
Say how how you tested your changes. If you changed the UI, attach screenshots.

Hi @alexec, I wonder whether you have any docs or examples for how to add workflows as tests?
I think it'll be a lot more confident checking in workflows to verify the fix and make sure we don't break it in the future.

nonroot sidecar example:
#### sidecar example ####
apiVersion: argoproj.io/v1alpha1
kind: Workflow
metadata:
  generateName: nonroot-sidecar-
spec:
  serviceAccountName: pipeline-runner
  entrypoint: sidecar-example
  templates:
  - name: sidecar-example
    container:
      image: alpine:latest
      command: [sh, -c]
      args: ["
        apk update &&
        apk add curl &&
        until curl 'http://<IP_ADDRESS>:8080'; do sleep 5; done &&
      "]
    sidecars:
    - name: http-echo
      image: mendhak/http-https-echo:19
      command: ['docker-entrypoint.sh']
      args: ['node', './index.js']
      envs:
      - name: HTTP_PORT
        value: 8080

nonroot parameter passing
#### parameter passing test workflow for non-root ####
# Output parameters provide a way to use the contents of a file,
# as a parameter value in a workflow. In that regard, they are
# similar in concept to script templates, with the difference being
# that the output parameter values are obtained via file contents
# instead of stdout (as with script templates). Secondly, there can
# be multiple 'output.parameters.xxx' in a single template, versus
# a single 'output.result' from a script template.
#
# In this example, the 'whalesay' template produces an output
# parameter named 'hello-param', taken from the file contents of
# /tmp/hello_world.txt. This parameter is passed to a subsequent
# step as an input parameter to the template, 'print-message'.
apiVersion: argoproj.io/v1alpha1
kind: Workflow
metadata:
  generateName: nonroot-parameter-
spec:
  serviceAccountName: pipeline-runner
  entrypoint: output-parameter
  templates:
  - name: output-parameter
    steps:
    - - name: generate-parameter
        template: whalesay
    - - name: consume-parameter
        template: print-message
        arguments:
          parameters:
          - name: message
            value: "{{steps.generate-parameter.outputs.parameters.hello-param}}"

  - name: whalesay
    container:
      image: curlimages/curl:latest
      command: [sh, -c]
      args: ["sleep 1; echo -n hello world > /tmp/hello_world.txt"]
    outputs:
      parameters:
      - name: hello-param
        valueFrom:
          default: "Foobar"   # Default value to use if retrieving valueFrom fails. If not provided workflow will fail instead
          path: /tmp/hello_world.txt

  - name: print-message
    inputs:
      parameters:
      - name: message
    container:
      image: curlimages/curl:latest
      command: [sh, -c]
      args: ["echo {{inputs.parameters.message}}"]

non root hello world workflow:
#### one step test workflow for non-root ####
apiVersion: argoproj.io/v1alpha1
kind: Workflow
metadata:
  generateName: nonroot-helloworld-
spec:
  serviceAccountName: pipeline-runner
  entrypoint: hw
  templates:
  - name: hw
    container:
      image: curlimages/curl:latest
      command: [sh, -c, "echo hello"]

nonroot artifact passing workflow:
#### artifact passing test workflow for non-root ####
# This example demonstrates the ability to pass artifacts
# from one step to the next.

apiVersion: argoproj.io/v1alpha1
kind: Workflow
metadata:
  generateName: nonroot-artifact-
spec:
  serviceAccountName: pipeline-runner
  entrypoint: artifact-example
  templates:
  - name: artifact-example
    steps:
    - - name: generate-artifact
        template: whalesay
    - - name: consume-artifact
        template: print-message
        arguments:
          artifacts:
          - name: message
            from: "{{steps.generate-artifact.outputs.artifacts.hello-art}}"

  - name: whalesay
    container:
      image: curlimages/curl:latest
      command: [sh, -c]
      args: ["sleep 1; echo hello world | tee /tmp/hello_world.txt"]
    outputs:
      artifacts:
      - name: hello-art
        path: /tmp/hello_world.txt

  - name: print-message
    inputs:
      artifacts:
      - name: message
        path: /tmp/message
    container:
      image: curlimages/curl:latest
      command: [sh, -c]
      args: ["cat /tmp/message"]

@alexec thanks for the review! Updated to os specific

Any guidance for

Hi @alexec, I wonder whether you have any docs or examples for how to add workflows as tests?
I think it'll be a lot more confident checking in workflows to verify the fix and make sure we don't break it in the future.
?

@sarabala1979 this needs to be back-ported to v3.1. Do you think we should do another patch release this week?


Fixed launch file by using a list for arguments.

Arguments were being fed in a random order. Using a list ensures that it is consistently being fed in order.

@mergify backport main galactic

@mecarill thanks a lot for the contribution, good catch


Fix temporary dataset_path creation for URIs related to remote fs

This aims to close #3295

Hi ! Thanks for the fix :)
I think this should be extract_path_from_uri 's responsibility to strip the extra / from a badly formatted path like hdfs:///absolute/path (or raise an error). Do you think you can simply do the changes in extract_path_from_uri ? This way this fix will be available for all the other parts of the lib that need to extract the inner path from an URI of a remote filesystem
Then we can also keep your test cases but simply apply them to extract_path_from_uri instead

Hi @lhoestq! No problem! Thanks for your interest! :)
I think stripping the 3rd / in hdfs:///absolute/path inside extract_path_from_uri is not the solution. When I provide hdfs:///absolute/path to extract_path_from_uri we want /absolute/path to be returned, as it does now (at least in the case of URIs with hdfs schemas, for s3 is different as it should start with a bucket name).
The problem comes in line 1041 in the original code below:
https://github.com/huggingface/datasets/blob/42f6b1d18a4a1b6009b6e62d115491be16dfca22/src/datasets/arrow_dataset.py#L1038-L1042
Lets assume the following parameters for line 1041 after extract_path_from_uri has removed the hdfs schema part and the :// from hdfs:///absolute/path, and get_temporary_cache_files_directory() returns /tmp/a1b2b3c4, as it is shown below:
src_dataset_path = '/absolute/path'
tmp_dir = '/tmp/a1b2b3c4'
dataset_path = Path(tmp_dir, src_dataset_path)

After passing those paths to the Path object, dataset_path contains only /absolute/path; that is, it has lost the temporary directory path. This is because, when two (or more) absolute paths are passed to the Path function, only the last one is taken. However, if the contents of those variables are:
src_dataset_path = 'relative/path'
tmp_dir = '/tmp/a1b2b3c4'
dataset_path = Path(tmp_dir, src_dataset_path)

then dataset_path contains /tmp/a1b2b3c4/relative/path as expected.
Absolute paths are allowed in hdfs URIs, so that's why I added the extra function build_local_temp_path in the PR; so in case the second argument is an absolute path, it still will create the correct absolute path by concatenating the temp dir and the path passed by converting it to a relative path (and it also works for windows paths too.) It also allows to add the tests, checking that the main combinations are ok.
I've checked all the places where the result of extract_path_from_uri is used, and as far as I've seen this is the only place where it is concatenated with another possible absolute path, so no need to add build_local_temp_path anywhere else.


Pricing?

Giving your customers 1 week to decide without any information on MAU pricing model is not appropriate. We're in the middle of looking at B2C and thankfully we caught this on the last day before the permanent switchover. We provisioned a B2C just to reserve the old model. What is the new pricing model? How come there is no information?

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

ID: 10c6698d-da67-a802-3f77-ae8091ea4782
Version Independent ID: b5397a88-c4df-26d2-e9d2-29491d76ea00
Content: Billing model for Azure Active Directory B2C
Content Source: articles/active-directory-b2c/active-directory-b2c-how-to-enable-billing.md
Service: active-directory
Sub-service: b2c
GitHub Login: @mmacy
Microsoft Alias: marsma

@liutang Thank you for your feedback. We will update on this.

Hi @liutang, thanks for your interest in B2C. We recognize that the pricing page is not refreshing for many of our customers. Please accept our apologies for the inconvenience this might have caused, we're working to get it resolved as quickly as we can.
As you've surmised, existing customers are not automatically switched over to the MAU billing meter. If you've linked your Azure AD B2C tenant to an Azure subscription, you're considered an existing customer and will continue to be billed on a per-authentication basis until you decide to switch to the new MAU meter, or until a future deprecation date.
This meter change is the result of careful listening to our customers about their needs regarding predictable, intuitive, and cost-efficient billing for customer identity solutions. Under this new pricing model, you're able to authenticate your first 50,000 MAU for free every month. This means that most customers—with 50,000 or fewer MAUs per month—will be able to use Azure AD B2C for free.
I'll update this issue as soon as the new pricing information is available.
#reassign:mmacy

Hello @liutang, the pricing information for Monthly Active Users (MAU) billing is now available on the Azure AD B2C pricing page. Apologies once again for the delay.
One thing to note, as mentioned on pricing page, is that "Billing and subscription management support is provided at no cost." You can open a support request from the Azure portal in Help + support, and select Billing from the drop-down:

I'll now request that this issue be closed, but feel free to reopen if you feel your questions haven't been answered adequately. #please-close


remove-old-cilium-slo

Before adding a new alerting rule into this repository you should consider creating an SLO rules instead.
SLO helps you both increase the quality of your monitoring and reduce the alert noise.

How to create a SLO rule: https://github.com/giantswarm/sloth-rules#how-to-create-a-slo
Documentation: https://intranet.giantswarm.io/docs/monitoring/slo-alerting/

Towards: https://github.com/giantswarm/...
This PR removes the migrated slos https://github.com/giantswarm/sloth-rules/pull/198
Checklist

[x] Update CHANGELOG.md
[ ] Add Unit tests
[ ] Follow Alert structure
[ ] Consider creating a dashboard (guidelines) (if it does not exist already) to help oncallers monitor the status of the issue.
[ ] Request review from oncall area, as well as team (e.g: oncall-kaas-cloud GitHub group).

https://github.com/giantswarm/giantswarm/issues/31049


Create options model for optional parameters in client methods

collapse optional parameters in client method into an options model
generate options model

The support for FooOptions for aggregated optional parameters in client methods seems to be a general feature. Is it preferable directly adding it to v4 javagen, with an option in JavaSetting to enable/disable it?
@jianghaolu @srnagar Your opinions?

I agree as long as this can be enabled/disabled through options.

@JianpingChen
It is up to you to decide whether to do it in android-v4 branch, or directly in v4 branch with setting in JavaSettings to enable/disable it.
Either way, I would suggest to merge the part in javagen to v4 (in case some change in same file would cause conflict in andoird-v4).

@weidongxu-microsoft cc: @jianghaolu : Given the time we have for android support, it is probably more practical for us to keep it in android-v4 for now and promote to v4 later, after a second thought. Changes we made in android-v4 may lead to more suggestions for v4 and we can review that together once we get Android work done within the timeline we are given. Thanks for the suggestion


Please provide sqlframe.__version__

Use case - SQLFrame support in Narwhals
Other tools provide e.g. pandas.__version__, polars.__version__, and we use it to keep track of the backend version in case of API changes

The version is included in SQLFrame. You can find it in sqlframe/_version.py under the __version__ variable.


How I can upgrade openvpn to latest version?

Depending on your distro, you could configure the official OpenVPN repos and then run the script normally.
But ask yourself if you really need it: usually the distribution's official repositories are perfectly fine.


Update PKGBUILD

Python2 is not needed anymore. Python (e.g. Python3 will suffice)
See issue #501

Does not work. More work needs to be done to update to python3.

Does not work. More work needs to be done to update to python3.


PDF::Reader::ObjectHash.get_page_objects: undefined method `[]' for nil:NilClass

This error is by far the most frequently encountered error during fuzzing.
crashes/20220417055748989526710_crash_497.pdf.trace-1-undefined method `[]' for nil:NilClass
crashes/20220417055748989526710_crash_497.pdf.trace:2:/var/lib/gems/2.7.0/gems/pdf-reader-2.9.2/lib/pdf/reader/object_hash.rb:576:in `get_page_objects'

20220417055748989526710_crash_497.pdf
I have not investigated the root cause. I have no idea how realistic this issue is outside of fuzzing. However, fixing this issue would significantly reduce the fuzzer output. This would speed up fuzzing and save disk space by not having to write the crash file and output to disk.
The surrounding code raises MalformedPDFError but these code paths are frequently missed.
https://github.com/yob/pdf-reader/blob/21d0d21051b6c5ae160cb281e19e4bb23c3f9e56/lib/pdf/reader/object_hash.rb#L570-L588

woah, spooky. This was just converted to a MalformedPDFError by #457

If you can confirm #457 fixes the crash for you in fuzzing, I'll close this issue.

If you can confirm #457 fixes the crash for you in fuzzing, I'll close this issue.

Re-running the fuzzer now. This issue appears to have been resolved.
user@ubuntu:~/Desktop/pdf-reader$ grep get_page_objects crashes/*.trace | wc -l
0

There would usually have been hundreds or thousands of these crashes by now.
user@ubuntu:~/Desktop/pdf-reader$ grep get_page_objects crashes.1/*.trace | wc -l
4140
user@ubuntu:~/Desktop/pdf-reader$ grep get_page_objects crashes.2/*.trace | wc -l
19736


Cant refrence sothree within xml since the last update.

Error:(8) No resource identifier found for attribute 'panelHeight' in package 'com.eugene_horan.app_name'

Never mind. I got it to work with   sothree:umanoPanelHeight="68dp"  I needed to add the umanoPanelHeight


getting started page

On the homepage we had before a link to the guidelines which we will not have for now, maybe it should be a link to getting started page?

On the homepage we had before a link to the guidelines which we will not have for now, maybe it should be a link to getting started page?

Good idea, but the problem is that there's no "overview" page for "Getting started" so not sure to which page it should link.
@DanielleRameau any thoughts on this?

We will change the "guidelines" button in a different story


auto-ma-tate the build

[ ] add a github action to run the build npm run build
[ ] change the output of the build to point to a new folder dist
[ ] add the dist folder to .gitignore
[ ] change the root folder for the site in GitHub Pages settings to dist

Keep the project tidy!

@levithehandyman for another day soon


pull request

I will review this when I have some more time. Thanks for contributing!

Sorry, I merged this request without realizing it was on a different branch, which I deleted.
Please make make the PR again to master.


Code release

The code will be published soon. Subscribe to this issue to be notified when that happens.

thanks for sharing！
All the best.

When will the code be published?

I'm still not authorized to share it yet. It will take a little bit longer. What I can tell you is that the code largely follows the same structure of PolyLaneNet. If you want to know something specific or have further questions, feel free to open a new issue or send me an e-mail.

When will the code be published?

The source code has been published.


Run UndefinedBehaviorSanitizer on CI

As explained in #780, it's be really useful to compile and run our tests with UndefinedBehaviorSanitizer. Unfortunately, our current implementation of filter parser ("filter/" in the root of the repo) triggers a lot of warnings there. Luckily, though, that parser is being rewritten in Rust now (#631), so this issue is going to get unblocked soon.

Actually, sanitizer's warnings can be suppressed on a per-file basis, so we can add it to CI even though our Rust parser is not ready yet.


Fix disabled files in FileDialog using the wrong color

Fixes the wrong color being applied to disabled files in the FileDialog (most notably when using directory mode), rendering their filenames invisible in light mode. I guess at some the name of it got changed (it's in the 3_to_4 migration file) but not in the theme manager.
Before:

After:

Thanks!


Delete unused snippets

Found using http://github.com/gewarren/cleanrepo.

@gewarren Can you remove anything from dotnet-desktop-guide/net/* from this PR? Those are considered clean. There are some "unused" snippets but they're either (1) used to generate the screenshots from the article (2) using moniker folders for v6 vs v5 content and I'm not sure if they'll remain or not, but that's a separate issue.


[communication] Migrate @azure/communication-email to ESM/vitest

Packages impacted by this PR

@azure/communication-email

Issues associated with this PR

https://github.com/Azure/azure-sdk-for-js/issues/31338

Describe the problem that is addressed by this PR
Migrates the @azure/communication-email package to ESM/vitest.
What are the possible designs available to address the problem? If there are more than one possible design, why was the one in this PR chosen?
Are there test cases added in this PR? (If not, why?)
Provide a list of related PRs (if any)
Command used to generate this PR:**(Applicable only to SDK release request PRs)
Checklists

[ ] Added impacted package name to the issue description
[ ] Does this PR needs any fixes in the SDK Generator?** (If so, create an Issue in the Autorest/typescript repository and link it here)
[ ] Added a changelog (if necessary)

API change check
API changes are not detected in this pull request.


how to make that the bots have random names

i want to have bots whit random names

First of all git pull or download the latest version as a zip. Then follow these steps:

Place a file named botnames.txt in src/ai.
Fill the file with the bot names that you want to use (with a new line per name).
Start the server.


New action types

Looks like there a few new action types.  Will have to bring those in.
Reported by @romap0

Please download the following:
Manatee.Trello v2.2.0+
Manatee.Trello.ManateeJson v2.1.0+


MQTT v4 Library Can Fail Malloc Silently and Fails to Flush Received Packet

Describe the bug
Incoming MQTT messages can silently fail to malloc a buffer and then cause an Unknown packet type <xx> received. message if buffer for packet can not be allocated.
The issue of the Unknown Packet is caused by the function IotMqtt_ReceiveCallback calling _getIncomingPacket, but then not handling the IOT_MQTT_NO_MEMORY case. Because IotMqtt_ReceiveCallback does not handle the No Memory case, the receive of the packet is never actually done. This means, when the _networkReceiveTask task calls SOCKETS_Recv again (as it will once the failed allocation and packet read returns), the next byte (which in my case happens to be a 0x00 byte) is received and the system expects it to be a new MQTT packet. What it actually is, is the remainder of the packet that could not be allocated, which causes the MQTT packet type deserializer (_IotMqtt_GetPacketType) to determine that it is bad data.
I've included a snippet of the log. The relevant annotated lines are:

[DEBUG][NET][47305] Successfully received 1 bytes. (First byte from real message received - Byte is a legitimate Packet Type)
[DEBUG][NET][47310] Successfully received 1 bytes. (Second byte - Length byte 0)
[DEBUG][NET][47316] Successfully received 1 bytes. (Third byte - Length byte 1)
Malloc silently fails here, which returns all the way up the call stack to _networkReceiveTask.
_networkReceiveTask calls SOCKETS_Recv to receive the next byte (which is waiting there from the unflushed packet)
[DEBUG][NET][47321] Successfully received 1 bytes. (Fourth byte of original packet - Treated as a new message)
[ERROR][MQTT][47326] (MQTT connection 20033b0c) Unknown packet type 00 received. (_getIncomingPacket attempts to call _IotMqtt_GetPacketType on the received byte and fails because it's an invalid packet type.)

System information

Version of Amazon FreeRTOS: Version 201906.00 Major
Project [Custom Application|MQTT|Shadow]

Expected behavior
The expected behavior would be as follows:

Debug Feedback from the MQTT library (maybe best to be in _getIncomingPacket) that the malloc failed.
IotMqtt_ReceiveCallback or _getIncomingPacket to consume/flush the packet from the socket, so that the next byte that is waiting on the socket connection is not considered to be a new MQTT message.

I think the addition of a DEBUG message when the malloc fails would be an EXCELLENT addition and should be added in other places where the same situation may present. Memory allocation issues are exceptionally hard to track down on a embedded platform without good feedback.
Screenshots or console output
This is a snippet of the DEBUG output from when the issue occurs.
[DEBUG][MQTT][15502] (MQTT connection 20033b0c) Sending PUBACK for received PUBLISH 1.
[DEBUG][MQTT][15510] MQTT PUBACK packet:
40 02 00 01
[DEBUG][MQTT][15516] (MQTT connection 20033b0c) PUBACK for received PUBLISH 1 sent.
[DEBUG][MQTT][15524] (MQTT connection 20033b0c) Reference count changed from 2 to 3.
[DEBUG][Shadow][15532] Verifying client tokens for Shadow UPDATE.
[DEBUG][Shadow][15539] Received Shadow response on topic $aws/things/Cobalt/shadow/update/accepted
[INFO ][Shadow][15548] Shadow UPDATE of Cobalt was ACCEPTED.
[DEBUG][Shadow][15554] Shadow UPDATE for Cobalt has persistent subscriptions. Reference count will not be decremented.
[DEBUG][Shadow][15565] Destroying Shadow operation UPDATE.
[DEBUG][MQTT][15555] (MQTT connection 20033b0c) Reference count changed from 3 to 2.
1563210034808 0002 DEBUG ShadowClient: Successfully performed Device Shadow update.
[DEBUG][NET][47305] Successfully received 1 bytes.
[DEBUG][NET][47310] Successfully received 1 bytes.
[DEBUG][NET][47316] Successfully received 1 bytes.
[DEBUG][NET][47321] Successfully received 1 bytes.
[ERROR][MQTT][47326] (MQTT connection 20033b0c) Unknown packet type 00 received.
[ERROR][MQTT][47333] (MQTT connection 20033b0c) Error processing incoming data. Closing connection.
[DEBUG][MQTT][47342] (MQTT connection 20033b0c) Keep-alive job canceled and cleaned up.
[INFO ][MQTT][47351] (MQTT connection 20033b0c) Network connection closed.
[INFO ][MQTT][47358] (MQTT connection 20033b0c) Disconnecting connection.
[INFO ][MQTT][47364] (MQTT connection 20033b0c) Network connection closed.
[DEBUG][MQTT][47371] (MQTT connection 20033b0c) Reference count changed from 1 to 0.
[DEBUG][MQTT][47379] (MQTT connection 20033b0c) Connection will be destroyed now.
[DEBUG][NET][47358] Network receive task terminating.
[INFO ][MQTT][47393] (MQTT connection 20033b0c) Network connection destroyed.
[DEBUG][MQTT][47400] (MQTT connection 20033b0c) Connection destroyed.
[INFO ][Shadow][47406] Shadow library cleanup done.
[INFO ][Shadow][47411] Shadow library successfully initialized.
1563210066649 0002 DEBUG ShadowClient: Client Disconnect successful.
[INFO ][MQTT][48958] Establishing new MQTT connection.

To reproduce
Steps to reproduce the behavior:

Make an MQTT connection to AWS
Publish message(s) to the shadow with persistent connection. The message that is not able to be allocated for our application comes in on the $aws/things/<thingName>/shadow/update/accepted topic, which is a persistent topic.
Modify the shadow on the AWS platform.
When a large update is posted on the  $aws/things/<thingName>/shadow/update/accepted, the device will receive it (even though in the case where the Cloud has modified the device shadow, the Device doesn't need to know if it was accepted or not)
Device fails to malloc enough space for the incoming data on the subscribed topic and fails silently. (NOTE: In our case, this happens because our static buffer size, as defined by IOT_MESSAGE_BUFFER_SIZE, can not hold the entire message)
MQTT library does not flush the packet after failing to allocate the required space and attempts to receive the rest of the packet as a new packet.

I've included snippets below of the relevant parts of the functions.
If malloc fails, the function is cleaned up and exited.
https://github.com/aws/amazon-freertos/blob/24c0b1c078d60b20f73b24fe64128d814a70fc3e/libraries/c_sdk/standard/mqtt/src/iot_mqtt_network.c#L198-L209
IOT_MQTT_NO_MEMORY not handled at this level.
https://github.com/aws/amazon-freertos/blob/24c0b1c078d60b20f73b24fe64128d814a70fc3e/libraries/c_sdk/standard/mqtt/src/iot_mqtt_network.c#L862-L910

@lt72 Thanks for taking a look at this. 😄

@tombresson  Appreciate for reporting this to us. We agree this is a bug in our MQTT library and it should handle IOT_MQTT_NO_MEMORY case.
We are in discussion of the fix and will post an update once it is ready.

Hi @tombresson,
The merged PR #943 resolves this.  Please give it a try and comment/reopen if you have any questions.


Local editable packages don't have dependency resolution

Pipenv doesn't respect the dependencies of local editable packages.
One such solution is to generate a setup.py file that will configure dynamic dependencies.:
This can solve a few problems at once.

The dependencies of local editable packages can be scanned and added to this pipenv_patch package. This will remove the duplicated dependencies in the Pipfile.

Maybe this pipenv_patch can even parse the Pipfile and get the list of editable packages (no recursion search needed for this. Just get the list from reading the Pipfile since dependencies can't be editable unless they are listed there)
This patch will read the setup.py files, and get the list of dependencies from them, and call them its own.

(optional) We can check an environment variable and dynamically add other dependencies based on that. This is to solve pipenv issue 3167. Since the Pipfileallows you to add other sections that are ignored, you could for example have

[foo-packages]
ipykernel = "*"

And the foo packages are parsed only if an environment variable is set to foo. There could also be a [not-foo-packages] too. This will work well for the tensorflow vs tensorflow-gpu scenario. But this whole optional idea might not pan out either.
@scott-vsi

I may have observed this happening on a local non-editable install of a package too. May just be a local thing. I did not try turning the local package into a wheel and then installing that.


[New Snap] kobosu

Checklist
All items in the list below needs to be satisfied.

[x] Is the Snap repository publicly accessible and linked in this ticket: https://github.com/DoggyFiOfficial/dogecoin-snap-public
[x] Is the Snap distributed on npm and linked in this ticket: https://www.npmjs.com/package/@doggyfi-official/kobosu
[x] Has an audit been performed and the audit report attached or linked in this issue ?
[x] Is a complete list of discovered vulnerabilities from the audit documented in this issue?
[ ] For vulnerabilities that have been deemed necessary to be addressed, are the links to the fixes attached to this issue?
[ ] For vulnerabilities that have been deemed not necessary to be addressed, is a reason for each of them documented in this issue?
[ ] The corresponding pull request in this repo has been merged.

Audit
Auditor : Sayfer
Link : https://sayfer.io/audits/metamask-snap-audit-report-for-doggyfi/
Security Assessment Findings:

Fees Are Not Displayed to the User (ID: SAY-01)

Status: Fixed
Risk: Medium
Issue: Users were not shown the transaction fees upfront in the confirmation prompt, leading to a potential breach of trust.
Mitigation: Fees are now displayed separately in the initial prompt.

Dependencies with Floating Versions (ID: SAY-02)

Status: Fixed
Risk: Low
Issue: Dependencies were not pinned to exact versions, increasing the risk of supply chain attacks.
Mitigation: Use of exact versions for all packages is recommended.

Fee Data Not Displayed on Initial Prompt (ID: SAY-03)

Status: Acknowledged
Risk: Low
Issue: While fees are displayed, they only appear after the initial confirmation, which could lead to a poor UX as users might skip later prompts.
Mitigation: Fees should be presented in the first prompt.

Development Leftovers (ID: SAY-04)

Status: Fixed
Risk: Informational
Issue: There were comments and unfinished features in the code that had been overlooked.
Mitigation: Ensure all known issues are resolved before production.

Team had to make a fix and bumped the version to 0.1.4.
Reason: There was an erroreous line of code in sendDoginal that was never caught making signing a sendDoginal tx impossible. Builder removed line as your team can see here: https://github.com/DoggyFiOfficial/dogecoin-snap-public/commit/f567664732f4600442b9155cdf2539c4649d2598#diff-7bf51f3994b5de19f663e7e8fb6ecbf37bcd0989f855752ad7214c1210570268L1272

Team had to make an other fix discovered after companion website was live, this is in the following two commits

edge case related to wallets with a large number of utxos not paginating our API properly.
additionally, they revised the mintDune / openDune built in functionality to not require the user to know how to shift decimals, and hand decimals properly on mints.

See commits

https://github.com/DoggyFiOfficial/dogecoin-snap-public/commit/49ab4c5ad0ad90aa34fe1a1d545796b7d91802cb
https://github.com/DoggyFiOfficial/dogecoin-snap-public/commit/8d44a8137faa38a365ea3583c6689c684636488a