Feature request: Downloadable png in indexed format matching quantized output, or text output of quantized palette

Love the tool and find it useful. I have a feature request-
It would be very useful if the resulting downloadable image was in indexed palette mode instead of RGB, and for the indexed palette to match the resulting quantized palette (and for each tile to use the correct indexes of that palette). That way it could be used with tools that only operate on indexed palettes and which don't have their own quantization step. (Edit: looks like canvas may only operate in RGBA mode, so maybe this output wouldn't be easy to generate.)
Alternatively, and probably easier: Provide version of the resulting palette in a text based RGB format (maybe either numeric or classic html hex style #RRGGBB) which could be used in a simple remapping step.

When you click on the output image, it will now be saved as an indexed bmp.

Thank you!


fix(hosted): removed debug printfs

Some debug printfs leaked into my last commit.  This commit removes them.

@BetsyRT r+

:pushpin: Commit 6a4b1a1 has been approved by jappavoo

:hourglass: Testing commit 6a4b1a1 with merge c5a56c0...

:sunny: Test successful - runtests
Approved by: jappavoo
Pushing c5a56c05cfa97ddfc370239c38e9c03bc21fda0e to master...


⚠ Bofrost.es has degraded performance

In 4182ce7, Bofrost.es (https://www.bofrost.es) experienced degraded performance:

HTTP code: 200
Response time: 1653 ms

Resolved: Bofrost.es performance has improved in 8ba3150 after 1 hour, 14 minutes.


Introduce CompilationOptions to the Project API

This PR introduces a new API element called CompilationOptions to the project API.
Please note that I have removed the previous BuildOptions API. IMO, CompilationOptions is the correct term. Also, I have engaged CompilationOptions with a package and not with a project.
Check List

[x] Read the Contributing Guide
[ ] Updated Change Log
[ ] Checked Tooling Support (#)
[ ] Added necessary tests

[ ] Unit Tests
[ ] Spec Conformance Tests
[ ] Integration Tests
[ ] Ballerina By Example Tests

[ ] Increased Test Coverage
[ ] Added necessary documentation

[ ] API documentation
[ ] Module documentation in Module.md files
[ ] Ballerina By Examples

@sameerajayasoma , there are conflicts. Please fix and update the PR.

Closing since it's resolved by #27078


x/tools/godoc: memory leak with default options

Please answer these questions before submitting your issue. Thanks!
What did you do?
Compile and run godoc as godoc -http=:6060.
What did you expect to see?
I expected the program to use a reasonable amount of memory; on my machine it gets to about 200 MB and then remains constant.
What did you see instead?
The program's memory consumption grew in an unbounded way; up to 30 GB RAM before I killed it. In addition, a number of error output lines (thousands) were streamed to the console:
$ godoc -http=:6060
2017/07/17 22:51:20 ignoring symlink: stat /Users/kevin/src/chromium.googlesource.com/infra/infra/appengine_module/gae_event_mon/checkouts.py: no such file or directory
2017/07/17 22:51:20 ignoring symlink: stat /Users/kevin/src/chromium.googlesource.com/infra/infra/appengine_module/gae_event_mon/config.py: no such file or directory
2017/07/17 22:51:20 ignoring symlink: stat /Users/kevin/src/chromium.googlesource.com/infra/infra/appengine_module/gae_event_mon/httplib2_utils.py: no such file or direct

Does this issue reproduce with the latest release (go1.8.3)?
Yes
System details
go version devel +e9b9dfe3f7 Tue Jul 18 04:42:09 2017 +0000 darwin/amd64
GOARCH="amd64"
GOBIN=""
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOOS="darwin"
GOPATH="/Users/kevin"
GORACE=""
GOROOT="/Users/kevin/go"
GOTOOLDIR="/Users/kevin/go/pkg/tool/darwin_amd64"
GCCGO="gccgo"
CC="clang"
GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/sf/fsn3_vgd0n98r0jb86bgp83r0000gn/T/go-build558191022=/tmp/go-build -gno-record-gcc-switches -fno-common"
CXX="clang++"
CGO_ENABLED="1"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOROOT/bin/go version: go version devel +e9b9dfe3f7 Tue Jul 18 04:42:09 2017 +0000 darwin/amd64
GOROOT/bin/go tool compile -V: compile version devel +e9b9dfe3f7 Tue Jul 18 04:42:09 2017 +0000
uname -v: Darwin Kernel Version 16.6.0: Fri Apr 14 16:21:16 PDT 2017; root:xnu-3789.60.24~6/RELEASE_X86_64
ProductName:	Mac OS X
ProductVersion:	10.12.5
BuildVersion:	16F73
lldb --version: lldb-370.0.42
  Swift-3.1

I've bisected the commits in x/tools and https://go-review.googlesource.com/c/45096/ is the first one where the program's memory begins growing.

Reading over that CL I don't see anything obvious causing the problem... maybe ReadDir is calling itself in a loop?
So I think the next step may be to back it out, or run the program with -benchmem on and see where the allocations are occurring.

Is there a symlink loop anywhere?

What does
GODEBUG=gctrace=1 ./myAppReproducer
say. This will tell us if it is growth in the Go heap or growth somewhere
else.
On Tue, Jul 18, 2017 at 2:12 AM, Daniel Martí<EMAIL_ADDRESS>wrote:

Is there a symlink loop anywhere?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/golang/go/issues/21061#issuecomment-315991109, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AA7Wn8sa93HFBwAUCcjFHPWYJVJcAIl3ks5sPGjRgaJpZM4Oa4Nb
.

https://gist.github.com/kevinburke/d1e3c65ecbb486862669f6889a939598

I think there's a symlink loop somewhere because if I do this:
diff --git a/godoc/corpus.go b/godoc/corpus.go
index f2c7ebbf..61408745 100644
--- a/godoc/corpus.go
+++ b/godoc/corpus.go
@@ -147,7 +147,7 @@ func (c *Corpus) Init() error {
 }

 func (c *Corpus) initFSTree() error {
-	dir := c.newDirectory(pathpkg.Join("/", c.testDir), -1)
+	dir := c.newDirectory(pathpkg.Join("/", c.testDir), 30)
 	if dir == nil {
 		return errors.New("godoc: corpus fstree is nil")
 	}

The memory usage settles at ~500 MB.
That said, is a symlink loop that uncommon, and can we have godoc error (instead of growing RAM use infinitely) if it finds one?

Did https://go-review.googlesource.com/c/45096/ help or hurt?

Oh, interesting, these are pretty common Go libraries, I think.
gfind: File system loop detected; ‘./src/github.com/coreos/etcd/cmd/etcd’ is part of the same file system loop as ‘./src/github.com/coreos/etcd’.
gfind: File system loop detected; ‘./src/github.com/coreos/etcd/cmd/vendor/github.com/coreos/etcd’ is part of the same file system loop as ‘./src/github.com/coreos/etcd’.
gfind: File system loop detected; ‘./src/github.com/jteeuwen/go-bindata/testdata/symlinkRecursiveParent/symlinkTarget’ is part of the same file system loop as ‘./src/github.com/jteeuwen/go-bindata/testdata/symlinkRecursiveParent’.
gfind: File system loop detected; ‘./src/github.com/kubernetes/kops/vendor/github.com/jteeuwen/go-bindata/testdata/symlinkRecursiveParent/symlinkTarget’ is part of the same file system loop as ‘./src/github.com/kubernetes/kops/vendor/github.com/jteeuwen/go-bindata/testdata/symlinkRecursiveParent’.

That change hurt. Running godoc on the commit immediately before it, memory settles at 200MB. Recompiling with that change and it grows exponentially.

I can take a go at fixing this... does anyone have any ideas about a solution? The dumb one would be to create a map of symlinks, e.g. map[existing]new. Any time we come across a new symlink, if the file it points to is in the "existing" map, we have a loop, and should stop following those links, and/or panic. I don't think we should panic because there are legitimate reasons to have symlink loops in your file tree, see above.
Another (much easier to implement) solution would be to cap godoc directory recursion at, say, a depth of 20 or 30.

How can I repro?
For any given directory, we should only read it once, regardless of the path we got to it. Subsequent reads can just return empty results probably.

It should be enough to clone the most recent version of go-bindata into your GOPATH, then recompile godoc with the tip of x/tools master, and restart it. go-bindata contains a recursive symlink in the testdata directory.
gfind: File system loop detected; ‘./src/github.com/jteeuwen/go-bindata/testdata/symlinkRecursiveParent/symlinkTarget’ is part of the same file system loop as ‘./src/github.com/jteeuwen/go-bindata/testdata/symlinkRecursiveParent’.

I think this may be a dup of #17344. There are memprofiles too, there.

I've been running godoc locally for about a year now, I've had go-bindata
(and the other symlink loops) locally for over a year and I only saw it eat
all of my RAM in the last week or so. I can also make the problem go away
by reverting the CL mentioned above and reinstalling so I think this is a
recent issue.
On Wed, Jul 19, 2017 at 14:03 Alberto Donizetti<EMAIL_ADDRESS>wrote:

I think this may be a dup of #17344
https://github.com/golang/go/issues/17344. There are memprofiles too,
there.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/golang/go/issues/21061#issuecomment-316516268, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAOSI65x2vTccRjIFD68W408-HsnIAEWks5sPm8CgaJpZM4Oa4Nb
.

--
--
Kevin Burke
925.271.7005 | kev.inburke.com

@kevinburke ah, sorry for the noise. I overlooked the fact that the commit you bisected this to was very recent.

I can't reproduce.
I go got go-bindata and ran godoc before & after.
I see no change in memory. Definitely nothing growing "exponentially".
What am I doing wrong?

Okay, I removed the symlinks as well as chromium.googlesource.com/infra and now godoc settles at 300MB of memory usage - previously it settled at about 17. Still trying to repro the "exponential growth" section, though maybe it was just that with my old repo Godoc would prevously "settle" at, say, 10GB and I never actually got to that point.

I can reproduce with an otherwise empty $GOPATH. Instead of go-bindata, try etcd.
According to their docs, you can get it either vendored or not. I can reproduce with both.

go get github.com/coreos/etcd/cmd/etcd (vendored)
go get github.com/coreos/etcd (not vendored)

Confirmed to be caused by CL 45096. Prior to commit, memory use is <30MB. After commit, memory grows to >15GB. I quit because I was about to start rapidly swapping to my fragile SSD. Memory growth appears to be arithmetic and unbounded. Web server doesn't start because it is continually scanning. In verbose mode, no info or errors are generated.
I think go-bindata doesn't cause the issue because it only has one recursive symlink.
etcd has two recursive symlinks:

$GOPATH/src/github.com/coreos/etcd/cmd/etcd -> ../
$GOPATH/src/github.com/coreos/etcd/cmd/vendor/github.com/coreos/etcd -> ../../../../

If I remove the cmd/etcd symlink, memory use is ~130MB and stable. I get 28 errors of the following form:

2017/08/07 15:47:51 newDirTree reading /src/github.com/coreos/etcd/cmd/vendor/github.com/coreos/etcd/cmd/vendor/github.com/coreos/etcd/cmd/vendor/github.com/coreos/etcd/cmd/vendor/github.com/coreos/etcd/cmd/vendor/github.com/coreos/etcd/cmd/vendor/github.com/coreos/etcd/cmd/vendor/github.com/coreos/etcd/cmd/vendor/github.com/coreos/etcd/cmd/vendor/github.com/coreos/etcd/cmd/vendor/github.com/coreos/etcd/cmd/vendor/github.com/coreos/etcd/cmd/vendor/github.com/coreos/etcd/cmd/vendor/github.com/coreos/etcd/cmd/vendor/github.com/coreos/etcd/cmd/vendor/github.com/coreos/etcd/cmd/vendor/github.com/coreos/etcd/cmd/vendor/github.com/coreos/etcd/cmd/vendor/github.com/coreos/etcd/cmd/vendor/github.com/coreos/etcd/cmd/vendor/github.com/coreos/etcd/cmd/vendor/github.com/coreos/etcd/cmd/vendor/github.com/coreos/etcd/cmd/vendor/github.com/coreos/etcd/cmd/vendor/github.com/coreos/etcd/cmd/vendor/github.com/coreos/etcd/cmd/vendor/github.com/coreos/etcd/cmd/vendor/github.com/coreos/etcd/cmd/tools/functional-tester/etcd-tester: open /usr/local/opt/go/libexec/src/github.com/coreos/etcd/cmd/vendor/github.com/coreos/etcd/cmd/vendor/github.com/coreos/etcd/cmd/vendor/github.com/coreos/etcd/cmd/vendor/github.com/coreos/etcd/cmd/vendor/github.com/coreos/etcd/cmd/vendor/github.com/coreos/etcd/cmd/vendor/github.com/coreos/etcd/cmd/vendor/github.com/coreos/etcd/cmd/vendor/github.com/coreos/etcd/cmd/vendor/github.com/coreos/etcd/cmd/vendor/github.com/coreos/etcd/cmd/vendor/github.com/coreos/etcd/cmd/vendor/github.com/coreos/etcd/cmd/vendor/github.com/coreos/etcd/cmd/vendor/github.com/coreos/etcd/cmd/vendor/github.com/coreos/etcd/cmd/vendor/github.com/coreos/etcd/cmd/vendor/github.com/coreos/etcd/cmd/vendor/github.com/coreos/etcd/cmd/vendor/github.com/coreos/etcd/cmd/vendor/github.com/coreos/etcd/cmd/vendor/github.com/coreos/etcd/cmd/vendor/github.com/coreos/etcd/cmd/vendor/github.com/coreos/etcd/cmd/vendor/github.com/coreos/etcd/cmd/vendor/github.com/coreos/etcd/cmd/vendor/github.com/coreos/etcd/cmd/tools/functional-tester/etcd-tester: no such file or directory

If I remove the cmd/vendor/github.com/coreos/etcd symlink, memory use is ~80MB and stable. I get 4 errors of the following form:

2017/08/07 15:59:19 ignoring symlink: stat $GOPATH/src/github.com/coreos/etcd/cmd/etcd/cmd/etcd/cmd/etcd/cmd/etcd/cmd/etcd/cmd/etcd/cmd/etcd/cmd/etcd/cmd/etcd/cmd/etcd/cmd/etcd/cmd/etcd/cmd/etcd/cmd/etcd/cmd/etcd/cmd/etcd/cmd/etcd/cmd/etcd/cmd/etcd/cmd/etcd/cmd/etcd/cmd/etcd/cmd/etcd/cmd/etcd/cmd/etcd/cmd/etcd/cmd/etcd/cmd/etcd/cmd/etcd/cmd/etcd/cmd/etcd/cmd/etcd/cmd/etcd: too many levels of symbolic links

etcd is the only package in my 1.5GB $GOPATH/src that exhibits this behavior. I have not searched for others.

@broady, @ianlancetaylor, you probably want to revert https://go-review.googlesource.com/c/45096 for Go 1.9.

Reopening to port over to 1.9 release branch.

I can confirm this as well to be caused by symlinks.
Memory:
15669 cstockt+  20   0 11.587g 8.686g   1320 D 155.1 55.8   7:24.76 godoc
15694 cstockt+  20   0 9637792 6.002g   1440 S  79.5 38.6   5:45.18 godoc

Strace on either pid shows:
[pid 15850] lstat("/ws/go/src/github.com/coreos/etcd/cmd/etcd/cmd/etcd/cmd/etcd/cmd/vendor/github.com/coreos/etcd/cmd/etcd/cmd/etcd/cmd/vendor/github.com/coreos/etcd/cmd/etcd/cmd/vendor/github.com/coreos/etcd/cmd/vendor/github.com/coreos/etcd/cmd/etcd/cmd/etcd/cmd/etcd/pkg/transport",  <unfinished ...>
[pid 15838] lstat("/ws/go/src/github.com/coreos/etcd/cmd/etcd/cmd/etcd/cmd/etcd/cmd/vendor/github.com/coreos/etcd/cmd/etcd/cmd/etcd/cmd/vendor/github.com/coreos/etcd/cmd/etcd/cmd/vendor/github.com/coreos/etcd/cmd/vendor/github.com/coreos/etcd/cmd/etcd/cmd/etcd/cmd/etcd/Documentation/v2/faq.md",  <unfinished ...>
[pid 15715] lstat("/ws/go/src/github.com/coreos/etcd/cmd/etcd/cmd/etcd/cmd/etcd/cmd/vendor/github.com/coreos/etcd/cmd/etcd/cmd/etcd/cmd/vendor/github.com/coreos/etcd/cmd/etcd/cmd/vendor/github.com/coreos/etcd/cmd/etcd/cmd/vendor/github.com/coreos/etcd/cmd/etcd/cmd/etcd/Documentation/v2/other_apis.md",  <unfinished ...>
[pid 15879] lstat("/ws/go/src/github.com/coreos/etcd/cmd/etcd/cmd/etcd/cmd/etcd/cmd/vendor/github.com/coreos/etcd/cmd/etcd/cmd/etcd/cmd/vendor/github.com/coreos/etcd/cmd/etcd/cmd/vendor/github.com/coreos/etcd/cmd/vendor/github.com/coreos/etcd/cmd/etcd/cmd/etcd/cmd/etcd/mvcc/metrics_txn.go",  <unfinished ...>

It looks like @cbro cherry-picked the "don't follow symlinks" fix into the x/tools release-branch.go1.9 an hour before tagging go1.9 in the main repo. I assume that means this is fixed in Go 1.9 and we just forgot to close the issue?
Can someone check and see if the blowup still exists? If so we need to figure out why - either we used a stale release-branch from x/tools or we didn't fix the bug.

I did this ($HOME/go1.9 is an unpacked go1.9.1 binary distribution, to make sure I'm using the godoc as built in the distribution).
r$ mkdir /tmp/gp
r$ export GOPATH=/tmp/gp
r$ go get -d github.com/coreos/etcd/cmd/etcd
r$ ls -l $GOPATH/src/github.com/coreos/etcd/cmd/etcd
lrwxr-xr-x  1 rsc  wheel  3 Oct 14 22:22 /tmp/gp/src/github.com/coreos/etcd/cmd/etcd -> ../
r$ ls -l $GOPATH/src/github.com/coreos/etcd/cmd/vendor/github.com/coreos/etcd
lrwxr-xr-x  1 rsc  wheel  12 Oct 14 22:22 /tmp/gp/src/github.com/coreos/etcd/cmd/vendor/github.com/coreos/etcd -> ../../../../
r$ export GOROOT=$HOME/go1.9
r$ $GOROOT/bin/godoc -http=localhost:6060 -v

And then I visited http://localhost:6060/pkg/github.com/coreos/etcd/ and it does not show an infinite tree as described above. So I am going to conclude that godoc is fixed as of Go 1.9.1. It was probably also fixed as of Go 1.9, and the fact that the fix was in a subrepo just meant that this issue never got closed.
Closing now.


#84 Feature/add sign to bankid api

Have not added complete simulation but I think this should be enough to start of with for #84.

Hi,
Looks like you've done a massive job on this PR. Thanks so much for that!
I haven't had time to get into the code yet unfortunately. Can you give us a short description on how the usage of this code is gonna look?
Any specifik setup during startup? And how is the actual signing calls looking?

Even if it looks massive it's quite simple. Just added support for calls to /sign. The workflow is identical to /auth except the following:

two additional parameters. One visible to the user during the signing phase and one optional non visible. The guideline recommendation is to use a hash when signing a file to accomodate all file sizes. But could be an text extract to the complete model as json during signing or anything covering your needs.
when the signing process is done collect the signing result with CompletionData.GetSignatureXml()
It contains everything you need to prove the signing took place with the parameters used and by whom.

I only use the client-part. Something which would be nice is some of the HttpClient setup parts where moved to the client-library instead. Now I've manually initialized the HttpClient.
We store our certificates in the windows certificate store so that's a nice alternative to the disk based, if you don't use azure. But that's a separate PR/issue.

First off. Thanks for the repo to start off with.

Thank you, I like how we can collaborate on things like these :) Out of interest, can you disclose what project you are using it for?

I only use the client-part. Something which would be nice is if some of the HttpClient setup parts where moved to the client-libraries instead, through shared.

Yes, we haven't thought to much on how to make it optimal for standalone use. In the ASP.NET scenario it is recommended to leave the lifetime handling of HttpClient to the ASP.NET DI-system, and therefore that is what is needed in the constructor. For standalone usage, there might be overloads that could make things easier. Please have input in an Issue if you have any ideas :)

We store our certificates in the windows certificate store so that's a nice alternative to the disk based, if you don't use azure. But that's a separate PR/issue if you are interested.

Yeah, a PR on that would be great!

First off. Thanks for the repo to start off with.

Thank you, I like how we can collaborate on things like these :) Out of interest, can you disclose what project you are using it for?

Yeah that's great! Was suprised the v4 endpoint was "already" stamped with end of life, but it's a rest world...
Not sure what the client thinks so I'll leave it to them. But basically, we've lifted the now soon deprecated v4-endpoint to v5 for their sign in (which we added on top of their password based "my pages"). Now we’re prototyping generation of dynamic agreements (pdfs) which is then signed by all parties involved. We investigated in existing services for this but decided a self-hosted solution would be best for the prototype, based on the requirements.

I only use the client-part. Something which would be nice is if some of the HttpClient setup parts where moved to the client-libraries instead, through shared.

Yes, we haven't thought to much on how to make it optimal for standalone use. In the ASP.NET scenario it is recommended to leave the lifetime handling of HttpClient to the ASP.NET DI-system, and therefore that is what is needed in the constructor. For standalone usage, there might be overloads that could make things easier. Please have input in an Issue if you have any ideas :)

Mostly thought that some of the BankIdAuthenticationBuilder configuration could be decoupled from AuthenticationBuilder/AspNetCore, and moved to the API-library, for standalone use. But not an issue since we need to configure it manually either way (window store) with our container.

We store our certificates in the windows certificate store so that's a nice alternative to the disk based, if you don't use azure. But that's a separate PR/issue if you are interested.

Yeah, a PR on that would be great!

I'll have that in mind then! Not sure yet if we can use the rest of the libraries or not based on other factors.

Fantastic @ellinge! I'm happy to merge this now :) Thank you so much for your contribution. I'll see if I can get a 1.1.0-alpha1 out on nuget any day now so you can start using that instead of your own.

This is awesome! Great job!

Short status update. We are finishing up a few other things and are planning on releasing this feature that you implemented in an upcoming 2.0.0 release. It will first be released with a beta1 suffix so you can try it out before going live.
@ellinge: We would like to send you a small gift to say thank you for this valuable contribution (the first major external PR merged into Active Login!). Feel free to drop me an email (found in profile) with your details and I'll arrange it :)


143 issue solved

#143 issue solved . please verify my PR and let me know if any changes are required

Thank you @pranee17 for your valuable contribution! We appreciate your help in making this project better. To ensure a smooth and efficient contribution process, please take a moment to review the contribution.md file and follow the provided instructions.


fix(metrics): track actual app endpoints

There was an issue in the configuration of the prometheus middleware. It would only measure the middleware itself.
This fix actually configures it to measure the express app and expose /metrics on different port

looks like we shouldn't need to create a dedicated express app for the metrics, https://fly.io/blog/hooking-up-fly-metrics/#:~:text=Node.js%3F No problem%3A

looks like we shouldn't need to create a dedicated express app for the metrics, https://fly.io/blog/hooking-up-fly-metrics/#:~:text=Node.js%3F No problem%3A

Well it could be used with the same express app, but that would expose the metrics endpoint publicly. I don't think that's a good idea from security perspective, it could leak some information


paste issue on search input

When pasting a plot number, If the cursor is at the end of the input box, it just appends the pasted number to the current one.
When pasting a plot number It should just replace the input with the first 4 chars of the pasted value.
ie.
value in Search Box is: 0000 and cursor position at 4th char.
pasting 1234 should replace input with 1234, no regards where cursors position is located.

It has fixed.
https://app-6eujxk2oo-citydao.vercel.app/

Fixed here 84a3e14178689031e3d3f001526df4c23422e205 Thank you!


mobile: Fix HTTPRequestUsingProxyTest.swift

This PR make the tests HTTPRequestUsingProxyTest.swift hermetic since it's causing 403 issues when hitting external URLs, for example:

https://github.com/envoyproxy/envoy/actions/runs/11671611154/job/32500065249
https://github.com/envoyproxy/envoy/actions/runs/11670461951/job/32494723883

Risk Level: low (tests only)
Testing: unit test
Docs Changes: n/a
Release Notes: n/a
Platform Specific Features: n/a

/assign @abeyad


Convert pictures to text

For a11y purposes, all text images with no charts will be converted to text and styled with css.
Image examples:

First image:

Frustrated by the lack of testing resulting from the problem with the CDC-developed kit, the Seattle Flu Study began using an in-house developed test to look for Covid-19 in samples from people who had tested negative for flu. That work —permissible because it was research— uncovered the Snohomish County teenager.

Second image:

What’s your risk of inadvertently allowing the death of someone in your community from COVID-19?

A local school district shifting to online learning will save 10 lives every week.
A 100,000 person conference canceled saves 200 lives.
If you and 20 coworkers work from home for 4 days, that action on average will save one life over the next two months.
Staying home when sick with #COVID19 prevents you from transmitting to 2-3 other people and causing 100 others to get it, of whom 15-20 are likely to be hospitalized and 1 is likely to die.

by @ScottLeibrand and @DanaMLewis, see http://bit.ly/COVID19communityimpact

I would think that to be able to translate this we need them in text only, and style them with css
@nditada @jkicillof do you agree?

I can do this later today... should my PR replace the images on the English homepage only? And then someone will latter add the translations to the other languages? I’m still figuring out how issues like these fit into the translation workflow. @nditada

addressed in part in #125

@nditada correct. YOu only worry about the english version, then new translation keys go to Lokalise and translation teams translate the new content


Doesn't work on Xiaomi S2. But should!

Hello!
Please help. We have lots of downloads but on many android devices Viro is not working.
One of them is Xiaomi S2 to which I have access right now.
I've checked other apps with this device - AR is working in them.
https://docs.viromedia.com/docs/isarsupportedondevice
Returns that AR is not supported.
Environment
Please provide the following information about your environment:

Development OS: Mac
Device OS & Version: Android 8.1.0
Version: ViroReact 2.11.0 and React Native 0.57.2
Device(s): Xiaomi S2

![img_0915](https://user-images.githubusercontent.com/11584712/47583902-6edf8e80-d961-11e8-8880-621cfd36532c.JPG)
![img_0916](https://user-images.githubusercontent.com/11584712/47583903-6edf8e80-d961-11e8-8684-4feb7bcb4251.JPG)
![img_0917](https://user-images.githubusercontent.com/11584712/47583904-6f782500-d961-11e8-8c29-7f04fce59692.JPG)

Hi @kesha-antonov,
One thing you might want to try (which you did in a previous issue), is to check the method checkIsARSupported() multiple times perhaps more than twice.
We suspect the reason could be the device is returning 'unknown' which we currently translate to 'not supported'. In a future release we plan to make this call async which will lead to more accurate results.
Another way, although def not ideal is to use react-native-device-info and check the device model against the arcore supported device list.
We'll dig into this more and fix the issue in a future release. When we do, we'll update you here.

@VikAdvani Hi!
Do you use this code ?
android: https://developers.google.com/ar/develop/java/enable-arcore#runtime
ios: https://developer.apple.com/documentation/arkit/arconfiguration/2923553-issupported
Yes, about Xiaomi S2 I think you're right.
But now I've received 1 star review about iPhone SE.

@VikAdvani
And what's the reason not to open source repo?
I think we could speed up development with the help of community

Hi @kesha-antonov ,
We just released ViroReact v2.12.0 where we updated our isARSupportedOnDevice() function to return a reason in `notSupportedCallback(). Updated docs here -> https://docs.viromedia.com/docs/isarsupportedondevice

Thanks! @manbod


Made HTTPS detection a bit better.

Introduced a new private method isHttps that checks if the request was sent over HTTPS or not.
To do so, it checks if one of the following is true:

URI scheme is 'https',
a 'X-Forwarded-Proto' header is present and its value is 'https' (useful when running behind a load balancer).

Please merge. This is crucial for our env; otherwise we will have to deploy all our code with secure->false.

@alokdhir technically there is almost no difference. The deployment is still unsecure if it trusts an user settable X-Forwarded-Proto header. Request itself still is not https.
@Frzk Sorry did not notice this earlier. Trusting headers should not be enabled by default. There was a similar PR for slim-basic-auth. Configuration should be similar to this, ie adding headersto the relaxed setting.
$app->add(new Tuupola\Middleware\JwtAuthentication([
    "path" => "/admin",
    "secure" => true,
    "relaxed" => ["localhost", "headers"],
]));

@tuupola : I guess it makes sense :-)
Maybe we could figure out a better way to handle these edge cases with support for X-Forwarded-* headers, but also for RFC 7239 (Forwarded header) in a dedicated option ?
I was thinking about something like:
$app->add(new Tuupola\Middleware\JwtAuthentication([
    "path" => "/admin",
    "secure" => true,
    "trustedProxies" => [
        "proxies": [<IP_ADDRESS>, <IP_ADDRESS>],
        "headers": ["X-Forwarded-Proto", "Forwarded"]
    ],
]));

Has anyone tried this with jwilder/nginx-proxy? Using the secure option doesnt work for me, then again i am forcing https anyway so is there any point in me bothering? Thanks


Handle nested array list structures.

Previously, nested structures like list.0.my_key and list.0.another_key were transformed to:
[
  "list" => [
    ['my_key' => '...'],
    ['another_key' => '...']
  ]
]

After this change, they are transformed to:
[
  "list" => [
    [
      'my_key' => '...'
      'another_key' => '...'
    ]
  ]
]

mega,, danke @kleinmann :)
freut mich


Controller does not get the expected Rx packets after increasing the packet qSize

Hi,
After increasing the packet qSize (issue was reported in https://github.com/cisco-open/go-p4/issues/5), the Rx packets reported is still less than the expected number of the packets.
Here is the code snippet to set the qSize:
client0Stream0 := leader.StreamChannelGet(&streamName)
if client0Stream0 == nil {
t.Logf("'%s' nil stream", streamName)
}
arbCntrs := client0Stream0.GetArbCounters()
t.Logf("stream '%s' Arbitration Counters RxArbCntr(%d) RxArbCntrDrop(%d) RxArbCntrQueued(%d)",
	streamName, arbCntrs.RxArbCntr, arbCntrs.RxArbCntrDrop, arbCntrs.RxArbCntrQueued)

qSize := 5000
client0Stream0.SetArbQSize(qSize)
qSizeRead := client0Stream0.GetArbQSize()
if qSize != qSizeRead {
	t.Logf("Stream '%s' expecting Arbitration qSize(%d) Got (%d)",
		streamName, qSize, qSizeRead)
}
pktCntrs := client0Stream0.GetPacketCounters()
t.Logf("stream '%s' Packet Counters RxPktCntr(%d) RxPktCntrDrop(%d) RxPktCntrQueued(%d)",
	streamName, pktCntrs.RxPktCntr, pktCntrs.RxPktCntrDrop, pktCntrs.RxPktCntrQueued)

client0Stream0.SetPacketQSize(qSize)
qSizeRead = client0Stream0.GetPacketQSize()
t.Logf(" qSizeRead is %d", qSizeRead)

if qSize != qSizeRead {
	t.Logf("Stream '%s' expecting Packet qSize(%d) Got (%d)",
		streamName, qSize, qSizeRead)
}

After the ATE sent more than 1496 packets (GDP and LLDP packets), the packet received reported from the controller is around 331, and no drop packets reported.
This is the snippet of the code to get the RxPktCtr .
// get the packet counters
client0Stream0 := client.StreamChannelGet(&streamName)
pktCntrs := client0Stream0.GetPacketCounters()
t.Logf("stream '%s' Packet Counters RxPktCntr(%d) RxPktCntrDrop(%d) RxPktCntrQueued(%d)",
streamName, pktCntrs.RxPktCntr, pktCntrs.RxPktCntrDrop, pktCntrs.RxPktCntrQueued)
Script run output is shown as below:
// get the packet counters
client0Stream0 := client.StreamChannelGet(&streamName)
pktCntrs := client0Stream0.GetPacketCounters()
t.Logf("stream '%s' Packet Counters RxPktCntr(%d) RxPktCntrDrop(%d) RxPktCntrQueued(%d)",
streamName, pktCntrs.RxPktCntr, pktCntrs.RxPktCntrDrop, pktCntrs.RxPktCntrQueued)
=== RUN   TestPacketIn/PacketIn_to_Primary_Controller
p4rt_61_test.go:317: packets len is 0
p4rt_61_test.go:317: stream 'p4rt' Packet Counters RxPktCntr(329) RxPktCntrDrop(0) RxPktCntrQueued(329)
p4rt_61_test.go:318:  packets len is 331.    <<<<<<<<<<<<<<<<
p4rt_61_test.go:327: Start to decode packet and compare with expected packets.
=== CONT  TestPacketIn
p4rt_61_test.go:390: gdpPacketNo is '221'.  <<<<<<<<<<<<<<
p4rt_61_test.go:391: lldpPacketNo is '110'.   <<<<<<<<<<<<<<<
--- PASS: TestPacketIn (426.50s)
--- PASS: TestPacketIn/PacketIn_to_Primary_Controller (0.01s)
PASS
*** Releasing the testbed...
*** PROPERTY: time.end -><PHONE_NUMBER>
*** PROPERTY: time.begin -><PHONE_NUMBER>
Thanks,
Sharon

@rnhaddad , can you please take a look? the RxPktCntr is always showing less value inspite of increasing the queue size for packets?

Sorry for the delay given the holidays and time off...
I will look into this ASAP.

Looked into the code, and nothing obvious that can pinpoint the issue.
Looking at the snippet above, there is not enough info to troubleshoot the problem. Possible issues i can think of:

Are you closing the stream/connection during the test?
Are you changing mastership/Election-id during the test?
The snippet shows that the queue size is set AFTER collecting the counters. Shouldn't this be the other way around (note that the drop counters show zero, which indicates no drops, but the counters should be read continuously in poll mode; are you doing that?)?
Have you looked into the glog file for any indication of the Go routine exiting prematurely?
Are you sure the server is sending 1496 packets to the client? Perhaps there is drop on the server side such that packets never show up on the client side?

Happy to help troubleshoot, but there is not enough info to conclude here.

Hi, any updates on this front?

Hi @rnhaddad  Thank you for your reply.
Please see my comments for the questions:

Are you closing the stream/connection during the test?
No

Are you changing mastership/Election-id during the test?
No.

The snippet shows that the queue size is set AFTER collecting the counters. Shouldn't this be the other way around (note that the drop counters show zero, which indicates no drops, but the counters should be read continuously in poll mode; are you doing that?)?

The snippet just want to show if the way to set the qSize correct or not, it is not the whole pictures of the code.

Here is the complete code for setting the qSize and read the packets:
   ......
    lldpTrafficFlow := args.lldppacketIO.GetTrafficFlow(args.ate, lldpPacketSize, lldpBitRate)
    gdpTrafficFlow := args.gdppacketIO.GetTrafficFlow(args.ate, gdpPacketSize, gdpBitRate)

    var flows []*ondatra.Flow
    flows = append(flows, gdpTrafficFlow...)
    flows = append(flows, lldpTrafficFlow...)

    client0Stream0 := leader.StreamChannelGet(&streamName)
    if client0Stream0 == nil {
            t.Logf("'%s' nil stream", streamName)
    }

   // Check the init count
    arbCntrs := client0Stream0.GetArbCounters()
    t.Logf("stream '%s' Arbitration Counters RxArbCntr(%d) RxArbCntrDrop(%d) RxArbCntrQueued(%d)",
            streamName, arbCntrs.RxArbCntr, arbCntrs.RxArbCntrDrop, arbCntrs.RxArbCntrQueued)

   // Change qSize
    qSize := 3500
    client0Stream0.SetArbQSize(qSize)
    qSizeRead := client0Stream0.GetArbQSize()
    if qSize != qSizeRead {
            t.Logf("Stream '%s' expecting Arbitration qSize(%d) Got (%d)",
                    streamName, qSize, qSizeRead)
    }
    pktCntrs := client0Stream0.GetPacketCounters()
    t.Logf("stream '%s' Packet Counters RxPktCntr(%d) RxPktCntrDrop(%d) RxPktCntrQueued(%d)",
            streamName, pktCntrs.RxPktCntr, pktCntrs.RxPktCntrDrop, pktCntrs.RxPktCntrQueued)

   // read the qSize
    client0Stream0.SetPacketQSize(qSize)
    qSizeRead = client0Stream0.GetPacketQSize()
    t.Logf(" qSizeRead is %d", qSizeRead)

    if qSize != qSizeRead {
            t.Logf("Stream '%s' expecting Packet qSize(%d) Got (%d)",
                    streamName, qSize, qSizeRead)

  }

   // Sending traffic
    testTraffic(t, args.ate, flows, srcEndPoint, 10)

     // Init the packetno for each protocol
    gdpPacketNo := 0
    lldpPacketNo := 0

    for _, test := range packetInTests {
            t.Run(test.desc, func(t *testing.T) {
                    // Extract packets from PacketIn message sent to p4rt client
                    packets := fetchPackets(ctx, t, test.client, 3500)
                    t.Logf(" packets len is %d", len(packets))

.......
In side fetchPackets Function:
// fetchPackets reads p4rt packets sent to p4rt client.
func fetchPackets(ctx context.Context, t *testing.T, client *p4rt_client.P4RTClient, expectNumber int) []*p4rt_client.P4RTPacketInfo {
t.Helper()
    packets := []*p4rt_client.P4RTPacketInfo{}
    t.Logf("packets len is %d", len(packets))

    // get the packet counters
    client0Stream0 := client.StreamChannelGet(&streamName)
    pktCntrs := client0Stream0.GetPacketCounters()
    t.Logf("stream '%s' Packet Counters RxPktCntr(%d) RxPktCntrDrop(%d) RxPktCntrQueued(%d)",
            streamName, pktCntrs.RxPktCntr, pktCntrs.RxPktCntrDrop, pktCntrs.RxPktCntrQueued).

    for i := 0; i < expectNumber; i++ {
            _, packet, err := client.StreamChannelGetPacket(&streamName, 0)
            if err == io.EOF {
                    t.Logf("EOF error is seen in PacketIn.")

..............
The log printed  below out is from fetchPackets function, not from the code before setting the qSize.
p4rt_61_test.go:317: packets len is 0
p4rt_61_test.go:317: stream 'p4rt' Packet Counters RxPktCntr(329) RxPktCntrDrop(0) RxPktCntrQueued(329)

Have you looked into the glog file for any indication of the Go routine exiting prematurely?
No

Are you sure the server is sending 1496 packets to the client? Perhaps there is drop on the server side such that packets never show up on the client side?

I remember that we checked on the server, the stats showed sending 1496 packets to the client.
Thanks,
Sharon

@sharonshenzhen,
From this:
Packet Counters RxPktCntr(329) RxPktCntrDrop(0) RxPktCntrQueued(329)
We can infer that the total number of times the QueuePacket function and thus the "case *p4_v1.StreamMessageResponse_Packet:" was called is 329.
The code is simple enough here, there are no hidden 'drops', right?
So what happened to the remaining callbacks or packets?!? We can not seem to reproduce this issue, so i am wondering if the server is actually sending these packets and/or flushing the gRPC queue from the server side?
Unfortunately, i don't have enough info to figure this out based on the above, and it is not something that i can reproduce.  Is it reproducible for you? If yes, i can be available to help troubleshoot if that helps...

@rnhaddad
Thank you for your quick response.
Yes, it is reproducible on my setup.
Thanks,
Sharon

How do you want to proceed? I can not seem to reproduce this problem locally (but we might be using different P4RT servers).

hi @rnhaddad , just for confirmation, in your setup are you able to get more than 1000 packets in the client RxPktCntr? In that case we will debug further and get back to you.

Hi @rsindhujha,
Yes, here's a sample output for a queue side of 5000:
Packet Counters RxPktCntr(2800) RxPktCntrDrop(0) RxPktCntrQueued(2800)

Hi @rnhaddad, Thanks for the update.
What is the traffic rate?
thanks,
Sharon

The 2800 packets reported above was at 2pps for 1400 seconds.
However, the pps does not matter, we can test and report based on your traffic rate if you want. What is your traffic rate?

@rnhaddad
I use 200kbps for GDP packets and 100kbps for LLDP packets.  Packet size is 512.

@rnhaddad
We have find the root cause for this issue.
Thank you for your support. Really appreciated.
Best Regards,
Sharon

@sharonshenzhen Awesome! So it is a server issue i guess? Was suspecting that...

@rnhaddad
It is not the server issue.  It is the timing issue in the script. We need to add more delay after sending traffic.


Scope for 23 Jul

[x] [Samoa] Compute fiat value for each wallet while they are inactive #2802
[x] Fix: Polygon native token not showing price #2968
[x] Add native token icons for Optimistic mainnet and testnet #2956

Can we also add this #2808 and also log the events to using this Quickswap button?

Build 398

Forgot to close previously


[WIP] KevaQL

Naive KQL

KQL supports:

CREATE TABLE
DROP TABLE
INSERT
UPDATE
DELETE
SELECT
AND, OR
EQUAL, NOT EQUAL
MIN, MAX
COUNT, AVG, SUM
NULL VALUES
GROUP BY
OFFSET
LIMIT

Still cannot be merged now, the visitor class is cursed


Support [hash] in spriteFilename when extracting (Feature Request)

To handle caching of the sprite, it would be useful to be able to include a [hash] in the filename of the sprite.
What would it take to implement this? How can I assist?

@wanecek it already supported in svg-sprite-loader@beta as [spritehash], e.g:
module.exports = {
  module: {
    rules: [
      {
        test: /\.svg$/,
        loader: 'svg-sprite-loader',
        options: {
          spriteFilename: '[chunkname].[spritehash].svg'
          // or as a part of query param
          // spriteFilename: '[chunkname].svg?[spritehash]'
        }
      }
    ]
  }
}

Please note: in 2.1.0 it will be renamed to [hash]

Closing this as duplicate of #98


⚠ T:Riza Docs has degraded performance

In 33462fc, T:Riza Docs (https://docs.triza.dev) experienced degraded performance:

HTTP code: 200
Response time: 1641 ms

Resolved: T:Riza Docs performance has improved in ca9b337.


When using MySQL Time logs do not show

·
[19:02:42] [Server thread/INFO] [nucleus]: Server ran the command: /pr l                                                                                │············
[19:02:42] [Server thread/INFO]: Prism // Querying records...                                                                                │············
[19:02:42] [Server thread/INFO]: Prism // Defaults used: since:3d                                                                                │············
[19:02:42] [pool-3-thread-2/INFO]: chayde placed saplingGE x11                                                                                │············
[19:02:42] [pool-3-thread-2/INFO]: DrCraftx placed vine x1                                                                                │············
[19:02:42] [pool-3-thread-2/INFO]: Jacob_Side killed entityhorse x2                                                                                │············
[19:02:42] [pool-3-thread-2/INFO]: environment placed dirt x140                                                                                │············
[19:02:42] [pool-3-thread-2/INFO]: environment broke fence x12                                                                                │············
[19:02:42] [pool-3-thread-2/INFO]: Vyraal1 broke leaves x493                                                                                │············
[19:02:42] [pool-3-thread-2/INFO]: environment placed gravel x54                                                                                │············
[19:02:42] [pool-3-thread-2/INFO]: Vyraal1 placed sand x55                                                                                │············
[19:02:42] [pool-3-thread-2/INFO]: Thegeneraldovah broke stone torch x1                                                                                │············
[19:02:42] [pool-3-thread-2/INFO]: Vyraal1 placed blockConduitBundle x1                                                                                │············
[19:02:42] [pool-3-thread-2/INFO]: chayde broke saplingGE x14                                                                                │············
[19:02:42] [pool-3-thread-2/INFO]: environment placed iskallium processed x1                                                                                │············
[19:02:42] [pool-3-thread-2/INFO]: Poignantly broke planks x1                                                                                │············
[19:02:42] [pool-3-thread-2/INFO]: environment placed log x25                                                                                │············
[19:02:42] [pool-3-thread-2/INFO]: Poignantly broke blockAtomicReconstructor x1                                                                                │············
[19:02:42] [pool-3-thread-2/INFO]: environment placed flowing lava x4                                                                                │············
[19:02:42] [pool-3-thread-2/INFO]: environment broke flowing lava x7                                                                                │············
[19:02:42] [pool-3-thread-2/INFO]: Dral5 placed leaves x299                                                                                │············
[19:02:42] [pool-3-thread-2/INFO]: Thegeneraldovah placed stone torch x8                                                                                │············
[19:02:42] [pool-3-thread-2/INFO]: ====================== « 1/5 » =======================

You're showing a grouped query, which can't show timestamps. Try using the -no-group flag to view individual records.

Is there any way to set that as the default

Not currently


Bugifx: Fix saga dose not delete branches when transaction ended. #1887

Ⅰ. Describe what this PR did
Fix saga dose not delete branches when transaction ended.
Optimize: RetryState and CompensateState dose not registry branch to Server now, only the original state instance is registered on the server, and its status should be reported.
Ⅱ. Does this pull request fix one issue?
#1887

Codecov Report

Merging #1893 into develop will decrease coverage by 0.03%.
The diff coverage is 0%.

@@              Coverage Diff              @@
##             develop    #1893      +/-   ##
=============================================
- Coverage       55.3%   55.26%   -0.04%
  Complexity      2388     2388
=============================================
  Files            422      422
  Lines          14300    14314      +14
  Branches        1702     1706       +4
=============================================
+ Hits            7908     7911       +3
- Misses          5678     5690      +12
+ Partials         714      713       -1

Impacted Files
Coverage Δ
Complexity Δ

.../java/io/seata/server/coordinator/DefaultCore.java
40.22% <0%> (-2.2%)
26 <0> (ø)

...server/store/file/FileTransactionStoreManager.java
57.91% <0%> (+0.94%)
29% <0%> (ø)
:arrow_down:


Ability to not apply source maps to stack traces

Feature request
While applying the sourcemaps to stack traces may be useful in development, when you're trying to debug stack traces in production and re-applying the sourcemaps it does not work as they've been rewritten.
We track exceptions with Sentry and upload our application sourcemaps via their release management tool (mainly for server side sourcemaps). However, all the errors that reach the _error page have been rewritten, so we don't get the correct mappings. See below:
Without automatic sourcemaps / Original error (Expected 👍)
Stack traces point to our original bundle file line numbers and columns, sourcemap is then applied and source is shown correctly:

With automatic sourcemaps (Actual 👎)
Stack traces point to files that don't exist. Even though the line numbers map correctly to the original source, we don't have it anymore to find the problem.

Describe the solution you'd like
Could we disable this automatically in production builds (both client and server) or at least have an option to disable it? Or alternatively, apply the sourcemaps just before rendering in the ErrorDebug page, while sending the real error to Error.getInitialProps so we can capture it correctly. Also, when it bubbles to the window, having the real url would point to the file in the dev console source, instead of non-existent/malformed file path that 404s at the moment.
I've seen that the @canary version has rewritten all of this. Are sourcemaps still gonna be applied in the next major version?
Describe alternatives you've considered
Capturing the exception ourselves to get the original stack trace (e.g. wrapping hoisted getInitialProps in _app), but this does not capture all the possible exceptions and is not centralized.
Is there any alternative right now to get the original error?

We no longer rewrite stacktraces on latest canary, we only render rewritten stacktraces in dev with react-error-overlay.

@Utwo @pmjhonwang I simply use the Sentry CLI (https://docs.sentry.io/clients/javascript/sourcemaps/#upload-sourcemaps-with-cli), though there are other ways. Just make sure you're generating sourcemaps on your build (e.g. with withSourcemaps) and you may need to play with the CLI a bit to get the --url-prefix right.

Thanks, I've solved it like this:
sentry-cli releases files ${TAG} upload-sourcemaps --url-prefix=~/_next/static  ./.next/static
sentry-cli releases files ${TAG} upload-sourcemaps \
   --url-prefix=~/_next/\"$(cat ./.next/BUILD_ID)\"/page \
   ./.next/server/bundles/pages"

Ah, now I understand where the problem was. Yeah, I next export everything into a folder (which I deploy to a CDN) and upload everything from there. This also runs from a docker container after deploy, so there's only one version of the app in there. No need to find BUILD_ID, etc.


Test cases may be stored in problems.

dart-lang/sdk: commit tag: 3ee3dac08ef290fce8923258b754ac36782949f6
file: ../sdk/tests/co19/src/LibTest/isolate/Isolate/spawn_A01_t05.dart
iMain(SendPort replyPort) {
  var receivePort = new ReceivePort();

  replyPort.send(receivePort.sendPort);

  receivePort.listen((message) {
    replyPort.send(message-1);
    if(message == 0) {
      receivePort.close(); // !!! The code cannot enter here.
    }
  });
}

message == 1 is ok.
I'm not sure if the imain object will exit properly.

It's not available on GitHub, but the Google Repository does have it.

Add a more important example of a test case that failed.
file : .../sdk/tests/standalone/io/web_socket_test.dart
main() {
  new SecurityConfiguration(secure: true).runTests();
  // TODO(whesse): Make WebSocket.connect() take an optional context: parameter.
  // new SecurityConfiguration(secure: true).runTests();
}

if secure set true, then test case execute fail.
tip:
Handshake error in client
HandshakeException


Incompatible with "Burnt Basic" mod 1.19.2

When you try to chop down a tree it just starts spawning the stripped/chopped blocks around and the tree is never chopped

IVE BEEN REMOVING MODS LIKE A MANIAC IT WAS BURNT THE WHOLE TIME!


release:translate operation does not work in Docker environment

This is likely caused by the lack of any DB solution being applied to the Docker image. Installing and configuring SQLite may be an easy, lightweight way to solve the issue.
ACs

[ ] release:translate command works correctly

I could not reproduce the issue. release:translate worked for me.

Closing as per the above comment