Module scripts fail to load

Describe the bug
A clear and concise description of what the bug is. Please briefly describe how to reproduce the bug as well as expected vs. actual behavior. Optionally include screenshots and server logs, if helpful.
When accessing the dashboard, nothing loads.
Checking the devtools console, I was able to find the following.

Failed to load module script: Expected a JavaScript module script but the server responded with a MIME type of "text/plain". Strict MIME type checking is enforced for module scripts per HTML spec. menu-main.js:1
Failed to load module script: Expected a JavaScript module script but the server responded with a MIME type of "text/plain". Strict MIME type checking is enforced for module scripts per HTML spec.

System information
Please provide information on:

Wakapi version: 2.0.0 RC1
Operating system: Windows 10 Version 20H2 (Build 19042.1415)

Windows 10 20H2

Browser: Google Chrome 96.0.4664.110 (Official Build) (64-bit) (cohort: Stable)
Database: SQLite
Accessing through localhost

I've download the latest release and it seems to be fine.

OS: Windows 21H1 19043.1415
Can you please give context about how you're building/running wakapi?
e.g. Compiled from repo (with/without docker), downloaded release zip etc.

I've download the latest release and it seems to be fine.  OS: Windows 21H1 19043.1415
Can you please give context about how you're building/running wakapi? e.g. Compiled from repo (with/without docker), downloaded release zip etc.

@YC Oh, that's odd. I downloaded the windows version from this release.
I have migrated from an old version (not too old either) to this one and this started happening.
Regarding running wakapi, i'm just running it from the command line. Here's my configuration file just in case.

Regarding running wakapi, i'm just running it from the command line. Here's my configuration file just in case.

Should be fine, that's what I usually do as well.
I remember that I once came across the same error message during development, but can't remember how I got it fixed. The weird thing is that it works on my machine (and @YC's). Do you get the same error when browing to https://wakapi.dev/signup?
I'm not a JS pro, but this might be relevant: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/Modules#aside_—_.mjs_versus_.js. However, I don't see a reason why content type should be wrong, as the module files are named .js like any others. And, again, it works for some people at least.
Could you post a screenshot of your browser tools' network tab, with a focus on the menu-main.js file request?

Regarding running wakapi, i'm just running it from the command line. Here's my configuration file just in case.

Should be fine, that's what I usually do as well.
I remember that I once came across the same error message during development, but can't remember how I got it fixed. The weird thing is that it works on my machine (and @YC's). Do you get the same error when browing to wakapi.dev/signup?
I'm not a JS pro, but this might be relevant: developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/Modules#aside_%E2%80%94_.mjs_versus_.js. However, I don't see a reason why content type should be wrong, as the module files are named .js like any others. And, again, it works for some people at least.
Could you post a screenshot of your browser tools' network tab, with a focus on the menu-main.js file request?

@muety Hello there, thanks for the fast reply!
I have some good and bad news.. The good news is that it's working for me now.
The bad news, is that I have not changed anything in my setup (browser and extensions wise) and all of the sudden it started working.
Regarding the dev tools screenshot, here's what it's showing:

Oddly enough, the js files still are being sent as text/plain.
Maybe my browsers were assuming that the js files were js modules?

I did some more research and found your exact problem here: https://github.com/golang/go/issues/32350. Super interesting discussion there! It actually goes all the way down to your Windows registry. Interestingly, the issue does not occur on my Windows 10 setup, so it looks like some software, that you have installed on your system, once changed that registry entry.
A quick fix is mentioned here: https://github.com/golang/go/issues/32350#issuecomment-700202218. I'd recommend to apply that to your system as a quick fix and in addition wait for the Go team to perhaps come up with a fundamental fix. I think there's not much we can do on Wakapi's side. Let me know if that worked for you!

I tested this as well, works fine if I use Docker Installation (Option 3: Use Docker), but I get the same error if I use "Option 2: Quick-run a Release" on Windows 10.

I did some more research and found your exact problem here: golang/go#32350. Super interesting discussion there! It actually goes all the way down to your Windows registry. Interestingly, the issue does not occur on my Windows 10 setup, so it looks like some software, that you have installed on your system, once changed that registry entry.
A workaround is mentioned here: golang/go#32350 (comment). I'd recommend to apply that to your system as a quick fix and in addition wait for the Go team to perhaps come up with a permament fix. I think there's not much we can do on Wakapi's side. Let me know if that worked for you!
Edit: It's also intersting to see that for me, the content type is application/javascript on Linux and text/javascript on Win.

@muety Awesome discovery! Never would've thought that Microsoft's insanity would break local servers.
The workaround you mentioned solved the issue locally! Still would be good to have the go team
upstream fix it.
@andre-paulo98 I saw your comment and I recommend also running the fix mentioned by muety

I'm glad the fix worked. I'll close this issue as there's nothing more we can do on our side. Susbcribe to changes of the upstream issue to track progress.


Replace cat-pipe with file redirection in coveralls script

The two are functionally identical, but for this use case, file redirection is more idiomatic.

Coverage remained the same at 100.0% when pulling 42573d088895ab2ae33929f9d323245840cdf059 on canterberry:cat-pipe into 6c2c958c8e93f133fd6c7f969c30374ca0430d83 on ethjs:master.


Leak when reading from SSL sockets

Envoy version: v1.9.1
We're seeing an issue where Envoy sometimes leaks tens of gigabytes of memory. I still don't have a great understanding of why this is happening, but here's what we know so far.
Here's the output of pprof on a heap profile: https://gist.github.com/julia-stripe/04cee10b2185d81f1b84ad493920a9b3 which I think is saying that the memory is being allocated on this line.
Some other observations:
Here are some logs from the heap profiler. It looks like the pattern is that it allocates ~8GB of memory, frees some memory, and then does the same thing again. There are a lot of periods where it's allocating about 1GB/s.
tcmalloc doesn't seem to be doing a great job of releasing freed memory back to the OS though: this example of what's reported by the stats endpoint is pretty typical (16MB allocated, 17GB heap).
$ curl localhost:9901/stats | grep memory
server.memory_allocated: 16697176
server.memory_heap_size:<PHONE_NUMBER>0

A few more relevant statistics that make this confusing:

output of curl localhost:9901/stats | grep bytes (less than 100GB of data)
output of curl localhost:9901/stats | grep cx_total (only ~2000 connections)

Thanks for the detailed report. Do you have a heap profile as a flame graph by any chance? I think that could be a useful insight into the call stack at allocation time.
CC @brian-pane (who knows a lot about Envoy's buffer management) and @PiotrSikora (SSL subsystem expert).

Here's a flamegraph.

Assuming allocated drops back down, it's unlikely there is a leak. The issue here is likely that tcmalloc is notoriously bad about releasing memory back to the OS. IIRC there are some options to make it do that, but I've never gotten it to work very well. I think @dnoe might know more about this.
The issue is more likely that there is a huge influx of traffic and Envoy memory/connection count grows very high before dropping down. You might want to look into enabling the overflow manager to prevent this type of unbounded growth on incoming connections: https://www.envoyproxy.io/docs/envoy/latest/configuration/overload_manager/overload_manager.

The thing that's very confusing to me is that there doesn't seem to be a lot of traffic on the boxes suffering from this -- dstat reports at most ~50MB/s of sent/recv'd and there are only ~2000 connections total, but memory is still sometimes growing at 1GB/s.
One hypothesis I have is that -- there are millions of ssl read returns: 1 lines logged (from here) when I turn on trace logging.
This makes me think that for some reason (??) Envoy is reading 1 byte at a time and allocating 16kb every time that happens. So even though not a lot of data is being transferred, Envoy is allocating a 16kb buffer for every byte read, which adds up.

@julia-stripe thanks for the extra info. If you feel like reading some code, take a look at https://github.com/libevent/libevent/blob/1f4f8769c4e78b14e6aa21d8300f432f67def8df/buffer.c#L690 and see how that behaves. From my quick read, we expand the buffer to make sure that we have 16K of space available, so I'm pretty sure that we would have at most 16K (or whatever the slice allocation size is rounded up) of extra space per connection sitting around.

Here's a self-contained reproduction of this issue we put together. If you run run.sh, you should see Envoy quickly allocating something like 20GB of memory. It uses a fairly pathological backend service (main.go). https://gist.github.com/julia-stripe/a9024d845e4b566f7aa06282e232a026
A hypothesis we have is that is that the Go backend is somehow racing Envoy's logic that closes the connection, so that Envoy ends up keeping a connection open that should normally be closed and then keeps reading bytes from that connection and allocating memory.

@julia-stripe Envoy will accept an unbounded amount of connections and allocate an unbounded amount of memory unless you configure the overload manager. It looks like that's what your example is doing?

@mattklein123 I updated main.go to log the number of bytes sent by the misbehaving server. The server reports that it sent 4194305 bytes, but Envoy's statistics say server.memory_allocated:<PHONE_NUMBER>2, and listener.<IP_ADDRESS>_8190.downstream_cx_total: 19088. Is there another source of memory I'm missing here (other than connections / bytes sent by the server) that would explain where the 13GB of memory being allocated is coming from?

@julia-stripe sorry not sure. I would get a heap profile / dump of the Envoy when it has 13GB allocated. You can configure the tcmalloc heap profiler to dump when every 1GB is allocated for example. What I still suspect is happening here is that connections are being created faster than they are being cleaned up, but I'm not completely sure.

What I still suspect is happening here is that connections are being created faster than they are being cleaned up, but I'm not completely sure.

I can reproduce this by making about 15 connections to Envoy which send a total of 4MB, so it's definitely not the number of connections

Is this reproducible with both the original and the new Envoy buffer implementations? (I think the original implementation is still the default, and the new one can be enabled at Envoy startup by adding the command-line parameters --use-libevent-buffers 0).

It's with the original buffer implementation, I haven't tested with the new implementation.

@julia-stripe sorry I did not read your Go code in detail enough, I think I understand the full scenario now. OK, here are some things to investigate if you are willing:

Can you please run your test with master to rule out any fixed issue?
What flow control settings are you using? Are you using HTTP/1 or HTTP/2 between downstream and upstream? Can you look at flow control stats to see if flow control is kicking on?
Per @brian-pane it might be worth it to quickly try with the new buffer implementation, it's possible there is an issue with libevent where we keep reserving more data and not reusing the existing reservations, that would need to be looked into.
Can you confirm that once a connection is opened it stays open? Who is closing the connection?

Could you verify that this is only happening for SSL sockets and not for plaintext?

Thanks!

here are answers to #2, #4, and #5 -- I've been having some trouble getting master compiled but once I figure that out I'll answer #1 and #3.

It's only happening for SSL sockets, I tested the same program / request pattern on plaintext (with many many more requests) and couldn't get Envoy's heap to more than about 5MB.
Some of the connections stay open and some are closed by Envoy. I'm not sure why some connections are closed yet and some aren't (maybe there's a race somewhere?). From observation, I believe that the connections that stay open are the ones that are causing the large increases in memory.
From Envoy's perspective it's just a TCP socket (the example of this we have internally is a CONNECT proxy). per_connection_buffer_limit_bytes just has the default value, I'm not sure what other flow control settings we should be using.

here are the flow control stats:
cluster.service1.upstream_flow_control_backed_up_total: 0
cluster.service1.upstream_flow_control_drained_total: 0
cluster.service1.upstream_flow_control_paused_reading_total: 1
cluster.service1.upstream_flow_control_resumed_reading_total: 0
http.admin.downstream_flow_control_paused_reading_total: 0
http.admin.downstream_flow_control_resumed_reading_total: 0
tcp.ingress_http.downstream_flow_control_paused_reading_total: 0
tcp.ingress_http.downstream_flow_control_resumed_reading_total: 0

@julia-stripe I will poke around a bit more tomorrow. Can you provide your full config or some approximation of it so we are all on the same page in terms of settings, filters, etc.? Thank you.

@mattklein123 I linked to it earlier up -- https://gist.github.com/julia-stripe/a9024d845e4b566f7aa06282e232a026

I think the issue is in this loop: https://github.com/envoyproxy/envoy/blob/master/source/extensions/transport_sockets/tls/ssl_socket.cc#L81-L93. Here's what the code looks like it's doing to me:

Every time Envoy reads more data from SSL_read, it reserves another 16k buffer
It always reads the data from SSL_read into the beginning of the buffer, so even if only 1 byte is read it takes up the whole 16k buffer

I believe there are 2 things contributing to this issue:
a. SslSocket::doRead is assuming that every read from SSL_read will be relatively big, and so it doesn't attempt to put data from more than one read into each 16k slice, it just gives every read its own slice
b. the size of read_buffer isn't being kept in check by any flow control (I can't see any buffer size controls in SslSocket::doRead) so there's nothing preventing read_buffer from growing in size an unlimited amount
some archaelogy makes it look like the SSL buffer handling code in Envoy is inspired by the bufferevent_openssl implementation which looks like it has the same behaviour.
If this is right, I don't believe the new/old buffer implementation would make a difference. It also seems like it should be possible to use this to DoS Envoy as a client, though I haven't been able to get a PoC of that working yet.

I think the issue here is more nuanced. From my read, the plain text code does exactly the same thing. See RawBufferSocket::doRead(Buffer::Instance& buffer) and OwnedImpl::read(Network::IoHandle& io_handle, uint64_t max_length). Also, my understanding of the reserve code is that it does not allocate a fresh 16KiB each time, it just makes sure there is 16KiB space available. If this is not the case it's definitely a bug, but given that the plain text code appears to be the same and you don't see any issue there, it's unclear what is happening.
So either there is a more subtle difference between the two paths, or read disable/flow control is not working for some reason in this path, or some other more subtle reason. Unfortunately I'm not going to have much more time to look at this today but cc @PiotrSikora @lizan who might be able to look a bit more (cc @alyssawilk also who is on vacation).

I did quick test on @julia-stripe's gist on my local box, with envoy commit 3a8128a8189a65c2f156eaea5bcb14ac50166ed9.
I can confirm it goes to:
server.memory_allocated: 4100408
server.memory_heap_size:<PHONE_NUMBER>

very quickly, but in the middle of stats queries I do also see
server.memory_allocated:<PHONE_NUMBER>
server.memory_heap_size:<PHONE_NUMBER>

as well, and it seems allocated memory does spike.

This dos happen for new buffer implementation as well, still exists when I added --use-libevent-buffer 0 to envoy args

I think @julia-stripe https://github.com/envoyproxy/envoy/issues/6617#issuecomment-484901279 is mostly correct, though we don't fully reserve 16k buffer, it reserve almost half of them (since we reserve in two slices), when SSL_read read bytes into a slice, we shrink the slice len_, and it wastes up to 16k memory. Posted #6662 try to fix this.
The part I'm not sure is that SSL_read returns millions of 1 (means it only read 1 bytes) in same event, which is unexpected, any idea why this is the case? @PiotrSikora.

Hmm, I need to look into this more. @lizan AFAICT the raw transport socket does exactly the same thing. Also, the buffer code should not always waste the memory, it should give you 16K across 2 slices, even if that starts 1 byte after the previous read.

Oh, I think I know the difference. The plain text socket is using readv() is being smarter about this. The buffer code must not be doing what I'm talking about, which is to be intelligent about a split reservation, though I'm quite surprised by this. @brian-pane how does the new buffer code handle this? I think @lizan's fix sounds reasonable if the buffer code is not doing what we think it should be doing.

The new buffer code reuses the available space at the end of the previous buffer, if I remember correctly. But with both the old and new buffer implementations, space might end up being wasted if the caller reserves two iovecs and only commits the first of them.

@brian-pane why would it be wasted vs. being used next time? That must be what is happening here. This seems broken for the plain text case also.

The semantics are ill-defined if you reserve 2 iovecs, commit just the first of them, and then do another reservation. The buffer implementation doesn’t know whether the caller might subsequently commit the 2nd iovec from the first reservation, so it might be erring on the side of caution and allocating a new buffer. I’ll check the code when I get home, to find out for sure.

Confirmed: neither the old nor the new buffer implementation reuses the buffer space if you reserve two iovecs and only commit the first of them. Here's a test case that expects reuse and fails for both impls: https://github.com/brian-pane/envoy/commit/49603c9196c350ebc10971e240476dfd00eae177
This test case probably can't be committed in its current form, because it's checking for semantics that aren't actually defined in the buffer API. But it definitely shows that reserving multiple iovecs and not committing them all will yield excessive memory usage. It's not quite a memory leak, because all the memory does get freed when the buffer object is destroyed. But during the lifetime of the buffer object, the memory utilization in a pathological test case can approach 8,000 times the number of bytes actually read from the socket.

@brian-pane ugh thanks a ton for looking into this. WDYT about changing the behavior of the new implementation to allow reuse? IMO that's the way it should work (and thought it work). I think this is actually an issue in the plain text socket as well, but the kernel does a better job of collapsing the small writes into a single larger read.

Sounds good to me. I'll post a PR shortly.

There may be an additional problem. I just remembered that, because of how libevent allocates slices internally, its 16KB slice size will have room for quite a bit more than 16KB. That makes my prior test case invalid.  In commit #6663, I added a new, valid version of the test ... and the old libevent-based buffer implementation passes the test.
That PR is still useful, because it makes the new buffer impl more robust. But I'll need to dig further to figure out the failure mode with the old buffer impl, since it's not one of the scenarios that the PR tests for.

@mattklein123 @brian-pane yeah that's right, here is while I debug this issue to see where the problem is starting:
Format: ssl read returns:  <slice.mem_> <slice.len_(before shrinking>
[2019-04-19 23:02:30.010][29967][trace][connection] [source/extensions/transport_sockets/tls/ssl_socket.cc:87] [C59] ssl reserved slices: 1
[2019-04-19 23:02:30.010][29967][trace][connection] [source/extensions/transport_sockets/tls/ssl_socket.cc:90] [C59] ssl read returns: 1 0x28d1ff1 16399
[2019-04-19 23:02:30.010][29967][trace][connection] [source/extensions/transport_sockets/tls/ssl_socket.cc:87] [C59] ssl reserved slices: 1
[2019-04-19 23:02:30.010][29967][trace][connection] [source/extensions/transport_sockets/tls/ssl_socket.cc:90] [C59] ssl read returns: 1 0x28d1ff2 16398
[2019-04-19 23:02:30.010][29967][trace][connection] [source/extensions/transport_sockets/tls/ssl_socket.cc:87] [C59] ssl reserved slices: 1
[2019-04-19 23:02:30.010][29967][trace][connection] [source/extensions/transport_sockets/tls/ssl_socket.cc:90] [C59] ssl read returns: 1 0x28d1ff3 16397
[2019-04-19 23:02:30.010][29967][trace][connection] [source/extensions/transport_sockets/tls/ssl_socket.cc:87] [C59] ssl reserved slices: 1
[2019-04-19 23:02:30.010][29967][trace][connection] [source/extensions/transport_sockets/tls/ssl_socket.cc:90] [C59] ssl read returns: 1 0x28d1ff4 16396
[2019-04-19 23:02:30.010][29967][trace][connection] [source/extensions/transport_sockets/tls/ssl_socket.cc:87] [C59] ssl reserved slices: 1
[2019-04-19 23:02:30.010][29967][trace][connection] [source/extensions/transport_sockets/tls/ssl_socket.cc:90] [C59] ssl read returns: 1 0x28d1ff5 16395
[2019-04-19 23:02:30.010][29967][trace][connection] [source/extensions/transport_sockets/tls/ssl_socket.cc:87] [C59] ssl reserved slices: 1
[2019-04-19 23:02:30.010][29967][trace][connection] [source/extensions/transport_sockets/tls/ssl_socket.cc:90] [C59] ssl read returns: 1 0x28d1ff6 16394
[2019-04-19 23:02:30.010][29967][trace][connection] [source/extensions/transport_sockets/tls/ssl_socket.cc:87] [C59] ssl reserved slices: 1
[2019-04-19 23:02:30.010][29967][trace][connection] [source/extensions/transport_sockets/tls/ssl_socket.cc:90] [C59] ssl read returns: 1 0x28d1ff7 16393
[2019-04-19 23:02:30.010][29967][trace][connection] [source/extensions/transport_sockets/tls/ssl_socket.cc:87] [C59] ssl reserved slices: 1
[2019-04-19 23:02:30.010][29967][trace][connection] [source/extensions/transport_sockets/tls/ssl_socket.cc:90] [C59] ssl read returns: 1 0x28d1ff8 16392
[2019-04-19 23:02:30.010][29967][trace][connection] [source/extensions/transport_sockets/tls/ssl_socket.cc:87] [C59] ssl reserved slices: 1
[2019-04-19 23:02:30.010][29967][trace][connection] [source/extensions/transport_sockets/tls/ssl_socket.cc:90] [C59] ssl read returns: 1 0x28d1ff9 16391
[2019-04-19 23:02:30.010][29967][trace][connection] [source/extensions/transport_sockets/tls/ssl_socket.cc:87] [C59] ssl reserved slices: 1
[2019-04-19 23:02:30.010][29967][trace][connection] [source/extensions/transport_sockets/tls/ssl_socket.cc:90] [C59] ssl read returns: 1 0x28d1ffa 16390
[2019-04-19 23:02:30.010][29967][trace][connection] [source/extensions/transport_sockets/tls/ssl_socket.cc:87] [C59] ssl reserved slices: 1
[2019-04-19 23:02:30.010][29967][trace][connection] [source/extensions/transport_sockets/tls/ssl_socket.cc:90] [C59] ssl read returns: 1 0x28d1ffb 16389
[2019-04-19 23:02:30.010][29967][trace][connection] [source/extensions/transport_sockets/tls/ssl_socket.cc:87] [C59] ssl reserved slices: 1
[2019-04-19 23:02:30.010][29967][trace][connection] [source/extensions/transport_sockets/tls/ssl_socket.cc:90] [C59] ssl read returns: 1 0x28d1ffc 16388
[2019-04-19 23:02:30.010][29967][trace][connection] [source/extensions/transport_sockets/tls/ssl_socket.cc:87] [C59] ssl reserved slices: 1
[2019-04-19 23:02:30.010][29967][trace][connection] [source/extensions/transport_sockets/tls/ssl_socket.cc:90] [C59] ssl read returns: 1 0x28d1ffd 16387
[2019-04-19 23:02:30.010][29967][trace][connection] [source/extensions/transport_sockets/tls/ssl_socket.cc:87] [C59] ssl reserved slices: 1
[2019-04-19 23:02:30.010][29967][trace][connection] [source/extensions/transport_sockets/tls/ssl_socket.cc:90] [C59] ssl read returns: 1 0x28d1ffe 16386
[2019-04-19 23:02:30.010][29967][trace][connection] [source/extensions/transport_sockets/tls/ssl_socket.cc:87] [C59] ssl reserved slices: 1
[2019-04-19 23:02:30.010][29967][trace][connection] [source/extensions/transport_sockets/tls/ssl_socket.cc:90] [C59] ssl read returns: 1 0x28d1fff 16385
[2019-04-19 23:02:30.010][29967][trace][connection] [source/extensions/transport_sockets/tls/ssl_socket.cc:87] [C59] ssl reserved slices: 1
[2019-04-19 23:02:30.010][29967][trace][connection] [source/extensions/transport_sockets/tls/ssl_socket.cc:90] [C59] ssl read returns: 1 0x28d2000 16384
[2019-04-19 23:02:30.010][29967][trace][connection] [source/extensions/transport_sockets/tls/ssl_socket.cc:87] [C59] ssl reserved slices: 2
[2019-04-19 23:02:30.010][29967][trace][connection] [source/extensions/transport_sockets/tls/ssl_socket.cc:90] [C59] ssl read returns: 1 0x28d2001 16383
[2019-04-19 23:02:30.010][29967][trace][connection] [source/extensions/transport_sockets/tls/ssl_socket.cc:90] [C59] ssl read returns: 1 0x28cc430 976
[2019-04-19 23:02:30.010][29967][trace][connection] [source/extensions/transport_sockets/tls/ssl_socket.cc:87] [C59] ssl reserved slices: 2
[2019-04-19 23:02:30.010][29967][trace][connection] [source/extensions/transport_sockets/tls/ssl_socket.cc:90] [C59] ssl read returns: 1 0x28cc431 975
[2019-04-19 23:02:30.010][29967][trace][connection] [source/extensions/transport_sockets/tls/ssl_socket.cc:90] [C59] ssl read returns: 1 0x28d6030 16336
[2019-04-19 23:02:30.010][29967][trace][connection] [source/extensions/transport_sockets/tls/ssl_socket.cc:87] [C59] ssl reserved slices: 2
[2019-04-19 23:02:30.010][29967][trace][connection] [source/extensions/transport_sockets/tls/ssl_socket.cc:90] [C59] ssl read returns: 1 0x28d6031 16335
[2019-04-19 23:02:30.010][29967][trace][connection] [source/extensions/transport_sockets/tls/ssl_socket.cc:90] [C59] ssl read returns: 1 0x28cc830 976
[2019-04-19 23:02:30.010][29967][trace][connection] [source/extensions/transport_sockets/tls/ssl_socket.cc:87] [C59] ssl reserved slices: 2
[2019-04-19 23:02:30.010][29967][trace][connection] [source/extensions/transport_sockets/tls/ssl_socket.cc:90] [C59] ssl read returns: 1 0x28cc831 975
[2019-04-19 23:02:30.010][29967][trace][connection] [source/extensions/transport_sockets/tls/ssl_socket.cc:90] [C59] ssl read returns: 1 0x28da030 16336
[2019-04-19 23:02:30.010][29967][trace][connection] [source/extensions/transport_sockets/tls/ssl_socket.cc:87] [C59] ssl reserved slices: 2
[2019-04-19 23:02:30.010][29967][trace][connection] [source/extensions/transport_sockets/tls/ssl_socket.cc:90] [C59] ssl read returns: 1 0x28da031 16335
[2019-04-19 23:02:30.010][29967][trace][connection] [source/extensions/transport_sockets/tls/ssl_socket.cc:90] [C59] ssl read returns: 1 0x28ccc30 976
[2019-04-19 23:02:30.010][29967][trace][connection] [source/extensions/transport_sockets/tls/ssl_socket.cc:87] [C59] ssl reserved slices: 2
[2019-04-19 23:02:30.010][29967][trace][connection] [source/extensions/transport_sockets/tls/ssl_socket.cc:90] [C59] ssl read returns: 1 0x28ccc31 975
[2019-04-19 23:02:30.010][29967][trace][connection] [source/extensions/transport_sockets/tls/ssl_socket.cc:90] [C59] ssl read returns: 1 0x28de030 16336
[2019-04-19 23:02:30.010][29967][trace][connection] [source/extensions/transport_sockets/tls/ssl_socket.cc:87] [C59] ssl reserved slices: 2
[2019-04-19 23:02:30.010][29967][trace][connection] [source/extensions/transport_sockets/tls/ssl_socket.cc:90] [C59] ssl read returns: 1 0x28de031 16335
[2019-04-19 23:02:30.010][29967][trace][connection] [source/extensions/transport_sockets/tls/ssl_socket.cc:90] [C59] ssl read returns: 1 0x28cd030 976
[2019-04-19 23:02:30.010][29967][trace][connection] [source/extensions/transport_sockets/tls/ssl_socket.cc:87] [C59] ssl reserved slices: 2
[2019-04-19 23:02:30.010][29967][trace][connection] [source/extensions/transport_sockets/tls/ssl_socket.cc:90] [C59] ssl read returns: 1 0x28cd031 975
[2019-04-19 23:02:30.010][29967][trace][connection] [source/extensions/transport_sockets/tls/ssl_socket.cc:90] [C59] ssl read returns: 1 0x28e2030 16336
[2019-04-19 23:02:30.010][29967][trace][connection] [source/extensions/transport_sockets/tls/ssl_socket.cc:87] [C59] ssl reserved slices: 2
[2019-04-19 23:02:30.010][29967][trace][connection] [source/extensions/transport_sockets/tls/ssl_socket.cc:90] [C59] ssl read returns: 1 0x28e2031 16335
[2019-04-19 23:02:30.010][29967][trace][connection] [source/extensions/transport_sockets/tls/ssl_socket.cc:90] [C59] ssl read returns: 1 0x28cd430 976
[2019-04-19 23:02:30.010][29967][trace][connection] [source/extensions/transport_sockets/tls/ssl_socket.cc:87] [C59] ssl reserved slices: 2
[2019-04-19 23:02:30.010][29967][trace][connection] [source/extensions/transport_sockets/tls/ssl_socket.cc:90] [C59] ssl read returns: 1 0x28cd431 975
[2019-04-19 23:02:30.010][29967][trace][connection] [source/extensions/transport_sockets/tls/ssl_socket.cc:90] [C59] ssl read returns: 1 0x28e6030 16336
[2019-04-19 23:02:30.010][29967][trace][connection] [source/extensions/transport_sockets/tls/ssl_socket.cc:87] [C59] ssl reserved slices: 2
[2019-04-19 23:02:30.010][29967][trace][connection] [source/extensions/transport_sockets/tls/ssl_socket.cc:90] [C59] ssl read returns: 1 0x28e6031 16335
[2019-04-19 23:02:30.010][29967][trace][connection] [source/extensions/transport_sockets/tls/ssl_socket.cc:90] [C59] ssl read returns: 1 0x28cd830 976
[2019-04-19 23:02:30.010][29967][trace][connection] [source/extensions/transport_sockets/tls/ssl_socket.cc:87] [C59] ssl reserved slices: 2
[2019-04-19 23:02:30.010][29967][trace][connection] [source/extensions/transport_sockets/tls/ssl_socket.cc:90] [C59] ssl read returns: 1 0x28cd831 975
[2019-04-19 23:02:30.010][29967][trace][connection] [source/extensions/transport_sockets/tls/ssl_socket.cc:90] [C59] ssl read returns: 1 0x28ea030 16336
[2019-04-19 23:02:30.010][29967][trace][connection] [source/extensions/transport_sockets/tls/ssl_socket.cc:87] [C59] ssl reserved slices: 2
[2019-04-19 23:02:30.010][29967][trace][connection] [source/extensions/transport_sockets/tls/ssl_socket.cc:90] [C59] ssl read returns: 1 0x28ea031 16335
[2019-04-19 23:02:30.010][29967][trace][connection] [source/extensions/transport_sockets/tls/ssl_socket.cc:90] [C59] ssl read returns: 1 0x28cdc30 976
[2019-04-19 23:02:30.010][29967][trace][connection] [source/extensions/transport_sockets/tls/ssl_socket.cc:87] [C59] ssl reserved slices: 2
[2019-04-19 23:02:30.010][29967][trace][connection] [source/extensions/transport_sockets/tls/ssl_socket.cc:90] [C59] ssl read returns: 1 0x28cdc31 975
[2019-04-19 23:02:30.010][29967][trace][connection] [source/extensions/transport_sockets/tls/ssl_socket.cc:90] [C59] ssl read returns: 1 0x28ee030 16336

From where the reservation return 2 slices and ssl socket only commits 1 bytes, the address changes significantly, which also confirms https://github.com/envoyproxy/envoy/issues/6617#issuecomment-485052520

Thanks @lizan. I just ran @julia-stripe's test case with some extra diagnostic logging added to Envoy and found that, independent of whether the buffer is using its internal space efficiently, a bigger problem is that SslSocket::doRead(Buffer::Instance& read_buffer) keeps reading into the buffer and never consumes any of the data that's been read. The buffer length increases endlessly.
I started the Go server and Envoy with the configs from https://gist.github.com/julia-stripe/a9024d845e4b566f7aa06282e232a026 and sent a single HTTP request to Envoy:
curl localhost:8190 2>/dev/null > /dev/null

The Go server sent its HTTP response with Content-Length: 5 and, as designed, sent an infinitely long response body.
Within the while (keep_reading) { ... } loop in ssl_socket.cc, I logged the length of the buffer before each read. The results look like this:
buffer 0x3274ea8 len 0
buffer 0x3274ea8 len 38
buffer 0x3274ea8 len 39
buffer 0x3274ea8 len 40
[... lots of lines skipped ...]
buffer 0x3274ea8 len 400883
buffer 0x3274ea8 len 400885
buffer 0x3274ea8 len 400887
[... this continues forever ...]

That all happens in one call to SslSocket::doRead(Buffer::Instance& read_buffer).
The only things that will break out of that while (keep_reading) loop are:

EAGAIN or an error when reading the socket (which won't happen when the upstream is sending data as fast as this Go server is).
Or callbacks_->shouldDrainReadBuffer().

It looks like callbacks_->shouldDrainReadBuffer() eventually breaks out of that read loop in ssl_socket.cc ... after the buffer accumulates 1MB of data.
Then the SSL socket read callback gets called again (which makes sense, because there's still data arriving from upstream). It gets the same buffer, which has been drained, and it starts reading and buffering its next megabyte of data.
buffer 0xe590ea8 len 1048575
doRead 0xe590ea8  <-- new invocation of the SSL socket read callback
buffer 0xe590ea8 len 0
buffer 0xe590ea8 len 1

Here's the source of the 1MB buffering limit: https://github.com/envoyproxy/envoy/blob/master/source/common/upstream/upstream_impl.cc#L553
I propose that the default should be something like 16KB, which will be safer for people running edge proxies with hundreds of thousands of concurrent connections.

I think we need to step back here. What the default size of the flow control limit is, is IMO orthogonal to the actual problem here which is apparently a huge amount of wasted space when we read a single byte into the buffer. Can we figure out why the reservation code is not doing that efficiently so that we would only be allocating at most an extra 16KiB of buffer space in this pathological case?
I'm not sure that changing the default max buffer size is something we should do without more thinking but we can discuss that in the other PR.

I'm no longer sure that the buffer reservation code itself is doing anything wrong (other than what PR6663 fixes). Looking at how the SSL socket code is using the reservation, it's easy for it to produce large block of unused memory in the middle of a buffer.
SslSocket::doRead(Buffer::Instance& read_buffer) reserves two slices and does a separate socket read into each of them. If the first read returns one byte and the second read returns anything more than zero, we're going to end up with a lot of unusable space at the end of the first slice.
So I think there separate problems:

The commit logic in the new buffer impl (PR 6663)
The logic in SslSocket::doRead misuses buffer slices in a way that can lead to internal fragmentation.
The default buffer limits (PR 6665).

I just wrote a patch for issue 2 (internal fragmentation due to the way SslSocket::doRead uses the slices). I'll post a PR once the tests complete.

Yup OK I see the issue now, thanks for explaining it clearly.

My issue seem to be closely related to this one. Maybe we should re-open here ?

@prune998 please debug in the other issue you opened. There is not enough information to know what is going on. We won't be reopening this issue unless we determine it is not fixed.


<EMAIL_ADDRESS>wants to be a hudi committer and join slack discusisons

working as Data engineer in Paytm.

Hey.. added you to our slack group. Welcome aboard!


Add memcnew and strcnew

Add functions which create a newly allocated buffer containing only the character c (null-terminated, for strcnew)

done


Better display of promises and streams

Right now, unforced promises are displayed as #[promise (unforced)] and forced streams are displayed as #[promise (forced)].
This means that you can't see the remaining values in a stream, even if they've already been forced.
Ideally, it would be nice if streams (at least) could render as
(1 2 3 ...)

or something similar (possibly with an indicator to distinguish between a stream and Scheme list).
This change would need to be made simultaneously both here and in the Python interpreter, and should happen between semesters.
Let's keep discussion of this issue that doesn't have to be private to the course here.

Rejected by John. Instead, I'll focus on #20 to make visualizing streams easier after you already printed.


rtmpdump: unstable-2019-03-30 -> unstable-2021-02-19

Contains single but important change:
orbea (1):
Fix race condition in the librtmp install target.
Description of changes

Things done

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
22.11 Release Notes (or backporting 22.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module
[ ] (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes

[x] Fits CONTRIBUTING.md.

@GrahamcOfBorg eval


Extraneous dotfiles in test fixtures

Seem to have been introduced in 0ec8a6d1ba - .!.png, .!.spl in the test fixtures directory.
Not sure if anyone wants to rewrite the commit in question or just remove the offending files and add the right pattern to .gitignore...

Thanks for pointing this out. I've removed the files


Menu for mobile presentation

Is your feature request related to a problem?
Currently the main navigation is the same in desktop and mobile presentation. However, it would be nice to have a mobile friendly menu for smaller screen sizes.
Describe the solution you'd like
Menu for site navigation, probably a hamburger or similar menu.

Fixed in #232


Support parallel impedance calculation in AnalogLink

DO NOT MERGE - DEPENDS ON #50. Resolves #47. One case towards #49, I'll probably implement more cases as they're needed (I'm not sure this is the right way).
Fix AnalogLink to properly calculate parallel impedances of its sinks. Adds support for Range / Array[Range] operations in the compiler.
TODO

[x] Actually fix the Simon example (should be a HDL issue)
[x] Add a unit test, including the infinity case, a double infinity case, a double non-infinity case, and a mix of both

A future PR will address typing information, there's now a tracking issue for that #54

What do you mean fragile? Like not all cases are defined, or -0?
I'm not too worried about empty parallel impedances - it shouldn't be possible to have an analog link with no sink ports. But I think there's going to be a decent degree of building out more complete expression evaluation concepts as we have more motivating examples - because without those it's unclear whether we're building the right thing.
I think currently the reduce-on-empty definitions are 'good enough', but in the future it might be useful to allow explicit specification of either the initial value to be passed into a reduction, or the value returned on empty.


fix: change 'suborg' to 'group' for list channels endpoint

The /channels endpoint for whatever reason does calls the suborg property group. All the other endpoints do call it suborg from what I could find.

LGTM


Cannot access "Default Role Center" field for Tenant Profile table even after issue #500 resolved

I created profile through profile object as below but still cannot make it default. How I can access Default Role Center field from AL. Thank you.
profile "Power Accountant"
{
Description = 'Power Accountant';
RoleCenter = "Power Accountant Role Center";
Customizations = MyCustomization;
}

Hi @yandko,
There are no property on the profile object to set that, but you can change it from code, for instance using the onInstall triggers .

hi @thpeder,
thank you for the reply. I tried to define record variable to point to Profile table (record<PHONE_NUMBER>) but it looks like the system doesn't allow me to do this saying
"The type or method 'Profile' cannot be used for 'Extension' development.
Error: The package could not be created."
Maybe it is because Profile is a reserved system keyword for defining Profile object.
    local procedure HandleFreshInstall();         var             r: Record<PHONE_NUMBER>;     begin         // Do work needed the first time this extension is ever installed for this tenant.         // Some possible usages:         // - Service callback/telemetry indicating that extension was install         // - Initial data setup for use     end;

Hi @yandko,
The table was made available in the anniversary update, which was released about half a year ago.
What version are you running?

hi @thpeder,
thank you for not leaving this along. I use the latest AL Language VCODE extension 0.15.18771 and NAV Platform Build 21441.

@yandko, Could you try and redownload the symbols in VSCode. Ctrl + Shift + P then type: AL: Download Symbols.

AL VsCode extension versions do not work with any server versions. You have to use the AL VsCode extension that was released for the given server version,

Hi @yandko,
As Kalman pointed out, you should be using the VSIX that came with the DvD.
I found the problem and it is that the system symbol file doesn't allow you to use that table and NAV 2018 didn't get that update since it got in after we branched for NAV 2018, so please have a look at:
Will features from the latest Dynamics 365 releases be back-ported to NAV 2018?
and
I found an issue on NAV 2018, what do I do?

hi @thpeder,
I have reinstalled NAV2018 from "CU 05 NAV 2018 W1" and visual studio code Al Language extension from VSIX file that is coming with this CU (AL Language 0.12.20065). Than re-Downloaded Symbols. Same issue. Neither definition works. It can't create a reference to Profile table.
       r1: Record<PHONE_NUMBER>;
       r2: Record<PHONE_NUMBER>;
       r3: Record "Tenant Profile";
       r4: Record "Profile";

Hi @yandko,
It wasn't backported to Nav 2018 only Business Central, so I'll fix that.


add databaseClient.newMoveManager()

We should now get DataMovementMangager from databaseClient.newMoveManager rather than "new DataMovementManager().withClient(databaseClient)".  That will align with the other managers in the Java Client API, and remove the step of setting the client.

Srinath, when you look at this, can you make sure all functional tests no longer use DataMovementManager.newInstance?  Then I'll remove that capability.  Hmm, I'll just make a PR for that and you can merge it...

Verified that databaseClient.newMoveManager works fine


feat: The lexicographic sum of two locally finite orders is locally finite

Forward-ports https://github.com/leanprover-community/mathlib/pull/11352

Can you fix up the style here?


Add 0pdd integration

Affects #11

@rultor please merge

@rultor please merge

@extsoft OK, I'll try to merge now. You can check the progress of the merge here

@rultor please merge

@extsoft Done! FYI, the full log is here (took me 1min)


Dependency on Python >3.8

Minor issue, just thought I'd mention that currently, graphicle requires at Python version >3.8 to avoid the error Module 'functools' has no attribute 'cached_property', which didn't exist before 3.8. Apologies if this dependancy is already mentioned somewhere and I missed it.

Thank you @Kieran-Mg1! Maybe it's mentioned somewhere, though the desired behaviour should be to have the build system refuse to install with earlier than 3.8, so I shall add a patch.

Turns out I didn't even use those functions in the current version, so simple enough to just remove and maintain further backward compatibility. Thanks for pointing this out, graphicle==0.1.2 has been added to PyPI.


os/linux: MacOS::CLT.installed? is true [Linux]

Codecov Report

Merging #653 into master will decrease coverage by 0.01%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master     #653      +/-   ##
==========================================
- Coverage   68.69%   68.67%   -0.02%
==========================================
  Files         382      382
  Lines       20592    20597       +5
==========================================
  Hits        14146    14146
- Misses       6446     6451       +5

Impacted Files
Coverage Δ

os/linux.rb
0% <0%> (ø)
:arrow_up:

Continue to review full report at Codecov.

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

I still get an undefined method error when installing python@2 - is this perhaps missing module_function?

Eep. Yes, it is. Thanks, Sam! Fixed by PR https://github.com/Linuxbrew/brew/pull/655


Update document and demo related to internationalization

update documentation for internationalization
fix a typo in an internationalization demo example
based on this Pull Request

Thank you 💯

Hi @burakcan , thanks for merging it in!
I am planning to create another PR with more translations(French, Italian, German), the place I am working at use this library (btw, great work!) , and we would love to provide translations in different languages to help on the localization part.


LineRenderer cannot find prefabs instantiated at runtime

LineRenderer seemed like an obvious choice for drawing constellation paths, but setting nodes of the line cannot be done by finding stars that were instantiated as prefabs. Might have to cache star locations somewhere and use it as a resource for setting constellation paths.

Partially solved, LineRenderer does not search for prefabs, lines drawn manually

Looks like you are missing the following deliverables:

Completed user stories checked-off in README (+2pts)

Your assignment is incomplete until all the deliverables are complete. Once completed, please push your updates, update your README, update your project board, and submit your group milestone again using the submit button on the appropriate assignment page so we can regrade it.
Whenever you make updates to your project that require re-grading, you need to re-submit your project using the submit button on the associated assignment page in the course portal. This will flag your project as “updated” on our end and we know to re-grade.
You should re-submit your assignment anytime you:

Update a previously incomplete assignment
Add optional and additional features to an already completed assignment
/cc @codepathreview


node-notifier not working on the remote

I have created very small api to upload the file to the local system. Upon completion, i want to trigger the notification saying the upload is completed. This is working fine when I access through the local URL - localhost:3000.
But the notification not coming while trying to access on the different system using my system IP address: sample URL - http://<IP_ADDRESS>:3000/.
Any help would be appreciated!

Any help on this please!

Hi, do you have any code so we can see? This isn’t related to node-notifier, strictly speaking. Node-notifier is just a local tool for communicating with your OS, and doesn’t care if you have a http api built on top of it.

My app.js code:
const express = require("express");
const app = express();
const http = require("http").Server(app).listen(3000);
const notifier = require("node-notifier");
console.log("Server Started");
app.get("/", function (req, res) {
res.send("Loaded");
notifier.notify("test");
})
I am receiving the notification while run on the local. When I tried to access on another machine using my machine ip address, the notification is still sending to my local machine.

Yes. Sorry, but this is expected behaviour. There is no built in support for notifications a cross networks in node-notifier. It's only a tool for communicating with the OS of the computer running node-notifier.


Add CA Certificates Buildpack to Group Ordering

We should add the CA Certificates Buildpack to each group in the buildpack. This buildpack will allow application developers to provide their own CA certificates and have them included in the root truststore at build and runtime.

LGTM. Accepted


Error in permissionex

Description
[Insert description of issue here]
What PEX Saw

No information provided.  Ticket closed.


Web Page Caching still load cached files when not enabled

Hi,
If a page have been cached using the web page caching ($this->output->cache($n);), the cached page is still loaded after we disabled the web page config functionality unless we delete the cached file.
I think the cached files should not be loaded if we didn't enable the web page caching.

This behavior is documented and there's a reason for it - to know whether $this->output->cache() is called, we'd have to execute all of your code before printing the possibly cached output.
The entire point of caching is to skip code execution.


Leaderboard ap is

I did The Following:

Created a new feature Branch Leaderboard-APIs
Implemented the APIs
Created Module folder with apis.js files
Used async and await.
Fix Linter Errors

@mikethreels @Mihndim2020
Thanks


Wrong Screen Size on iPad after upgrade

Environment
Docker
Version
0.12.1
Describe the problem
Since I have upgraded Homarr from v0.11.5 to 0.12.1 on my iPad the screen size category "small" instead of "medium" is chosen. Additionally, the symbols are very big and ordered in a very strange manner. On other devices (smartphone with screen size “small” and PC with screen size “large”) everything is working correctly. I am using the same config on all devices (“default”).
Specs from my iPad:
iPad 8. Generation, iOS 16.3, Browser: Safari
Screen Resolution: 1620 x 2160 Pixel – but Websites seems to handle it as a screen with 810 x 1080 Pixel Resolution which would fit to “medium” (< 1440 && >768).
I now downgraded to 0.11.5 and everything is working fine again.
Logs
No interesting logs when opening homarr on iPad
Context
No response
Please tick the boxes

[X] I confirm that I attached the proper logs
[X] I've read the docs
[X] I've checked for duplicate issues
[X] I've tried to debug myself

Hi, thanks for your issue.
The exact breakpoints can be seen here:
https://homarr.dev/docs/customizations/layout#screen-sizes
For issues like this, it would also be helpful to get screenshots or example configs with example resolutions.
We can emulate different screen sizes to reproduce.

@LimesRunner do you have a different layout on all screen sizes ? ( are apps supposed to be in different places ? )

@manuel-rw : Here are some screenshots:
iPad, v0.12.1, screen size small:

iPad, v11.5, screen size medium:

Smartphone, v0.12.1 (but equal to v.11.5), screen size small:

@ajnart
As you can see from the screen shots (compare medium and small), the categories are ordered in the same manner, the apps are ordered slightly different due to the different screen sizes.

@ajnart
As you can see from the screen shots (compare medium and small), the categories are ordered in the same manner, the apps are ordered slightly different due to the different screen sizes.

My question was more to know if you take advantage of the ability to move around apps for different layouts. You could have all "phone-oriented" apps first on the small layout. I am asking because we are considering to remove the ability to have apps in different places on different sizes because it creates confusion if you just move apps in one size and not the others. But you'll still keep the ability to choose the number of columns on each sizes.
Regarding your issue I'll look into it. But most browser have some kind of "zoom" feature.
The ribbons on the side should only appear on small devices so it's weird they appear on the iPad at medium size. I think the iPad width is between our breakpoint to disable the ribbon and the one to show medium size layout

Do you still encounter this issue ?

Unfortunately yes (Version 0.12.3)


[filebeat] Add service and deployment ports functionality

[x] Chart version not bumped (the versions are all bumped and released at the same time)
[x] README.md updated with any new values or changes
[ ] Updated template tests in ${CHART}/tests/*.py
[ ] Updated integration tests in ${CHART}/examples/*/test/goss.yaml

Adds ports configuration possibilty for filebeat deployments and also an optional servcie. Use case: Running filebeat with e.g. the checkpoint module and sending external UDP syslog traffic via nodeport service.

jenkins test this please

Related to #511

Hi @boernd,
Thanks for opening this PR.
We'll try to review it soon. Please be patient.

jenkins test this please

Please also support service.loadBalancerIP

still valid

What's needed/missing to get this PR merged?


Hi from JSON Schema! We'd like to add shadcn-ui to the JSON Schema Landscape

Feature description
Hi shadcn-ui Community!
This is Benjamin from the JSON Schema Community. First of all congrats for the amazing work with the project! We recently discovered that shadcn-ui uses JSON Schema and we'd like to make sure we offer our support here!
We'd like also to add shadcn-ui to the adopters section of the JSON Schema Landscape: https://landscape.json-schema.org/ Could this be possible?
Thanks a lot!
Affected component/components
No response
Additional Context
Additional details here...
Before submitting

[X] I've made research efforts and searched the documentation
[X] I've searched for existing issues and PRs

This issue has been automatically closed because it received no activity for a while. If you think it was closed by accident, please leave a comment. Thank you.


[exporter] Vanilla

thank you!!

Please prioritize this request. A vanillaforum to nodebb script would be great !

Any update?
I'm seeking for a plugin to migrate from Vanilla as well. Thanks.

I've got most of the development for one here but it's a work in progress.. There are some missing things like a user's place in the thread (because NodeBB doesn't support it yet)
However some plugins (like quotes and spoilers) are supported.

nice work @bdharrington7  - let me know if there is anything i can help with
also let me know when you have a stable release so I can add it to the supported list

@bdharrington7 Thanks, I tried it and it works mostly good, but some data of the new NodeBB seems not purged - some user logged in as another one, and posts content merged or replaced.
However if the NodeBB is a new installation these problems should be gone.

@phoenixlzx so.. are you saying it worked after setting up a clean NodeBB?

yea, this is not really designed to merge data. In fact, the importer will FLUSH or wipe out your existing nodebb DB - if the import process was interrupted, in most case it can resume (it some it cannot)

@bdharrington7 @akhoury Yeah, my vanillaforums converted to NodeBB successfully with a new installation. Only one problem found - the topic ID changed.
Maybe you need to add a instruction of these.

@phoenixlzx - ALL ids will change, Topics, Users, Posts, Categories, Messages  etc..
but that totally expected and should NOT be problem, as the Importer will handle all of these changes.
https://github.com/akhoury/nodebb-plugin-import/blob/master/write-my-own-exporter.md#terminology
However, 1 issue might come up if you care about redirecting URLs, you can download a redirect.map.json file and use it to redirect your URLs, read this section
https://github.com/akhoury/nodebb-plugin-import#imported-now-what

@phoenixlzx @fr3em1nd Please note that I had to back out some works in progress from the master branch (which shouldn't affect you if you pulled the version I linked to), but just to be safe, please delete and re-clone the master branch if you're going to be using the importer for vanilla any more

closing..
all new vanilla issues should be filed under @bdharrington7 's repo
https://github.com/bdharrington7/nodebb-plugin-import-vanilla
which im watching as well


Demonstrate netCDF file request

Produce notebooks that do the following

[ ] Demonstrate request for netCDF files
[ ] Produce basic 2D hexabin plots

[ ] y-axis: depth, x-axis: time
[ ] basic zoom in/out functionality

PR #16 allows for capabilities in requesting netCDF files in parallel.

Notebooks to come for demonstrations.


support for inchikeys (issue #131); test data not updated yet

Changes towards addressing issue #131

ability to add inchi keys when we're saving smiles (used in preprocessing and creation of test/train sets).
ability for precalculated inchi keys for pubchem (not added there yet though).
a short run of the workflow has been checked for completion without errors (on the LOTUS_truncated dataset).
None of the test_data files have been updated yet, so tests are expected to fail.

closing this in favor of PR #136


api: Add web_public_access_enabled realm setting.

Plumbs through the web_public_access_enabled realm setting added in 5.0:
https://zulip.com/api/get-server-settings

The last one can be updated by events; not sure about the other two.

I don't quite understand this. Here's the definition of user_has_permission:
https://github.com/Fingel/zulip/blob/f4a6d8f4544f44cb9da807b4923df76bcae82465/static/js/settings_data.ts#L115
I'm having a hard time finding anything in zulip-web relating to user permissions. I'd hope we wouldn't need to re-implement that check.

FWIW I think both settings_data.js and settings_config.js are modules that were created with a view towards being able to move them to shared with relatively modest refactoring and reuse them in the mobile apps (possibly with parts of them moved to be data the server sends).  (The prior model had the types of data structures we have there scattered in a bunch of places).

I don't quite understand this. Here's the definition of user_has_permission:

Ah, I just meant that of those three values from page_params, the last one (page_params.realm_create_web_public_stream_policy) can get updated by events, and I haven't looked into the others. Some values the web app keeps in page_params are simply constant after the page loads.
For mobile, where there is an event we'll want to handle it.

Here's the definition of user_has_permission:
https://github.com/Fingel/zulip/blob/f4a6d8f4544f44cb9da807b4923df76bcae82465/static/js/settings_data.ts#L115
[…] I'd hope we wouldn't need to re-implement that check.

Yikes, yeah.
For the sake of getting web-public streams out the door, I'd be happy with having a function that's just a translation of that one to adapt it to our data structures. But then clearly a thing we'll want to do to keep this area maintainable, rather than duplicate more and more of the code around that, will be to do some refactoring of the kind Tim mentioned and move this code to shared so we can reuse it directly.
(Writing a translation of this function to adapt to our data structures can even be a useful step toward that refactoring, by helping guide us on what a shareable version of the function will look like.)

Data needed for user_can_create_web_public_streams():
server_web_public_streams_enabled and realm_enable_spectator_access and realm_create_web_public_stream_policy can all be found in the /register endpoint
Looking into user_has_permission:
There are a lot of constants defined in settings_config.ts which I don't think really have an analogue in mobile? But they are used in checks like this:
if (policy_value === settings_config.create_web_public_stream_policy_values.nobody.code)
if (policy_value === settings_config.create_web_public_stream_policy_values.by_owners_only.code)
if (policy_value === settings_config.common_message_policy_values.by_everyone.code)
if (policy_value === settings_config.common_policy_values.by_admins_only.code)
if (policy_value === settings_config.common_policy_values.by_moderators_only.code)
if (policy_value === settings_config.common_policy_values.by_members.code)
page_params.is_spectator is defined to be the inverse of whether a user has a profile or not. I believe you cannot use the mobile app anonymously, so we can assume this is always false?
page_params.is_owner, page_params.is_admin, page_params.is_guest are found on the get user endpoint.
page_params.is_moderator is done as a check against the user role , and the role is passed in via the get_user endpoint.
Then at the end there is this logic to check whether a user has been active long enough.
realm_waiting_period_threshold is also found on the /register endpoint.
date_joined can be found in the  get_user endpoint.
So at a high level maybe we don't need to completely implement user_has_permission, but only the checks that are relevant to web public streams? A lot of this data from the user and register endpoints could already be available in mobile. We might need to pull in some of those role constants to do those checks, unless there is an API that exposes them.

Thanks, @Fingel! Closing as superseded by #5349 / #5354. Thanks in particular for your useful notes at https://github.com/zulip/zulip-mobile/pull/5322#issuecomment-1097211735, which sped up my work on #5384.


Enable TestCafe to Take Browser Heap Snapshot as we can take from Chrome DevTool Memory Tab Option

What is your Test Scenario?
I do take Memory Heap Snapshot of different pages in Chrome DevTool Memory Option which I think could be Automated in TestCafe.
What are you suggesting?
I do take Memory Heap Snapshot of different pages in Chrome DevTool Memory Option which I think could be implemented in TestCafe. This Will help to take automatic Browser Heap Snapshots of WebPages and later we can analyze those Heap snapshots by just loading to Chrome DevTool Memory Tab.
What alternatives have you considered?
Right Now I do this manually in Chrome DevTool Memory Tab like in below screenshot for different pages :-

@rakeshkumartripathy
Hello,
At present, we cannot interact with DevTools UI / DevTools Protocol to take a Heap snapshot. I marked this issue as an enhancement.
As a workaround, I suggest you use the window.performance interface to collect all needed information. Here you can find a way to access the memory and timing objects in tests. Note that TestCafe affects browser performance and, as a result, your performance analysis.


Preserve ordering of classes

This should fix #393.
I didn't add functionality that preserves uniqueness of classes, since classList.add will do that for us.

I'm not using yew anymore since my project using it didn't pan out, but I'll take a look at rebasing this PR and incorporating your review over the weekend.

I incorporated your comments into the pull request. However, to support the not equal assertion I had to make some changes to the eq implementation for VTag, since the IndexSet doesn't account for ordering when checking for equality.

bors r+


Setting Timestamp Format as an Option

Hi,
Is there a way to set the timestamp format as an option, like we do in reading the csv files, the timestampFormat option?
I've tried setting it using the following code
spark.read
      .option("rowTag", "row")
      .option("timestampFormat", "dd-MM-yyyy")
      .schema(schema)
      .xml("test.xml").show()

But it always returns null in the Timestamp field. Also, I've tried searching for a method representing that option in the XMLReader but I couldn't find any.
It would be really great if you could add setting the timestamp as an option while reading the XML files, if it's not already there :)

Can you show your schema and sample XML? There is some support for parsing dates, but I am not sure if it's 100% right. Timestamps (with hour/minute/second) should work.

Timestamps (with hour/minute/second) should work.

I've tried adding hour/minute/second with the format proposed above, but it didn't work. Only the default one, with hour/minute/second written, works. Probably, the data that I'd get won't contain hours/minutes/seconds in it.
Here's the XML:
<book>
    <author>John Smith</author>
    <date>01-01-2021</date>
</book>

Here's the schema as well:
root
 |-- author: string (nullable = true)
 |-- date: timestamp (nullable = true)

Here's the complete code reading the XML:
import com.databricks.spark.xml._
import org.apache.spark.sql.SparkSession
import org.apache.log4j.{Level, Logger}
import org.apache.spark.sql.types.{StringType, StructField, StructType, TimestampType}

object Main {
  def main(args: Array[String]): Unit = {
    Logger.getLogger("org").setLevel(Level.ERROR)
    val spark = SparkSession
      .builder()
      .master("local")
      .getOrCreate()

    val schema = StructType(
      Array(
        StructField("author", StringType),
        StructField("date", TimestampType)
      )
    )

    schema.printTreeString()

    spark.read
      .option("rowTag", "book")
      .option("timestampFormat", "dd-MM-yyyy")
      .schema(schema)
      .xml("test.xml").show()
  }
}

A few things are going on here -
You'll need to specify DateType in the schema as this isn't a timestamp.
I also found that schema inference doesn't correctly infer date, and can fix that, but it isn't your issue here.
It works if you use ISO formatted dates like "2021-01-01".
I assume you have to override that right, because your data isn't ISO formatted?
There isn't a timestampFormat or dateFormat option now. But, seems like that is the feature request then.
I guess the semantics would be, if you specify the format for date or time, that it will only accept that format and not ISO-formatted ones? or merely add to the list of formats it will accept?


Default views/templates per model

It would be nice to have a default template per model , which shows a list of items and the item properties.
It doesnt need to be fancy.
It would mean that after creating models and data, the generator can create a browsable version, without creating biolerplate views and templates.
It will also cut down the size/complexity of integration tests.
It might be a continuation of statik --quickstart , maybe statik --autogen

This would provide a nice framework in which to add extra batteries for https://github.com/thanethomson/statik/issues/23 (feeds) and https://github.com/thanethomson/statik/issues/71 (sitemaps)


[contrib] Fix "custom_path" already exist bug

fix error when use custom_path parameter in tempdir funciton.

Hi @huanmei9, just curious what the use case is here? Doesn't this allow for race conditions and pollution by re-using temporary directories?

I believe the correct way to do this is os.makedirs with exist_ok=True.

Hmm I agree with @tkonolige. It is slightly better to use the existing API provided by python. Please make changes accordingly and then we get the PR merged :-) Thanks a lot!

Hi @tkonolige @junrushao1994 .
Thanks for your suggestions, I have changed the code according to your suggestion.

Hi, @leandron .
Sorry for the late reply.
My use case is to check the build fils generated by zephyr in MicroTVM, such as .map and .hex files.
In addition, regardless of the use case, the tempdir function provides a custom_path interface, so it should be robust enough.

Hi @huanmei9,
I would suggest that the current implementation of custom_path is robust, consider a typical task which does the following:

Creates a temporary directory
Writes some files
Checks those files

With the current behaviour, if two tasks attempt to do this in parallel (such as parallel tests from pytest-xdist), you get the following:

Task A creates a temporary directory
Task A writes some files
Task B attempts to create a temporary directory - raises Exception that temporary directory already exists
Task A checks those files
Task B has failed as it tries to pollute the existing temporary directory.

With this change, you can instead have:

Task A creates a temporary directory
Task A writes some files
Task B attempts to create a temporary directory - no error raised
Task B writes some files
Task A checks those files - raises assertion error
Task B checks those files
Task A has now failed because of the pollution of the temporary directory and the error is also incorrectly attributed to Task A rather than Task B. This scenario only occurs intermittently and is therefore harder to debug.

Therefore, I would suggest that the current implementation of temp dir helps to prevent such concurrency bugs and raises the correct error to ensure we use a new fresh temp directory per invocation - what are your thoughts?

Hi, @Mousius .
The situation you describe is indeed possible, Thanks for your suggestion.
(●'◡'●)


adds styled-components documentation to README.md

#23

@Remownz thanks for PR! 🎉
Since you had a chance to use this module for your needs, have you run into any issue? Apart of bugs, anything API-wide? Would love to hear your feedback on improvement / suggestions.

@sergeybekrin you're welcome. Thank you for your great module!
I think it would be an improvement if the fonts passed to HoC would be passed as one property to React.createElement https://github.com/sergeybekrin/react-with-async-fonts/blob/631ad42007865ca7cf05f4612254562df93feb4e/src/index.ts#L35 otherwise you have to destructing all fonts. e.g. https://gist.github.com/Remownz/57fa39f86847c45929db31760221baec
Do you understand what i mean? Sorry for my bad english!

@Remownz yep completely got you! I'll think about that change, seems it fits better when using multiply fonts.


function send_resp/3 undefined

When I'm running the kitchen sink example, I'm getting the following error:
$ pwd
.../placid/examples/kitchensink
$ iex -S mix
Erlang/OTP 17 [erts-6.4.1] [source] [64-bit] [smp:8:8] [async-threads:10] [hipe] [kernel-poll:false]

Compiled lib/kitchen_sink.ex
Compiled lib/kitchen_sink/handlers/v1/main.ex

== Compilation error on file lib/kitchen_sink/router.ex ==
** (CompileError) lib/kitchen_sink/router.ex:1: function send_resp/3 undefined
    (stdlib) lists.erl:1336: :lists.foreach/2
    (stdlib) erl_eval.erl:657: :erl_eval.do_apply/6

Thanks for reporting the issue, @eproxus! This has been fixed upstream in http_router (which provides the routing macros), so I'll try to get this updated soon so the example works again.

Hey @eproxus! Sorry for the delay. This should be fixed now.

Thanks!


A developer friendly and clear statement abut data returned by the API is needed

Problem description
"the number of switch on users" is: confusing for application developers.

what is a switch?
who is a user?
what does "on users" really mean?

Expected behavior
The description must clearly specify what exactly is counted using application developers friendly language
For example:

The API returns number of SIM cards located in the given areas
The API returns number of devices identified by a SIM card located in the given areas

Agree with @gregory1g
As discussed during our meeting probably connected devices will be better.
Regarding the API name perhaps we need to think about changing it.

I think we have reached a preliminary agreement. Due to the inability to confirm the number of users, it was mentioned in the meeting that changing the name of the API to Region Device Count would be more appropriate. If there are no different opinions, I will submit this proposal to TSC this Friday and close this issue.

"Region Device Count" is good, "Region Sim Count" could be a bit more accurate.
A device is a phone, drone, watch etc. One device can have multiple SIMs inside (theoretically all SIMs can be from the same MNO) and API will count SIMs, not devices they are "put in".

"Region Device Count" is good, "Region Sim Count" could be a bit more accurate. A device is a phone, drone, watch etc. One device can have multiple SIMs inside (theoretically all SIMs can be from the same MNO) and API will count SIMs, not devices they are "put in".

I agree, the Region SIM count is indeed more accurate, but is it too technical? It may not be easy for users to understand. I hope everyone can provide feedback or submit it to TSC for selection (I am not sure if they will help us choose)

Both of your comment make sense :) .... SIM is more accurate while device is more understandable. I have a very small preference for device but will follow team preference. Let's get our preference in this group and then we expose it to the TSC.

I have another question/comment - If we agreed that we count the SIM (whatever we use SIM or Device in the API Name) do we need to allow requester to make distinction between SIM for direct user device (phone, weareable) vs IoT device?
I'm looking to the UC provided by @chinaunicomyangfan - in particular the User Story 1 - I tend to think that we are looking here for 'human' associated with device but not IoT device.
WDYT?

I would say that for both UC the API should offer a filter. This way API user can specify what type of devices is needed. This is especially important for advertisement user story. One can start with simple filter like human/IoT, roamers/local. But design the filter so that it can be extended in the future.

Yes ! I got also the comment about counting or not the roamers ;)

@bigludo7 @gregory1g
Thank you for your suggestion. This is also the topic I plan to discuss. The Region User Count API has some mature usage scenarios in our internal products. Currently, in our internal use, we provide the following response parameters to meet the needs of different scenarios: total users, 5G users, 4G users, 23G users, IoT users, mobile users, roaming users, and local users. I think it makes sense to return by user classification. Further discussion may be needed on which categories are necessary. In my opinion, distinguishing between humans and IoT devices is necessary for User Story 1, and distinguishing between roaming and local may be necessary for advertising scenarios.

Let me add two ideas for the discussion:

the filter must be extendable and flexible.
the API must not be limited to listed 2 scenarios exclusively. Advertisement is one of the use cases, and this use case can benefit   mostly any filtering option and combinations.

Therefore, I suggest to consider a filter which:

allows apply different criteria independently - like 5G and roamers
allows introduction of new filtering criteria (like smartphone type - Android/iOS) in the future in a backward compatible way

Let me add two ideas for the discussion:

the filter must be extendable and flexible.
the API must not be limited to listed 2 scenarios exclusively. Advertisement is one of the use cases, and this use case can benefit   mostly any filtering option and combinations.

Therefore, I suggest to consider a filter which:

allows apply different criteria independently - like 5G and roamers
allows introduction of new filtering criteria (like smartphone type - Android/iOS) in the future in a backward compatible way
@gregory1g
excellent idea,so do you have any suggestions for request or response parameters

Herbert, if we want to switch API name from RegionUserCount to RegionDeviceCount what is the process? From this WG team this latest name reflects more the API intent.

I would say that this is mainly a topic to align with APIBacklog:

Open an issue within APIBacklog - the table there need to be updated and the new name should be communication properly towards GSMA OGW Product team
Potentially PR on APIproposal_RegionUserCount_ChinaUnicom.md if there are more changes then just the name, e.g. regarding the scope

For TSC I would consider it enough if APIBacklog is informing about the change.

Herbert, if we want to switch API name from RegionUserCount to RegionDeviceCount what is the process? From this WG team this latest name reflects more the API intent.

I would say that this is mainly a topic to align with APIBacklog:

Open an issue within APIBacklog - the table there need to be updated and the new name should be communication properly towards GSMA OGW Product team
Potentially PR on APIproposal_RegionUserCount_ChinaUnicom.md if there are more changes then just the name, e.g. regarding the scope

For TSC I would consider it enough if APIBacklog is informing about the change.

Thank you Herbert,Do you mean we should communicate with GSMA OGW Product team first?

Just saying that both, APIBacklog and OGW Product team, need to be involved/informed (as it was a proposal coming with one of the OGW drops). I have no specific opinion about the sequence.

@chinaunicomyangfan @hdamker
Thanks Herbert
To sum-up:

Issue & PR in https://github.com/camaraproject/APIBacklog
An email to GSMA product stream leaders : Helene Vigue & Olu Omobitan

@chinaunicomyangfan I let you triggering this ? (I can help but will be off 17 to 26th May).

@bigludo7 Thank you, I will handle it. Have a nice vacation

email to GSMA has been sent and Helene suggested us to submit issue and PR to API Backlog.
so the issue has been submitted here.

Issue & PR in https://github.com/camaraproject/APIBacklog
An email to GSMA product stream leaders : Helene Vigue & Olu Omobitan

repo name has been modified,close this issue.

it looks like there is some agreements about filtering capability.
suggestion: extract filter capability to a separate dedicated issue and clarify the topic there.

it looks like there is some agreements about filtering capability. suggestion: extract filter capability to a separate dedicated issue and clarify the topic there.

@gregory1g Thank you for your suggestion. Do you mention adding filtering function to classify and filter devices? For example, adding a parameter to distinguish between 4G and 5G users, and also adding a parameter to distinguish between human network devices and IoT devices. Do I understand correctly？

I would start from roamers/all/non-roamers, other filter criteria to be discussed as well.

OK,I think we can open a new issue to discuss about it.


Failing test case when two requests with the same request argument are collapsed

This test case fails because two ObservableCollapserGetWordForNumber commands are collapsed, both of them having the same request argument. Test passes with:
TestSubscriber<String> subscriber1 = getWordForNumber(contextAwareScheduler, 0);
TestSubscriber<String> subscriber2 = getWordForNumber(contextAwareScheduler, 1);

//then
subscriberReceived(subscriber1, 0);
subscriberReceived(subscriber2, 1);

The error is:
java.lang.IllegalStateException:
No response set by ObservableCollapserGetWordForNumber 'mapResponseToRequests' implementation

Looks like here requests with the same argument are silently ignored. When response later arrives they are not populated.
I'm not sure if it's a bug in Hystrix or in example ObservableCollapserGetWordForNumber.

NetflixOSS » Hystrix » Hystrix-pull-requests #437 SUCCESS
This pull request looks good

Thanks for the testcase along with the description, @nurkiewicz .
My thought here is that :

If request-caching is implemented for the collapser, the 2nd-nth submission of the same argument should get immediately looked up in the request-cache.
Otherwise, the request-cache data structure is not set up, so we can't use it.
There's a problem if we submit the repeated argument in the batch multiple times: Given a series of OnNext(value)s for that argument, there's no way to distinguish which argument should get matched.
Therefore, I think the only sensible thing to do is to dedupe the arguments within the batch, and then return the same stream of values to each instance of an argument.

Thoughts?

Given the current structure of the HystrixObservableCollapser, I think there are 3 choices:

If request-caching is enabled, then the only way to encounter this condition is 2 simultaneous batch-adds that happen before the cache-key is added to the request-cache.  In this case, caching is clearly desired by the user, so we should prevent duplicate addition to the batch, and only submit the argument once.  Then we must hook up the responses to all such arguments.

Otherwise, request-caching is off.  In this case, there are 2 possibilities:

2a) The presence of duplicate arguments in the batch is an error.  The 2nd-nth such argument would receive an error.
2b) The presence of duplicate arguments in the batch is permitted.  The 2nd-nth such argument will receive the same value as the first.
I'll add a new configuration option to allow the user to choose which of 2a/2b should apply.
Also, note that allowing duplicate arguments in the same batch is still not permitted with this design.  Given that this would be a more involved refactoring (and the only time it's come up is here - in the hystrix-examples module), I will defer it for now but track it separately.
Thoughts?

After thinking about this more, since the default for request cache enabled is true, having the user disable it is a strong enough signal that they don't want multiple arguments to result in the same work being done.
Therefore, I will not add a new config option, and use request cache enabled for choosing between 2a/2b above.  The only 2 cases will be that :
A) If request caching is on, the 2nd-nth appearance of an argument in a batch results in the same value as the first (from the cache)
B) If request caching has been explicitly disabled, the 2nd-nth appearance of an argument in a batch results in an error.  This forces the user to not place the same argument in the batch.  If this is problematic in practice, then that's another issue to work on.  I suspect it will not be.

This test case pases now after merging #1278


Bug: Uncaught (in promise) TypeError: i is undefined on cmdk-sv website

Hello!
Just wanted to report an issue i found on https://www.cmdk-sv.com/.
Choosing the vercel option causes an uncaught TypeError. When the error is thrown no other option can be chosen. Need to reload to make it work again.
Any other option works fine.

Thank you! Will investigate!


Moderation tab

Closes #254, except for the link to the Dispute Resolution Guidelines. See #338.

Submitting some fixes to the tests shortly.

Travis is throwing some weird errors on this. I can't reproduce them when running tests locally.


Add HSL to color spaces for editing the color

Please add ability to change HSB to HSL (or add HSL) to be able to have a lightness slider. Would really help selecting shades in the same color.

Hi @Spark3000, thank you for your comment.
The Color Picker for VS Code already can change the color notations for the output.
You can specify that by drop-down list in the dialog box.
And also, you can change the color notation of color strings that were written in the editor by the Convert Color command.
Supported color notations:

hsb()/hsba()
hsl()/hsla()
hwb()
rgb()/rgba()
RGB-Hex 3/4/6/8 digits
CSS Named Color
device-cmyk()
gray()

See document: https://github.com/anseki/vscode-color

Hi. Thanks for the reply.
Yes, the output notations types are very useful however I would really like the ability to change the selected color using the slider to control the amount of Lightness (instead of Brightness) as an option or a switch (even better).
It's different from HS(B) / HS (V) and is super useful for selecting shades of a color which complement the existing or previous ones.
More info on this is here and also Steve Schoger the UI expert talks about HSL vs HSB a lot. Also Sketch App has also enabled HSL in their color picker.

That feature requires big changing for UI, then I will examine that when more requests come.
Thank you again for your comment. :smile:
If you want to adjust the lightness now, use the Lab or change the output text as the HSL. (But these have no slider. I know, you want visual UI.)

I close this issue for now.
I will examine this feature when more requests come. I still welcome comments.


Added colons to the rest of the media info in media page

Description or Fixes hummingbird-me/hummingbird#[replace brackets with the issue number that your pull request addresses].
Changes proposed in this pull request:
[list out summary of changes here]
[etc]
/cc @hummingbird-me/staff

Yeah I guess. Original design didn't have em.


ENH: daemon mode

Is your feature request related to a problem? Please describe
Start xinference as a background service.

+1


feat(554): supporting exists feature in rules

#554

I've noticed that the github action "build/jest" is always checking out master. Therefore the added tests for rules exists are not taken please in the "pipeline". It might be confusing since every action is green and might suggest a working test testsetup.

@alexander-matthiesen
Can you spot my mistake in .github/workflows?

I've tried a bit but unfortunately I haven't that much experience with github workflows. I'm more of an expert with GitLab CI/CD (thats also why I'm here. :D
I will have a look. Maybe it is working better now when I can create a branch in this repo here instead of having a fork.

Hehe, me too 😁I'll read up, and try some things, then you can pull master and see if that helps 🤟

Actually I will close this PR and create a new one based on a branch in this repository.
I really don't like the "forking" stuff.
Follow up PR will come asap.


Cache the servers on Minehut

Increases display speed of options when using /server.
Depends on #4

I personally think for the use case we have here where we need semi-accurate data just polling every 30 seconds would be better so if nobody has recently done the command the data wont be weird.
I don't think it matters too much which approach is taken here but the suggestions will definitely be more inaccurate for users who use the command after periods of inactivity.

How so? It would be something like this flow:
Person runs /server:
-> if cache is over 30s or not set yet:
-> cache current servers online
-> use the cache for the autocomplete

Yeah, that's why I think it's ok whichever approach is taken, just having the most up to date data every 30 seconds without user input seems a tad bit nicer but it's honestly probably fine.
LGTM.

Sorry for the delay, thought I've already merged this; lgtm 👌🏻


[CT-1171] Blueprint json artifacts to persist contracts' state and unify manifests and catalogs across projects

Success Criteria:

Links to existing files in dbt-core that need to be updated
Net new files in dbt-core and why it needs new files
Potential "gotcha" implementations based on the above(think: if we update this file here, we have to update 100 files downstream)
pseudo-code snippets on initial approach for the above to make this functionality work

"nodes": {
        "model.upstream_project.my_first_dbt_model": {
            "resource_type": "model",
            "has_downstream_dependencies": true,
            ...
        },
        "model.downstream_project.my_second_dbt_model": {
            "resource_type": "model",
            "depends_on": {
                "macros": [],
                "nodes": ["model.upstream_project.my_first_dbt_model"]
            },

https://github.com/dbt-labs/dbt-core/blob/main/core/dbt/contracts/graph/manifest.py
https://github.com/dbt-labs/dbt-core/blob/main/core/dbt/parser/manifest.py

Envisioned process:

contract configs set in the dbt_project.yml, schema.yml or model.sql files.
As part of project parsing in an upstream project, dbt identifies when there are node contracts in place and if so, generates a contracts.json which is written to /target.

Great update!
I'm going to use your example json outputs as sketches for the json my contract yml configs will output!

@matt-winkler I used your json schemas as a starting point and built this template: https://github.com/dbt-labs/dbt-core/blob/120e4d3edceaa5bed9180546140e4a49a9aa44c5/tests/functional/dbt_contracts/contracts.json
contracts.json will consolidate a subset of the manifest.json, catalog.json, run_results.json, sources.json files and then merge that with the consumer's manifest.json, catalog.json(run_results.json, sources.json files are for validating contract requirements only)
Pros:

A single file that consolidates the relevant details
Removes the need to point to a project directory and/or git repo url as the contracts.json contains all the relevant metadata, code, results

Cons:

This file can easily become overloaded and gigantic
Still need to figure out how to merge elegantly with a downstream(consumer) project's manifest.json, catalog.json, but that will happen regardless of the approach


[HOLD for payment 2024-10-25] [$250] Android - IOS - It flickers when I open the manual submit expense twice or more

If you haven’t already, check out our contributing guidelines for onboarding and email<EMAIL_ADDRESS>to request to join our Slack channel!

Version Number: 9.0.43-1
Reproducible in staging?: Y
Reproducible in production?: Y
Issue was found when executing this PR: https://github.com/Expensify/App/pull/49007
Issue reported by: Applause Internal Team
Action Performed:

Open the app
Log in with a Gmail account
Navigate to FAB - Submit expense - Manual
Navigate back to the LHN
Navigate to FAB - Submit expense

Expected Result:
It shouldn't flicker.
Actual Result:
It flickers when I open the manual submit expense twice or more.
Workaround:
Unknown
Platforms:

[x] Android: Native
[ ] Android: mWeb Chrome
[ ] iOS: Native
[ ] iOS: mWeb Safari
[ ] MacOS: Chrome / Safari
[ ] MacOS: Desktop

Screenshots/Videos
https://github.com/user-attachments/assets/2013e452-083e-49a4-bdd1-48d8c3e77a1c

View all open jobs on GitHub
Upwork Automation - Do Not Edit

Upwork Job URL: https://www.upwork.com/jobs/~021843392417403890622
Upwork Job ID:<PHONE_NUMBER>403890622
Last Price Increase: 2024-10-14
Automatic offers:

rayane-djouah | Reviewer | 104420246

Issue OwnerCurrent Issue Owner: @slafortune

We think that this bug might be related to #wave-collect - Release 1

@slafortune  FYI I haven't added the External label as I wasn't 100% sure about this issue. Please take a look and add the label if you agree it's a bug and can be handled by external contributors

Proposal
Please re-state the problem that we are trying to solve in this issue.

It flickers when I open the manual submit expense twice or more.

What is the root cause of that problem?

In IOURequestStartPage, we display the loading indicator if the transaction data is not available:

https://github.com/Expensify/App/blob/e02df29fc8ff05da2a242775fe972cf2bc5b817a/src/pages/iou/request/IOURequestStartPage.tsx#L101

If the transaction data is loaded successfully, we display the tab navigator:

https://github.com/Expensify/App/blob/e02df29fc8ff05da2a242775fe972cf2bc5b817a/src/pages/iou/request/IOURequestStartPage.tsx#L137

In the tab navigator, we also have logic that will return null if the selectedTab data is loading:

https://github.com/Expensify/App/blob/e02df29fc8ff05da2a242775fe972cf2bc5b817a/src/libs/Navigation/OnyxTabNavigator.tsx#L106-L108

That leads to is flicker effect. The order of displayed components: FullScreenLoadingIndicator > Navigator with 3 tab (Manual | Scan | Distance) > null > Navigator with 3 tab (Manual | Scan | Distance).

What changes do you think we should make in order to solve the problem?

We should display the loading indicator instead of just returning null in:

https://github.com/Expensify/App/blob/e02df29fc8ff05da2a242775fe972cf2bc5b817a/src/libs/Navigation/OnyxTabNavigator.tsx#L106-L108
Now, the flicker effect still appears. The order of displayed components: FullScreenLoadingIndicator > Navigator with 3 tab (Manual | Scan | Distance) > FullScreenLoadingIndicator > Navigator with 3 tab (Manual | Scan | Distance).

We should change the order to: FullScreenLoadingIndicator > Navigator with 3 tab (Manual | Scan | Distance). To do it, we need to remove:

https://github.com/Expensify/App/blob/e02df29fc8ff05da2a242775fe972cf2bc5b817a/src/pages/iou/request/IOURequestStartPage.tsx#L98-L102
and pass isLoading={!transaction?.transactionID} when using OnyxTabNavigator here.

In OnyxTabNavigator, update:

https://github.com/Expensify/App/blob/e02df29fc8ff05da2a242775fe972cf2bc5b817a/src/libs/Navigation/OnyxTabNavigator.tsx#L106-L108
    if (isLoadingOnyxValue(selectedTabResult) || isLoading) {
        return <FullScreenLoadingIndicator />;
    }

Beside the above main change, we need to make sure the changes do not break the rest logic in IOURequestStartPage:

https://github.com/Expensify/App/blob/e02df29fc8ff05da2a242775fe972cf2bc5b817a/src/pages/iou/request/IOURequestStartPage.tsx#L173-L181
What alternative solutions did you explore? (Optional)

Proposal
Please re-state the problem that we are trying to solve in this issue.
The submit expense page flickers when open it.
What is the root cause of that problem?
In submit expense page, we use an OnyxTabNavigator. Inside the component, we return null if the selectedTab onyx data is loading.
https://github.com/Expensify/App/blob/e61ee7fbe60acc12879b9d5cc6ef92c4a0b98caa/src/libs/Navigation/OnyxTabNavigator.tsx#L106-L108
If we already previously loaded the data before, then the tab navigator will be shown immediately. But the navigator has a state listener which is triggered on mount which updates the selectedTab onyx with the same value.
https://github.com/Expensify/App/blob/e61ee7fbe60acc12879b9d5cc6ef92c4a0b98caa/src/libs/Navigation/OnyxTabNavigator.tsx#L120-L126
It will make the status becomes loading again because now we have a pending merge.
https://github.com/Expensify/react-native-onyx/blob/22b2717e4b6a21b444efe59048ead7cb795b8671/lib/useOnyx.ts#L177-L179
loaded -> loading -> loaded
What changes do you think we should make in order to solve the problem?

Don't update the onyx if the selected tab is the same.
const newSelectedTab = routeNames.at(index);
if (selectedTab !== newSelectedTab) {
    Tab.setSelectedTab(id, newSelectedTab as SelectedTabRequest);
    onTabSelected(newSelectedTab as IOURequestType);
}

Yep - tested and get the same results 👍

PR is ready
cc: @rayane-djouah

LGTM

Are we still waiting for payment here?

Yes.

Payment is due today -

@bernhardoj Role Contributor -  requires payment through NewDot Manual Requests - Due $250
@rayane-djouah Role C+ requires payment via Upworks - Paid $250

Requested in ND.


Add success and failure count OTel metrics for async shard fetch

Description
This change adds failure count and success count OTel metrics for async shard fetch
Related Issues
Resolves #[Issue number to be closed when this PR is merged]

Check List

[x] Functionality includes testing.
[x] API changes companion pull request created, if applicable.
[x] Public documentation issue/PR created, if applicable.

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

❌ Gradle check result for cfb40f1: FAILURE
Please examine the workflow log, locate, and copy-paste the failure(s) below, then iterate to green. Is the failure a flaky test unrelated to your change?

failing tests:
org.opensearch.index.ShardIndexingPressureSettingsIT.testShardIndexingPressureEnforcedEnabledDisabledSetting
org.opensearch.index.ShardIndexingPressureSettingsIT.classMethod
org.opensearch.indices.settings.SearchOnlyReplicaIT.testFailoverWithSearchReplica_WithoutWriterReplicas
org.opensearch.snapshots.DedicatedClusterSnapshotRestoreIT.testSnapshotWithStuckNode
#14331 - ShardIndexingPressureSettingsIT
#15812 - SearchOnlyReplicaIT
#15806 - DedicatedClusterSnapshotRestoreIT
verified these 4 tests have showed up in flaky test report

Thanks @rahulkarajgikar ! can you please run the tests in loop as you have added bunch of assertions in multiple tests in AsyncShardFetchTests.java

Sure, I have run the entire test class 5000 times and validated that there were no failures

raised manual backport: https://github.com/opensearch-project/OpenSearch/pull/16130/files