Port timeout after accessing port that has been reset

Hi,
I am having issues when developing with either Node or Django and running their respective development servers on localhost, not sure if it is repeatable with the Rails dev server, but I imagine so. When you start the development server for the first time on a particular port and try and ping that port, everything works as expected. However, when you restart the service (because of source code changes, etc) pinging the port now times out. To reproduce on fresh install:
sudo apt-get install python-django
django-admin startproject my-test-project
cd my-test-project
python manage.py runserver
Everything boots fine, starts server on localhost:8000
Use a web browser to navigate to localhost:8000 to confirm welcome screen
Use CTL-C to kill the server
python manage.py runserver
Server successfully reboots
Use the same web browser, hit refresh, the app just hangs. The same thing happens when trying to curl localhost:8000
Doing the same thing with Node.js produces the same result. If you manually change the port to something else, ie, 8001, it works just fine, until you restart the server again.
Using:
Edition: Windows 10 Pro Insider Preview
Version: 1607
OS Build: 14986.1001
Thanks!!

@pfugate - Thanks for the post and thanks for using WSL. I could not reproduce this on 14986 by following the same steps as you have outlined above (see the screenshot below with the highlighted). The second (and subsequent) launch of the server were fine and I was able to connect to them using the browser (you can also see that in the screenshot, where the GET requests are logged with their timestamp). If you are running any Anti-Virus software (including Windows defender), can you try disabling them to see if there is any difference?

Hi Sunil. Thanks for getting back to me. I've disabled all securing on my system and it still won't work. What I am also wondering is why it works the first time I start the server, but does not work after restart? Also, why does it work if I change the port it is accessing (at least the first time)? The port also becomes reachable if I close the bash session, and then start a new one. Thanks again for all your help.
Best,
Phil
(P.S. I did not use sudo in my previous example because these are non privileged ports, but I tried with sudo and still no luck)

It works the first time because it should. One reason why it would not work the second or subsequent time is because when you close the server the first time, the socket bound to the port is not getting closed (for some reason). And, we are trying to find that reason here. Can you try few things?

Start the server the first time (after fresh start of bash), connect to the server using the web browser to make sure everything works.
Without closing the server, open a new admin Windows CMD prompt and do netstat -a | find "8000" and dump the output. You should see a TCP connection in "listening" state.
Now close the server and repeat (2). There should not be anyone listening on port 8000.
Start the server again and repeat (2). You should once again see someone listening on port 8000.

Can you share the output of (2), (3) and (4) above?
Also, I know you have stated it above, but can you confirm (one more time) that your Windows version is 14986?

So, really odd behavior. I tried the socket in a new session and it behaved as it did previously. Then I started a new session and did the netstat test and it worked?! I have no idea how or why, but it did. I've even tried it with node and it also works. No idea what changed, but thanks!! Maybe netstat caused a refresh of the windows network stack?

If you notice this one has only one connection and it is not TIME_WAIT

I take it back. So I left a connection open for about an hour, then closed and restarted it, and it did not work. I ran netstat again and noticed that there were two open connections. I closed the one open connection and ran netstat again and both connections were still there. I then restarted the server and ran netstat and saw 3 open connections. See screen shot below. This is a really odd problem.

Are you suspending or killing the processes? You can also do a ps -all in bash to see all the processes? Suspended process will not release their resources. The other difference I see between your previous screenshot and the new ones is that earlier they were listening on <IP_ADDRESS>, in the latest it is <IP_ADDRESS>. What changed?

Hi, sorry for the delay, work got in the way. Much to my embarrassment I was using CTL-Z or CTL-X to end the server. This, as you know does not kill the process. Then, when trying to restart the process, there is one suspended and one new, both on the same port, but pinging the port tries to access the suspended process.
Under a normal Linux/MacOS/Unix env, this process works just fine, as the new process is able to supplant the old one, but this is not the case with WSL. Is this the desired outcome?
Thanks!

@pfugate -- do you have a specific updated example where this works for you using CTL-Z or CTL-X on Mac or Linux?
On my Mac (and, I would expect, on Linux as well), if I open up one terminal and do:
$ python -m SimpleHTTPServer
Serving HTTP on <IP_ADDRESS> port 8000 ...
^Z
[1]+  Stopped

and then I open a second terminal and try to open a replacement process, I get:
$ python -m SimpleHTTPServer
Traceback (most recent call last):
  File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/runpy.py", line 162, in _run_module_as_main
    "__main__", fname, loader, pkg_name)
  File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/runpy.py", line 72, in _run_code
    exec code in run_globals
  File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/SimpleHTTPServer.py", line 235, in <module>
    test()
  File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/SimpleHTTPServer.py", line 231, in test
    BaseHTTPServer.test(HandlerClass, ServerClass)
  File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/BaseHTTPServer.py", line 595, in test
    httpd = ServerClass(server_address, HandlerClass)
  File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/SocketServer.py", line 420, in __init__
    self.server_bind()
  File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/BaseHTTPServer.py", line 108, in server_bind
    SocketServer.TCPServer.server_bind(self)
  File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/SocketServer.py", line 434, in server_bind
    self.socket.bind(self.server_address)
  File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/socket.py", line 228, in meth
    return getattr(self._sock,name)(*args)
socket.error: [Errno 48] Address already in use

Thanks @aseering
@pfugate - Are you seeing any discrepancy of behavior between WSL and native Linux? If not, we would like to close the issue out.

This is super embarrassing, but yea, it was my bad using CTL-Z. I'm not sure why I've never noticed this before on other systems. Anyway, thanks for all the help.


Multi cross section routing

Adds basic multilayer electrical routing to most routing functions

Use via_corner instead of wire_corner for bend function
Use MultiCrossSectionAngleSpec instead of CrossSectionSpec to define multiple cross sections
Avoids refactoring as much as possible so it doesn't interfere with current single-layer routing

Nice, thank you Thomas


Getting zlib error when trying to connect to code server 3.9.2 with the browser

OS/Web Information

Web Browser: Chrome Version 89.0.4389.90 (Official Build) (32-bit)
Local OS: Windows Server 2016 Datacenter
Remote OS: Ubuntu 18.04.5
Remote Architecture: Amazon EC2
code-server --version: v3.9.2

config.yaml:
Steps to Reproduce

systemctl --user start code-server
log into it from browser
journalctl:
bind-addr: <IP_ADDRESS>:9001
auth: none
cert: /usr/lib/code-server/cert.pem
cert-key: /usr/lib/code-server/key.pem

Expected
journalctl:
Apr 01 15:16:16 ip-10-114-44-7 systemd[11951]: Started code-server.
Apr 01 15:16:18 ip-10-114-44-7 code-server[13218]: [2021-04-01T15:16:18.691Z] info  code-server 3.8.1 41ad0c0c4c14df78e1bfa3a44d8b633ed2fc26e5
Apr 01 15:16:18 ip-10-114-44-7 code-server[13218]: [2021-04-01T15:16:18.694Z] info  Using user-data-dir ~/.local/share/code-server
Apr 01 15:16:18 ip-10-114-44-7 code-server[13218]: [2021-04-01T15:16:18.734Z] info  Using config file ~/.config/code-server/config.yaml
Apr 01 15:16:18 ip-10-114-44-7 code-server[13218]: [2021-04-01T15:16:18.734Z] info  HTTP server listening on http://<IP_ADDRESS>:9001
Apr 01 15:16:18 ip-10-114-44-7 code-server[13218]: [2021-04-01T15:16:18.734Z] info    - Authentication is disabled
Apr 01 15:16:18 ip-10-114-44-7 code-server[13218]: [2021-04-01T15:16:18.734Z] info    - Using certificate for HTTPS: /usr/lib/code-server/cert.pem
Actual
journalctl:
Mar 31 21:12:22 ip-10-114-44-7 systemd[8572]: Started code-server.
Mar 31 21:12:23 ip-10-114-44-7 code-server[26055]: [2021-03-31T21:12:23.935Z] info  code-server 3.9.2 109d2ce3247869eaeab67aa7e5423503ec9eb859
Mar 31 21:12:23 ip-10-114-44-7 code-server[26055]: [2021-03-31T21:12:23.937Z] info  Using user-data-dir ~/.local/share/code-server
Mar 31 21:12:23 ip-10-114-44-7 code-server[26055]: [2021-03-31T21:12:23.970Z] info  Using config file ~/.config/code-server/config.yaml
Mar 31 21:12:23 ip-10-114-44-7 code-server[26055]: [2021-03-31T21:12:23.970Z] info  HTTP server listening on http://<IP_ADDRESS>:9001
Mar 31 21:12:23 ip-10-114-44-7 code-server[26055]: [2021-03-31T21:12:23.970Z] info    - Authentication is disabled
Mar 31 21:12:23 ip-10-114-44-7 code-server[26055]: [2021-03-31T21:12:23.970Z] info    - Using certificate for HTTPS: /usr/lib/code-server/cert.pem
Mar 31 21:13:08 ip-10-114-44-7 code-server[26055]: Error: invalid distance too far back
Mar 31 21:13:08 ip-10-114-44-7 code-server[26055]:     at Zlib.zlibOnError [as onerror] (zlib.js:180:17) {
Mar 31 21:13:08 ip-10-114-44-7 code-server[26055]:   errno: -3,
Mar 31 21:13:08 ip-10-114-44-7 code-server[26055]:   code: 'Z_DATA_ERROR'
Mar 31 21:13:08 ip-10-114-44-7 code-server[26055]: }
Mar 31 21:13:08 ip-10-114-44-7 code-server[26055]: [2021-03-31T21:13:08.418Z] warn  vscode invalid distance too far back
Mar 31 21:13:18 ip-10-114-44-7 code-server[26055]: [2021-03-31T21:13:18.326Z] error vscode Handshake timed out {"token":"7310faa7-c169-4ed7-9f78-73d1af8bbedf"}
Notes

This issue can be reproduced in VS Code: No

In the browser, it hangs, then says that it cannot reconnect.

I have the same issues on a Raspberry Pi 4 with Debian using standard password authentication.

Same issues on Termux for Android

@gbruno16 are you able to post reproduction steps? Might help with debugging as I have an Android I can test on.

I followed exactly the steps in https://github.com/cdr/code-server/blob/main/docs/install.md#termux on a fresh installation of Termux 0.108.
My device is a Huawei Matepad 10.4 (Android 10). Code server starts but after some seconds it disconnects and gives the same error reported above

Okay, thanks for the notes! Can you try running with code-server --log debug and posting the logs here?

I hope this is what you asked for:
[2021-04-03T09:27:04.844Z] info  code-server 3.9.2 109d2ce3247869eaeab67aa7e5423503ec9eb859
[2021-04-03T09:27:04.846Z] info  Using user-data-dir ~/.local/share/code-server
[2021-04-03T09:27:04.872Z] info  Using config file ~/.config/code-server/config.yaml
[2021-04-03T09:27:04.872Z] info  HTTP server listening on http://<IP_ADDRESS>:8080
[2021-04-03T09:27:04.872Z] info    - Authentication is enabled
[2021-04-03T09:27:04.872Z] info      - Using password from ~/.config/code-server/config.yaml
[2021-04-03T09:27:04.872Z] info    - Not serving HTTPS
Error: invalid distance too far back
at Zlib.zlibOnError [as onerror] (zlib.js:182:17) {
errno: -3,
code: 'Z_DATA_ERROR'
}
[2021-04-03T09:27:12.510Z] warn  vscode invalid distance too far back
Error: invalid distance too far back
at Zlib.zlibOnError [as onerror] (zlib.js:182:17) {
errno: -3,
code: 'Z_DATA_ERROR'
}
[2021-04-03T09:27:21.239Z] warn  vscode invalid distance too far back
[2021-04-03T09:27:22.481Z] error vscode Handshake timed out {"token":"6f236eec-8108-4bc6-a4b9-f16930416b93"}
Error: invalid distance too far back
at Zlib.zlibOnError [as onerror] (zlib.js:182:17) {
errno: -3,
code: 'Z_DATA_ERROR'
}
[2021-04-03T09:27:26.265Z] warn  vscode invalid distance too far back
[2021-04-03T09:27:31.212Z] error vscode Handshake timed out {"token":"bda65549-df28-488d-9e7a-7891255812d9"}
ERR /data/data/com.termux/files/home/.local/share/code-server/extensions [Error: ENOENT: no such file or directory, scandir '/data/data/com.termux/files/home/.local/share/code-server/extensions'] {
errno: -2,
code: 'ENOENT',
syscall: 'scandir',
path: '/data/data/com.termux/files/home/.local/share/code-server/extensions'
}
Error: invalid distance too far back
at Zlib.zlibOnError [as onerror] (zlib.js:182:17) {
errno: -3,
code: 'Z_DATA_ERROR'
}
[2021-04-03T09:27:33.999Z] warn  vscode invalid distance too far back
[2021-04-03T09:27:36.072Z] error vscode Handshake timed out {"token":"c57e8aab-c55d-4194-ac89-ce4c618cad4b"}
[2021-04-03T09:27:43.652Z] error vscode Handshake timed out {"token":"2dafe5e3-5051-43b2-b015-119531d1c85d"}
ERR /data/data/com.termux/files/home/.local/share/code-server/extensions [Error: ENOENT: no such file or directory, scandir '/data/data/com.termux/files/home/.local/share/code-server/extensions'] {
errno: -2,
code: 'ENOENT',
syscall: 'scandir',
path: '/data/data/com.termux/files/home/.local/share/code-server/extensions'
}

Perfect! Exactly what we needed. I've seen this same issue so you're not alone. Thanks for posting the logs! We'll look into this.

Same problem here.
local device: raspberry Pi 3
remote device 1: Ipad (ipadOs 14.4.2)
Browsers that i used to test: Brave (Version 1.23.1 (<IP_ADDRESS>)), Safari, Chrome
code-server version: 3.9.2

Hi can you try upgrade to 3.9.3 and letting us know if you're still experiencing the same issue?
Feel free to post in the release discussion as well.

The issue is resolved after the update, at least for me. 👍

I updated, and received these errors in journalctl:
Apr 09 16:59:08 ip-10-114-44-7 systemd[10796]: Started code-server.
Apr 09 16:59:09 ip-10-114-44-7 code-server[30652]: [2021-04-09T16:59:09.769Z] info  code-server 3.9.3 fe2dc2deb08e378069891b622bb62ad1d261d1b1
Apr 09 16:59:09 ip-10-114-44-7 code-server[30652]: [2021-04-09T16:59:09.772Z] info  Using user-data-dir ~/.local/share/code-server
Apr 09 16:59:09 ip-10-114-44-7 code-server[30652]: [2021-04-09T16:59:09.838Z] info  Using config file ~/.config/code-server/config.yaml
Apr 09 16:59:09 ip-10-114-44-7 code-server[30652]: [2021-04-09T16:59:09.838Z] info  HTTP server listening on http://<IP_ADDRESS>:9001
Apr 09 16:59:09 ip-10-114-44-7 code-server[30652]: [2021-04-09T16:59:09.838Z] info    - Authentication is disabled
Apr 09 16:59:09 ip-10-114-44-7 code-server[30652]: [2021-04-09T16:59:09.838Z] info    - Using certificate for HTTPS: /usr/lib/code-server/cert.pem
Apr 09 16:59:16 ip-10-114-44-7 code-server[30652]: [2021-04-09T16:59:16.647Z] error vscode is not running Error: vscode is not running
Apr 09 16:59:16 ip-10-114-44-7 code-server[30652]:     at VscodeProvider.send (/usr/lib/code-server/out/node/vscode.js:206:19)
Apr 09 16:59:16 ip-10-114-44-7 code-server[30652]:     at VscodeProvider. (/usr/lib/code-server/out/node/vscode.js:198:30)
Apr 09 16:59:16 ip-10-114-44-7 code-server[30652]:     at step (/usr/lib/code-server/out/node/vscode.js:63:23)
Apr 09 16:59:16 ip-10-114-44-7 code-server[30652]:     at Object.next (/usr/lib/code-server/out/node/vscode.js:44:53)
Apr 09 16:59:16 ip-10-114-44-7 code-server[30652]:     at fulfilled (/usr/lib/code-server/out/node/vscode.js:35:58)
Apr 09 16:59:16 ip-10-114-44-7 code-server[30652]:     at processTicksAndRejections (internal/process/task_queues.js:97:5)
Apr 09 16:59:16 ip-10-114-44-7 code-server[30652]: [2021-04-09T16:59:16.742Z] error vscode is not running Error: vscode is not running
Apr 09 16:59:16 ip-10-114-44-7 code-server[30652]:     at VscodeProvider.send (/usr/lib/code-server/out/node/vscode.js:206:19)
Apr 09 16:59:16 ip-10-114-44-7 code-server[30652]:     at VscodeProvider. (/usr/lib/code-server/out/node/vscode.js:198:30)
Apr 09 16:59:16 ip-10-114-44-7 code-server[30652]:     at step (/usr/lib/code-server/out/node/vscode.js:63:23)
Apr 09 16:59:16 ip-10-114-44-7 code-server[30652]:     at Object.next (/usr/lib/code-server/out/node/vscode.js:44:53)
Apr 09 16:59:16 ip-10-114-44-7 code-server[30652]:     at fulfilled (/usr/lib/code-server/out/node/vscode.js:35:58)
Apr 09 16:59:16 ip-10-114-44-7 code-server[30652]:     at processTicksAndRejections (internal/process/task_queues.js:97:5)
Apr 09 16:59:25 ip-10-114-44-7 code-server[30652]: [2021-04-09T16:59:25.628Z] warn  vscode Version mismatch (41ad0c0c4c14df78e1bfa3a44d8b633ed2fc26e5 instead of fe2dc2deb08e378069891b622bb62ad1d261d1b1)
Apr 09 16:59:26 ip-10-114-44-7 code-server[30652]: Error: invalid distance too far back
Apr 09 16:59:26 ip-10-114-44-7 code-server[30652]:     at Zlib.zlibOnError [as onerror] (zlib.js:182:17) {
Apr 09 16:59:26 ip-10-114-44-7 code-server[30652]:   errno: -3,
Apr 09 16:59:26 ip-10-114-44-7 code-server[30652]:   code: 'Z_DATA_ERROR'
Apr 09 16:59:26 ip-10-114-44-7 code-server[30652]: }
Apr 09 16:59:26 ip-10-114-44-7 code-server[30652]: [2021-04-09T16:59:26.017Z] warn  vscode invalid distance too far back
Apr 09 16:59:30 ip-10-114-44-7 code-server[30652]: [2021-04-09T16:59:30.711Z] warn  vscode Version mismatch (41ad0c0c4c14df78e1bfa3a44d8b633ed2fc26e5 instead of fe2dc2deb08e378069891b622bb62ad1d261d1b1)
Apr 09 16:59:31 ip-10-114-44-7 code-server[30652]: [2021-04-09T16:59:31.609Z] warn  vscode Version mismatch (41ad0c0c4c14df78e1bfa3a44d8b633ed2fc26e5 instead of fe2dc2deb08e378069891b622bb62ad1d261d1b1)
Apr 09 16:59:35 ip-10-114-44-7 code-server[30652]: [2021-04-09T16:59:35.992Z] error vscode Handshake timed out {"token":"9eb85fc6-f60b-47b5-973d-afb81ea6ae0d"}
So I updated vscode to 1.55.1-1617808414
Now I'm seeing these same errors:
Apr 09 17:04:49 ip-10-114-44-7 systemd[10796]: Started code-server.
Apr 09 17:04:50 ip-10-114-44-7 code-server[31198]: [2021-04-09T17:04:50.519Z] info  code-server 3.9.3 fe2dc2deb08e378069891b622bb62ad1d261d1b1
Apr 09 17:04:50 ip-10-114-44-7 code-server[31198]: [2021-04-09T17:04:50.522Z] info  Using user-data-dir ~/.local/share/code-server
Apr 09 17:04:50 ip-10-114-44-7 code-server[31198]: [2021-04-09T17:04:50.554Z] info  Using config file ~/.config/code-server/config.yaml
Apr 09 17:04:50 ip-10-114-44-7 code-server[31198]: [2021-04-09T17:04:50.554Z] info  HTTP server listening on http://<IP_ADDRESS>:9001
Apr 09 17:04:50 ip-10-114-44-7 code-server[31198]: [2021-04-09T17:04:50.554Z] info    - Authentication is disabled
Apr 09 17:04:50 ip-10-114-44-7 code-server[31198]: [2021-04-09T17:04:50.554Z] info    - Using certificate for HTTPS: /usr/lib/code-server/cert.pem
Apr 09 17:05:07 ip-10-114-44-7 code-server[31198]: Error: invalid distance too far back
Apr 09 17:05:07 ip-10-114-44-7 code-server[31198]:     at Zlib.zlibOnError [as onerror] (zlib.js:182:17) {
Apr 09 17:05:07 ip-10-114-44-7 code-server[31198]:   errno: -3,
Apr 09 17:05:07 ip-10-114-44-7 code-server[31198]:   code: 'Z_DATA_ERROR'
Apr 09 17:05:07 ip-10-114-44-7 code-server[31198]: }
Apr 09 17:05:07 ip-10-114-44-7 code-server[31198]: [2021-04-09T17:05:07.305Z] warn  vscode invalid distance too far back
Apr 09 17:05:17 ip-10-114-44-7 code-server[31198]: [2021-04-09T17:05:17.295Z] error vscode Handshake timed out {"token":"9866a080-0504-4e2e-a8c9-aa67b80da9d6"}

Interesting! Thanks for confirming @lovetodream
Thanks for the logs @sweet-mentat - we'll have to dig into this a bit more.

I'm getting the same issue,
4월 25 16:40:32 localhost.localdomain code-server[22661]: }
4월 25 16:40:32 localhost.localdomain code-server[22661]: [2021-04-25T07:40:32.905Z] warn  vscode invalid distance too far back
4월 25 16:40:37 localhost.localdomain code-server[22661]: Error: invalid distance too far back
4월 25 16:40:37 localhost.localdomain code-server[22661]: at Zlib.zlibOnError [as onerror] (zlib.js:182:17) {
4월 25 16:40:37 localhost.localdomain code-server[22661]: errno: -3,
4월 25 16:40:37 localhost.localdomain code-server[22661]: code: 'Z_DATA_ERROR'
4월 25 16:40:37 localhost.localdomain code-server[22661]: }
4월 25 16:40:37 localhost.localdomain code-server[22661]: [2021-04-25T07:40:37.081Z] warn  vscode invalid distance too far back
4월 25 16:40:42 localhost.localdomain code-server[22661]: [2021-04-25T07:40:42.873Z] error vscode Handshake timed out {"token":"5bdfbd05-25d1-4393-b17d-a9bfa576d4c0"}
4월 25 16:40:46 localhost.localdomain code-server[22661]: [2021-04-25T07:40:46.988Z] error vscode Handshake timed out {"token":"1fc5665a-a7f0-4f78-ad1a-37d5f7528314"}
I'm using SBC, Udoo X86 advanced with additional SSD, just on eMMC.
CentOS for OS.
I'm suspecting on I/O...

  While it’s currently disabled, zlib compression does appear to work in local testing if the configuration is negotiated by the client.

That's awesome to hear!


Edit LoadBalancer should show the listener ports.

Build from master:
Steps to reproduce the problem:
Create a LB service and activate it.
Edit this LB service.
It does not include information about the listener ports.
Expected Behavior:
Edit LoadBalancer should show the listener ports.

Verified v0.30.0-rc4


How can I do a FormBuilderField that returns a Map<String,dynamic>?

Hi, I need to do something like this, where _formkey has a metadata which is Map<String,dynamic>, any idea how can i do it?
{
"id": 0,
"description": "string",
"logo": "string",
"name": "string",
"company_id": "3fa85f64-5717-4562-b3fc-2c963f66afa6",
"subscription_id": "3fa85f64-5717-4562-b3fc-2c963f66afa6"
"metadata": {"option1": "", "option2": ""}
}

_formKey.currentState.values or something like this don't help you?
Take a look on all formKey properties

Yes i know @deandreamatias ,but my question is how do I make "metadata" of type Map<String,dynamic>, inside the formKey.currentState.values?


Separate essential requirements and non-essential ones

Some of these requirements we have are only needed for things like Whisper or optical flow... its too much

I think we could make extra deps for different subsamplers so that we don't need to install deps for most subsamplers by default
using "extra" feature of pypi

A docker image of video2dataset is easily almost 7 gigabytes, and I suspect lot of it is pretty unnecessary for most use cases.


[Enhancement] Add Connector-ClickHouse related modules

Search before asking

[X] I had searched in the issues and found no similar issues.

Enhancement Request
Complete Connector-ClickHouse related modules.
Describe the solution you'd like
Task list:

[ ] add sink-connector-clickhouse module
[ ] add source-connector-clickhouse module

Are you willing to submit PR?

[X] Yes I am willing to submit a PR!

I will try to implement this part，please assign to me

Hello @qqeasonchen , recently I've been swamped with work and can't continue with this issue. Could you please assign it to @epiao55 ? I'll keep an eye on the latest developments in our community. Thank you.

@koonchen Never mind😊


[DO NOT MERGE] SITL tests multi-EKF lockstep debugging

This seems to be working as well as master now. The issues is the lockstep registration moving to the ekf2 selector. The ekf2 selector is schedule on ekf2 attitude (estimator_attitude) and estimator_status publications. When starting up there's a brief window where we don't get a publication for every single IMU message (each step). By holding off on the ekf2 selector lockstep registration until the first attitude publication we can bypass the problem for now.


Fix known issue with Any, Any resolution

The following expressions:
define Test1: null ~ null
define Test2: null = null

result in an error about ambiguous resolution. This is because the generic resolution that would have enabled these is disabled (see #420) because once a binary operator signature for Any, Any is instantiated, it ends up being used for all resolutions, even if a more appropriate specific resolution is available. The operator resolution needs to take this possibility into account so that this functionality can be reintroduced.

This is only relevant when both sides are literal null, right?  In other words, while this might come up in test cases, you should never see production CQL that does a comparison between two literal nulls -- so it's really only a problem for tests cases like the one above, right?

Yes, it's an edge case for sure, but there are also places where it will manifest if you only have a compile-time type of Any, where an =(Any, Any) should be allowed but the translator can't resolve it.


add selected language restriction to tick for new project dialog

add the selected language restriction to the tick for new projects. Currently that will be "" | "python-only" | "javascript-only" | "no-blocks"

not currently; you want one on show?


[RFC] "Project bandWAgon" (Agones for wasmCloud)

The What
In short, this issue is here to address the question, "Can we provide an on-ramp for developing online multiplayer gaming backends for wasmCloud in a similar way that Agones provides a gaming server infrastructure?" More importantly, can we do so in a way that is easier, faster, and dare-we-say more fun than building against Agones?
The Why
We've built a couple experimental gaming backends so far: a very brittle distributed ECS, and a demo that stitched together disparate infrastructures but would not be good for a true realtime backend. The purpose isn't really to build a gaming backend service, the purpose is to determine if wasmCloud makes such a thing possible. This would be an eating our dogfood project. In short, if you can build an Agones competitor on wasmCloud (without the hosted infrastructure bit that GKE has), then wasmCloud is a success as a tool for platform builders and we've verified that wasmCloud can indeed scale and meet performance demands while also ensuring secure, rapid deployment.
Agones
The following is an incomplete list of some of the key features that Agones provides or enables:

A Game server SDK

Lifecycle management

A kubectl plugin to scale the game server fleet
A gateway that bridges a dozen or so client SDKs (including Unreal) to your backend game server fleet
Player Tracking (available as an in-memory cache as part of the SDK, e.g. realtime access w/out network query)
Ability to run a local game server (this actually looks pretty high-friction, still requires Kube and doesn't include managed Agones environment).
Latency testing services

In Agones the unit of deployment is a docker image with the Agones pre-requisites (e.g. the "sidecar" that bridges client SDKs to the backend server SDK)
References:

Agones tutorial - Build and Run a Simple GameServer in Rust

Implementation Options
There are a couple of different things we could do to build this, and should discuss the various options.
Agones Capability Provider
In this option, instead of building something that does what Agones does, we instead make it so that developers can deploy custom wasmCloud hosts into the Agones ecosystem by giving actors access to the Agones client SDK. This could "easily" by done by wrapping the Rust client SDK in a capability provider.
While this would certainly be faster and easier to build, what would we learn from doing so?
Full Project bandwAgon
The one thing that is beyond the realm of responsibility of wasmCloud is the launching of processes. Once you have a host process running and it's connected to a lattice, wasmCloud is responsible for anything that happens inside that process. Where Agones can let you use Kubernetes to spin up as many containers as you like, and wasmCloud will let you spin up as many actors as you like, we need to be aware of the fact that wasmCloud doesn't have a provision for starting new host processes.
I think the other important thing to keep in mind in a potential project like this is not to simply duplicate Agones functionality, but to take a look at the requirements that drove the development of Agones and see how we could solve those requirements and more using wasmCloud in a way that is optimized for wasmCloud's strengths - e.g. leveraging the small, portable actors and loosely coupled capability provider mechanism and the lattice connectivity to provide an easy way for people to build online gaming backends.
Deliverables
I think we would be successful if we either delivered an actual product / framework or if we delivered a set of architectural guidelines and instructions on how to build such a product, assuming we could back it up with enough proof that it would scale properly.

cc @brooksmtownsend

Updated the original comment to include the notion that we can either build an Agones alternative, or we can simply build a capability provider that talks to the Agones SDK, though there are obviously tradeoffs there and I'm not convinced we would learn anything from the latter.

It might be helpful to target an existing open game with a lot of active development. Veloren is a bit of a showcase you've probably read about if you read the weekly Rust news. It's built with amethyst.rs an ECS game engine.
https://veloren.net/
https://gitlab.com/veloren/veloren
https://amethyst.rs/

Without having spent much time reading up on Veloren, we should also classify the type of back-end we're looking to build (or support the building of). For example, Agones seems very specifically focused on the concept of spinning up dedicated monoliths (microliths?) that host a given set of players, likely as a result of some kind of out-of-band matchmaking process.
The other type of backend is the "traditional" MMO backend - each logical area within the game is represented by a cluster of servers, and then instanced areas within the game are spun up on demand for each group or raid party. One could probably make the argument that if you support the first type (spinning up on-demand servers designed to handle a given subset of a game universe), then you can create the second type by building on the first ... but I'm certainly open to hearing arguments that this is not the case.

I've been in or around a few teams trying to get away from those "instanced" paradigms and are shooting for the open world feeling again. That being said I agree you could focus on the "microlith" being an on demand spin up of the game mechanics for a certain region/ number of players. I've seen a good example for this type of auto scaling with the Aether Engine https://hadean.com/spatial-simulation/
https://youtu.be/U5fELaMK8Vw

Yeah that's conceptually the idea that a lot of different backends go with now. The microliths are spun up to handle some subset of the universe (whether it's a single all-encompassing universe or a single 4X live match with 3 players). I'm still on the fence about whether a distributed ECS to maintain a single, unified backend simulation is a good idea.

No one has the time for this.


[go_router] documentation cannot read

Is there an existing issue for this?

[X] I have searched the existing issues
[X] I have read the guide to filing a bug

Steps to reproduce
access https://pub.flutter-io.cn/documentation/go_router/latest/topics/Navigation-topic.html
https://pub.flutter-io.cn/documentation/go_router/latest/topics/Redirection-topic.html
https://pub.flutter-io.cn/documentation/go_router/latest/topics/Web-topic.html

Expected results

Actual results

Code sample
Code sample
[Paste your code here]

Screenshots or Video

Screenshots / Video demonstration
[Upload media here]

Logs
Logs
[Paste your logs here]

Flutter Doctor output
Doctor output
[Paste your output here]

Hi @gkdgo, this is not a go_router issue. You should report this on either the mirrored pub repo or the pub repo so that it can be looked at.
The site is responsible for the hosting of the documentation. The documentation on pub.dev itself works, so it's likely an issue with pub.flutter-io.cn.
Closing from here.
Thank you


build(deps):upgrade to @mapbox/node-pre-gyp

Seems odd that ci didn't run for this PR

@jmeis Do we need to configure GH actions to run for forks?

I was wondering if any tests would run.

Branch updated. Can you rebase?

https://github.com/IBM/generator-ibm-cloud-assets/pull/211
fixed here ^


⚠ dev-deces.matchid.io search API has degraded performance

In 72446f8, dev-deces.matchid.io search API (https://dev-deces.matchid.io/deces/api/v1/search?q=pompidou) experienced degraded performance:

HTTP code: 200
Response time: 5249 ms

Resolved: dev-deces.matchid.io search API performance has improved in fd452d0 after 11 minutes.


Use DispatcherTaskScheduler instead of TaskScheduler.FromCurrentSynchronizationContext

What does the pull request do?
Due to TaskScheduler.FromCurrentSynchronizationContext being unreliable on browser workloads, it's safer to explicitly provide dispatcher-based scheduler implementation.
Also, @kekekeks what exactly should be done to ensure correct dispatcher priority? I could read current sync context and check for AvaloniaSynchronizationContext.Priority, if that's what you meant.
Fixed issues
This issue was reported couple of times in telegram chats.

Can DispatcherTaskScheduler be made public, please? It's something I've wanted from time to time. The workaround today is to call TaskScheduler.FromCurrentSynchronizationContext from the UI thread and store the result somewhere.


fix loading customized mockingjay upstream model

Fix issue reported in #215
The problem is that example config in config_model.yaml doesn't show some options that are actually required when users wants to load their customized model. (Because this issue will not be triggered if model_config is set to None in mockingjay_local() and this won't happen unless users specify their own pretrained model config)
This work is just trying to set to default options if user does not specify these required options in their options section in config_model.yaml

Hey @andi611! I have a quick look and it seems good to me. But I think you are more familiar with this part, could you help confirm this PR?

Hi @leo19941227 @keylin1999,
Please see my reply here: https://github.com/s3prl/s3prl/issues/215#issuecomment-1098785276
Looks like the current argument name model_config is misleading.
@keylin1999 if you could revise this PR by restoring to the old version first,
then help rename model_config to options_config that would be great!
Thanks!

Hi @andi611 thanks for your advice and I've followed your advice changing the argument name. Is there anything still I can help?

Hi @andi611 thanks for your advice and I've followed your advice changing the argument name. Is there anything still I can help?

Great! Looks good~ I will merge it now.


Unable to build multi-platform images without also pushing them

Hello! Looks like when the --no-push parameter on devcontainer build was dropped it stopped being possible to build a multi-platform container without pushing it. The current code sets the behavior when you don't push to automatically add --load to the docker buildx build call, which is incompatible with manifest based Docker images (which multi-platform images must be).
I will cook up a PR to fix this.

@natescherer With buildx, you can specify multiple platforms to build in a single call. Are you looking to manually construct the manifest?

So what I'm trying to do is build multi-platform image support into https://github.com/devcontainers/ci. Currently that's set up with three stages, build, run an (optional) command inside the image, and then push. I was trying to maintain the same workflow for multi-container images. Current thinking is adding --output-type and --output-path options to the CLI that map to the docker buildx --output, which would let me dump the container in OCI format out, then push it to GHCR.
Does that make sense?

Given the dev container CLI supports --platform which like buildx supports a list, so wouldn't wiring that up be a bit easier?
e.g., this should work: devcontainer build --platform "linux/amd64,linux/arm64"

Oh yeah, that's what I'm doing. But given the only way that call works now is with --push, there's no way to run the intermediate command (unless I'm mistaken). That's what I'm trying to preserve: the ability to build, test, and then push that's currently in the Action.

Do you mean the runCmd?  Yeah, that would require --load unfortunately since it ultimately is a "docker run + exec".  So you'd end up having to do an image pull or something after it was created anyway - another single architecture build that hopefully reuses the cache.  So you're thinking that having an output type would allow you to export and then import and push?

Yeah, runCmd is what I was talking about, sorry for not specifying. That part actually still works, because the devcontainer up that runCmd does recognizes it doesn't have a local image it can use an builds it again just for the local platform (not super efficient, obviously but gets the job done). (If you want to see for yourself, check this out: https://github.com/natescherer/sre-devcontainer/runs/8139243944?check_suite_focus=true)
I'm still trying to figure out how to push the OCI tarball to GHCR, but, if I can figure that out, I do think that adding output options to the CLI would solve the problem.

Okay, after a LOT of testing, I've determined that you can run this to copy a multi-image OCI tarball to GHCR successfully: skopeo copy --all oci-archive:muilti-platform-image.tar docker://ghcr.io/owner/repo:latest
I made quick and dirty edits to the CLI to tack --output type=oci,dest=multi-platform-image.tar onto the buildx call while I was proving this out, I will expand that out to add proper --output-type and --output-dest options to the CLI, add doc and tests, and make a PR!

Resolved by #166


Only show to users non restricted attributes

On #6129 a regular user (non admin) could not attach a disk to a VM template.
The cause of this issue is that when you get the disks that could be attached:

FSunstonte gets all the info from the API, and when you try to save your template, this includes a field DISK with all the info fields that returns the API. After that, if some of this fields couldn't be change by a regular user (because are in oned.conf) the creation of the VM template will fail.
Also, after correct this error sending to the creation of the VM template the field DISK with only two fields inside (IMAGE and IMAGE_UNAME) there is another problem. The second step (Advanced options) have fields that couldn't be change by a regular user:

For example, oned.conf have this line:
VM_RESTRICTED_ATTR = "DISK/TOTAL_BYTES_SEC"
And in the form we can set the field by the user:

So if the user set this field, the creation will fail.
To summarize:

In the form of a regular user, the fields that are not allowed to change in oned.conf will have not appear on it. This has to be dinamically because config is in oned.conf
For an admin user, that not applies, because he could change everything.
Also, there are other functionalities of the app that needs to have this functionality.

This issue was fixed in the development of https://github.com/OpenNebula/one/issues/6154


Built-In Template usage example has a syntax error

On the Build Mail usage docs, the Built-In Template code has a syntax error:
const mail = MailMessage.init()
    .greeting('Hello Sarah,')
    .line("You've received a new enquiry")
    .line('Summary: The product looks promising! would love to setup a call to discuss more')
    .action('View Enquiry', 'https://app.test.in/admin/queries/123'); // <-- This semicolon should be removed
    .subject('INVOICE PAID: #12345');

Oh yes, this is solved. Thanks! @claudiorivera


Zuul - Hystrix DashBoard Thread Pool Issue

I am using zuul as a gateway for my services. I forced it to use the THREAD isolation
zuul.ribbonIsolationStrategy=THREAD
But the hystrix dashboard displays single common RibbonCommand in the thread pool section instead of the service names (es and geolocation).
Please find the Zuul configuration for the two services
ribbon.eureka.enabled=false
zuul.routes.es.path=/es/**
zuul.routes.es.serviceId=es
es.ribbon.listOfServers=XXXXXXX

zuul.routes.geolocation.path=/geolocation/**
zuul.routes.geolocation.serviceId=geolocation
geolocation.ribbon.listOfServers=XXXXXXXX

please refer the below screen shot for more information

Note:
If you can't see the image. I tried to upload the image but it failed  please let me know is there any other way to achieve it.

It's not there. maybe zip it up and add it?

@spencergibb please find the screenshot (which is mentioned by @vasandharaj )

I thought the correct property to force thread isolation was hystrix.command.default.execution.isolation.strategy = THREAD.

@ryanjbaxter not for our zuul filters though.
@kavinduraisamy all the hystrix commands in zuul use the same group, which, if I'm not mistaken, has them share the same threadpool.

Closing this due to inactivity. Please re-open if there's more to discuss.

@vasandharaj I have the same issue, could you fix it?

@spencergibb why all the hystrix commands in zuul use the same group? Is it intended? What are the benefits of it?

@shuiky by default the command key is the same because it is semaphore. That wasn't changed when the option to use threads was added.

@spencergibb thanks to your reply


Remove static libraries from dist

Static libraries are not required at runtime.
I think our goal should be to remove precompiled libraries altogether and use the libraries from the binary directory for distribution, but as mentioned before have a discussion about this in #15 already

@Conan-Kudo why did you mark this as "blocked"?

I wasn't sure if we used these, apparently we don't...


Add pagination for ticket list

Pagination is a must for the ticket list.  This should be done prior to #15 so that we can implement sorting properly.

380c215 starts this, sample query
{
	"page": 1,
	"per_page": 20,
	"filter": {
		"status": "open"
	},
	"sort": {
		"sort_by": "Assignee",
		"sort_order": "Desc"
	}
}

I was thinking about doing a POST for this as I was going to roll in advanced filtering, and I'm not too fond of the idea of using the URL for what could be a lot of UUIDs.  But I may hold off on that and will keep using url query for pagination.


AdMobBanner is not displayed

I have tried to add admob to my project  .
my project is running correctely without error but no banner is dispayed .
my code is :
    <ScrollView>	 			  <AdMobBanner   bannerSize="banner"   adUnitID="ca-app-pub-3207834634154483/6974060636"   testDeviceID="EMULATOR"   didFailToReceiveAdWithError={this.bannerError}    adViewDidReceiveAd ={null} adViewDidDismissScreen={null} adViewWillLeaveApplication={null}/>       </ScrollView>
Can someone tell me what are probable reason  why my banner is not dispayed .
Thanks

Have you tried changing "bannerSize" to "adSize" and "didFailToRecieveAdWithError" to "onAdFailedToLoad"?

@Mimble-Wimble the change worked for me. Thanks

i was in 1.x branch version . i use now the version 2.
my code now is :
<AdMobBanner   adSize="fullBanner"   adUnitID="ca-app-pub-3207834634154483/6974060636"    testDevices={"EMULATOR"}   onAdFailedToLoad={error => console.error(error)} />
But i have this error

could you help me to fix this problem .
what should set as a value in testDevices to let my code determine dynamicly the device ID .

For v2 you should use testDevices={[AdMobBanner.simulatorId]} instead of the EMULATOR string.

i tried with testDevices={[AdMobBanner.simulatorId]} , but it  generate another error

@yassineHub any update on above issue? Are you able to use version 2 without any issues on android?

I'm still stuck with the above issue .
Any one have the same problem ?

I am getting the same UIManager.RNGADBannerView issue.  testing with iOS.
"react": "16.0.0-beta.5",
"react-native": "https://github.com/expo/react-native/archive/sdk-22.0.2.tar.gz",
"react-native-admob": "^2.0.0-beta.3",
Followed the directions that were given.
Any insight would be great.

+1

@sbugert can you please help us fix this issue?

@KamranKhankhail  i have no update about issue :(
i think i will return to the version 1.0

@yassineHub could it be that you updated the NPM package, but did not rebuild the project? Because I can't reproduce this with the example application..

Or are you by any change running an Expo project? Which I believe have no direct support for packages that need native modules.

Yes, running expo. Bummer that this won't work properly with it. Was looking forward to getting my google ads loading on my app.  Any suggestions or will there be compatibility coming down the line?

Any suggestions or will there be compatibility coming down the line?

Well I think since the library depends on the Google-Mobile-Ads-SDK, this will never work out of the box.
The only probable option is to "eject", and then follow the installation steps in the README.

But if you have any more questions regarding use with Expo, please open a new issue. (Unless @yassineHub is also using Expo?)

Just realized that create-react-native-app uses Expo by default. So my guess is that’s the case here too. If not let me know and I’m happy to reopen.

Please reopen this issue. It's not fixed yet.
I've confirmed the banner appear in Android emu + phy but the error shows when I react-native run-ios

I also insert interstitial ad in my app and it also fails. They are ok in Android though.


Move OSCAL Viewer Package to GitHub Releases

Move the production build of the Oscal Viewer, previously contained in a
separate oscal-viewer package, into the oscal-react-library package,
and remove the viewer package.
This fixes issues with the oscal-viewer package, which was previously
set up only for offline development by using local paths in its dependencies,
which are not compatible with publishing to an online registry.
Moving everything into one package allows for the end user to install both the
Viewer and its dependencies all in one place.

Don't we also want to do a preminor increment of the develop branch when creating a new feature? If we wanted to do so in this workflow we could use this as guidance for checking out and then pushing changes.

Are we assuming this workflow is always run from the develop or main branch or could it be run from any branch?

Are we assuming this workflow is always run from the develop or main branch or could it be run from any branch?

Good point - this should always check out the develop branch and make changes to that first. I'll look into specifying that so when this is triggered manually it always checks out the right branch.

The latest run of the workflow successfully created a release with the OSCAL Viewer as a .zip that's downloadable via the GitHub API.

The latest run of the workflow successfully created a release with the OSCAL Viewer as a .zip that's downloadable via the GitHub API.

@hreineck, unfortunately that viewer.zip contains only an empty build folder.

The last run of the workflow created two new branches, per the diagram: tag-0.2.0, which is the new tag branch created after incrementing the version (in this case from 0.2.0-0 to 0.2.0), and is the same as what would be pushed to main when this is run for real; and test-0.2.0, which is confusingly named but represents the changes that would be pushed to develop as the version is incremented to the next preminor (in this case from 0.2.0 to 0.3.0-0)

The last run of the workflow created two new branches, per the diagram: tag-0.2.0, which is the new tag branch created after incrementing the version (in this case from 0.2.0-0 to 0.2.0), and is the same as what would be pushed to main when this is run for real; and test-0.2.0, which is confusingly named but represents the changes that would be pushed to develop as the version is incremented to the next preminor (in this case from 0.2.0 to 0.3.0-0)

@hreineck, to be clear, we want a 0.2.0 tag, i.e. visible in tags (which seems to be present from a previous run), not necessarily a branch named tag-0.2.0.

Everything looks good! However, I have not personally seen a release. Could you push a new release (and delete it once I've seen it) so I can approve this PR?

Everything looks good! However, I have not personally seen a release. Could you push a new release (and delete it once I've seen it) so I can approve this PR?

Just pushed a release.


Pilot configures proxy with wrong routes/listeners

Bug description
Pilot adds incorrect listeners/routes to envoy proxies, resulting in 503's.  This is the output of proxy-config routes on 2 identical pods created from the same deployment:
This is the proxy that received the correct config:
$ istioctl pc routes pod1.our-namespace
NOTE: This output only contains routes loaded via RDS.
NAME                                                                                VIRTUAL HOSTS
8080                                                                                4
9091                                                                                2
istio-telemetry.istio-system.svc.cluster.local:42422                                                    1
15004                                                                                2
15014                                                                                2
inbound|8080|http|correct-service.our-namespace.svc.cluster.local     1
inbound|8080|http|correct-service.our-namespace.svc.cluster.local     1
inbound|8080|http|correct-service.our-namespace.svc.cluster.local     1
inbound|8080|http|correct-service.our-namespace.svc.cluster.local     1

Here is the output from an incorrectly configured proxy on the other pod from the same deployment as above:
$ istioctl pc routes pod2.our-namespace
NOTE: This output only contains routes loaded via RDS.
NAME                                                           VIRTUAL HOSTS
8080                                                           4
istio-telemetry.istio-system.svc.cluster.local:42422           1
9091                                                           2
15004                                                          2
15014                                                          2
inbound|8800|http|service-from-another-namespace.wrong-namespace.svc.cluster.local     1
inbound|8800|http|service-from-another-namespace.wrong-namespace.svc.cluster.local     1
inbound|8800|http|service-from-another-namespace.wrong-namespace.svc.cluster.local     1
inbound|8800|http|service-from-another-namespace.wrong-namespace.svc.cluster.local     1

Also notice the port number is not right either.  Restarting the second pod will result in a proxy with the same config as the first, which is correct.
Expected behavior
Pilot configures proxy with correct routes/listeners for the service.
Steps to reproduce the bug
It seems to only happen on a deployment when new pods are created and not every time.  Restarting the pods seems to yield correct listeners every time.
Version (include the output of istioctl version --remote and kubectl version and helm version if you used Helm)
$ istioctl version --remote
client version: 1.4.3
citadel version: 1.4.3
galley version: 1.4.3
galley version: 1.4.3
istio-ig-custom version:
istio-ig-custom version:
istio-ig-custom2 version:
istio-ig-custom2 version:
istio-ig-custom3 version:
istio-ig-custom3 version:
pilot version: 1.4.3
pilot version: 1.4.3
sidecar-injector version: 1.4.3
sidecar-injector version: 1.4.3
telemetry version: 1.4.3
telemetry version: 1.4.3
data plane version: 1.4.0 (1 proxies), 1.4.3 (229 proxies)

$ kubectl version
Client Version: version.Info{Major:"1", Minor:"16", GitVersion:"v1.16.3", GitCommit:"b3cbbae08ec52a7fc73d334838e18d17e8512749", GitTreeState:"clean", BuildDate:"2019-11-14T04:24:34Z", GoVersion:"go1.12.13", Compiler:"gc", Platform:"darwin/amd64"}
Server Version: version.Info{Major:"1", Minor:"15", GitVersion:"v1.15.5", GitCommit:"20c265fef0741dd71a66480e35bd69f18351daea", GitTreeState:"clean", BuildDate:"2019-10-15T19:07:57Z", GoVersion:"go1.12.10", Compiler:"gc", Platform:"linux/amd64"}

How was Istio installed?
Helm 2 with Tiller
Environment where bug was observed (cloud vendor, OS, etc)
On premise, centos

We are seeing the same or simular issue randomly in our pod after upgrading from Istio 1.3.3 to 1.4.3
Steps to reproduce the bug
It seems to only happen on a deployment when new pods are created and not every time. Restarting the pods seems to yield correct listeners every time.
Version (include the output of istioctl version --remote and kubectl version and helm version if you used Helm)
$ istioctl version --remote

client version: 1.4.3
citadel version: 1.4.3
egressgateway version: 1.4.3
egressgateway version: 1.4.3
egressgateway version: 1.4.3
egressgateway version: 1.4.3
egressgateway version: 1.4.3
galley version: 1.4.3
ilbgateway version: 1.4.3
ilbgateway version: 1.4.3
ingressgateway version: 1.4.3
ingressgateway version: 1.4.3
ingressgateway version: 1.4.3
ingressgateway version: 1.4.3
ingressgateway version: 1.4.3
nodeagent version:
[... nodeagent version ...]
nodeagent version:
pilot version: 1.4.3
pilot version: 1.4.3
policy version: 1.4.3
sidecar-injector version: 1.4.3
telemetry version: 1.4.3
telemetry version: 1.4.3
data plane version: 1.4.3 (838 proxies)

$ kubectl version

Client Version: version.Info{Major:"1", Minor:"17", GitVersion:"v1.17.2", GitCommit:"59603c6e503c87169aea6106f57b9f242f64df89", GitTreeState:"clean", BuildDate:"2020-01-18T23:30:10Z", GoVersion:"go1.13.5", Compiler:"gc", Platform:"darwin/amd64"}
Server Version: version.Info{Major:"1", Minor:"14+", GitVersion:"v1.14.7-gke.23", GitCommit:"81c87c699557fed991e292cd328b2129c2f242a2", GitTreeState:"clean", BuildDate:"2019-11-07T19:23:23Z", GoVersion:"go1.12.11b4", Compiler:"gc", Platform:"linux/amd64"}

How was Istio installed?
Helm 2 with Tiller
Environment where bug was observed (cloud vendor, OS, etc)

Google Cloud
GKE

$ gcloud container clusters list
NAME           LOCATION      MASTER_VERSION  MASTER_IP     MACHINE_TYPE   NODE_VERSION   NUM_NODES  STATUS
a-cluster      europe-west1  1.14.7-gke.23   x.x.x.x.x     n1-standard-4  1.14.7-gke.23  108        RUNNING

Additional information about this issue:
These are the routes in a normal pod (edited the names, I can provide the output wihtout edits via a private channel):
$ istioctl pc routes a-deployment-794f446794-zzwvm.correct-namespace
NOTE: This output only contains routes loaded via RDS.
NAME                                                                                VIRTUAL HOSTS
80                                                                                33
96                                                                                2
5556                                                                                2
8060                                                                                2
8080                                                                                10
8081                                                                                3
9090                                                                                3
9091                                                                                30
9901                                                                                2
10901                                                                                2
15004                                                                                3
15010                                                                                2
15014                                                                                7
15030                                                                                2
15031                                                                                2
jaeger-istio-collector.istio-system.svc.cluster.local:9411                                                 1
jaeger-istio-collector.istio-system.svc.cluster.local:14267                                                1
inbound|9091|http-prom-a-deployment-correct-namespace|a-deployment.correct-namespace.svc.cluster.local     1
jaeger-istio-collector.istio-system.svc.cluster.local:14268                                                1
istio-telemetry.istio-system.svc.cluster.local:42422                                                       1
inbound|9091|http-prom-a-deployment-correct-namespace|a-deployment.correct-namespace.svc.cluster.local     1
inbound|80|http-a-deployment-correct-namespace|a-deployment.correct-namespace.svc.cluster.local            1
inbound|80|http-a-deployment-correct-namespace|a-deployment.correct-namespace.svc.cluster.local            1
20001                                                                                2
                                                                                1

This are the routes from a faulty pod
istioctl pc routes a-deployment-794f446794-clvbg.correct-namespace
NOTE: This output only contains routes loaded via RDS.
NAME                                                                                VIRTUAL HOSTS
80                                                                                33
96                                                                                2
5556                                                                                2
8060                                                                                2
istio-telemetry.istio-system.svc.cluster.local:42422                                1
jaeger-istio-collector.istio-system.svc.cluster.local:14268                         1
inbound|80|http-other-deployment-wrong-namespace|other-deployment.wrong-namespace.svc.cluster.local     1
jaeger-istio-collector.istio-system.svc.cluster.local:9411                          1
jaeger-istio-collector.istio-system.svc.cluster.local:14267                         1
inbound|80|http-other-deployment-wrong-namespace|other-deployment.wrong-namespace.svc.cluster.local     1
8080                                                                                10
8081                                                                                3
9090                                                                                3
9091                                                                                30
9901                                                                                2
10901                                                                               2
15004                                                                               3
15010                                                                               2
15014                                                                               7
15030                                                                               2
15031                                                                               2
20001                                                                               2
                                                                                1

When executing an http request to a POD with the correct configuration we can see the headerx-envoy-decorator-operation set to the correct POD name:
curl -I http://a-deployment-794f446794-zzwvm.correct-namespace:8080
< server: istio-envoy
< x-envoy-decorator-operation: a-deployment.correct-namespace:80/*

If we execute the same request to a POD with a wrong configuration we see:
curl -I http://a-deployment-794f446794-clvbg.correct-namespace:8080
< server: istio-envoy
< x-envoy-decorator-operation: other-deployment.wrong-namespace:80/*

where you can notice the x-envoy-decorator-operation header indicates other-deployment.wrong-namespace:80 but we expected to see a-deployment-794f446794-clvbg.correct-namespace:80
Additionally, we have detected that the content response is correct, it is provided by a-deployment-794f446794-clvbg.correct-namespace but Policies are wrong (in our case, JWT Policy).
Kubernetes and Istio resources for a-deployment in correct-namespace:
VirtualService:
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  creationTimestamp: "2019-08-07T06:15:32Z"
  generation: 3
  labels:
    app: a-deployment
    chart: base-v1.2.17
    fullapp: correct-namespace
    heritage: Tiller
    release: a-deployment-correct-namespace
    version: v1.2.17
  name: a-deployment
  namespace: correct-namespace
  resourceVersion: "281486396"
  selfLink: /apis/networking.istio.io/v1alpha3/namespaces/correct-namespace/virtualservices/a-deployment
  uid: c3360aef-b8da-11e9-b4e4-42010ac50709
spec:
  gateways:
  - default/ingressgateway
  hosts:
  - correct-namespace.dev-01.my.domain.com
  - other.dev.my.domain.com
  http:
  - corsPolicy:
      allowCredentials: false
      allowHeaders:
      - origin
      - x-requested-with
      - accept
      - content-type
      - x-application-id
      - x-correlation-id
      - x-request-id
      - authorization
      - x-authorization
      - X-Customer-ID
      - X-SFID
      - X-MSISDN
      - x-front-client
      - scoring-token
      - x-target
      - cache-control
      allowOrigin:
      - '*'
      maxAge: 600s
    match:
    - uri:
        prefix: /v1/a-deployment/
    rewrite:
      uri: /
    route:
    - destination:
        host: a-deployment.correct-namespace.svc.cluster.local
        port:
          number: 80

Service:
piVersion: v1
kind: Service
metadata:
  annotations:
    prometheus.io/path: /metrics
    prometheus.io/port: "9091"
    prometheus.io/probe: "true"
  creationTimestamp: "2019-08-07T06:15:32Z"
  labels:
    app: a-deployment
    chart: base-v1.2.17
    fullapp: correct-namespace
    heritage: Tiller
    release: a-deployment-correct-namespace
    version: v1.2.17
  name: a-deployment
  namespace: correct-namespace
  resourceVersion: "435659168"
  selfLink: /api/v1/namespaces/correct-namespace/services/a-deployment
  uid: c3314118-b8da-11e9-b4e4-42010ac50709
spec:
  clusterIP: <IP_ADDRESS>
  ports:
  - name: http-a-deployment-correct-namespace
    port: 80
    protocol: TCP
    targetPort: 8080
  - name: http-prom-a-deployment-correct-namespace
    port: 9091
    protocol: TCP
    targetPort: 9091
  selector:
    app: a-deployment
    release: a-deployment-correct-namespace
  sessionAffinity: None
  type: ClusterIP

Policy
apiVersion: authentication.istio.io/v1alpha1
kind: Policy
metadata:
  creationTimestamp: "2019-10-21T14:11:59Z"
  generation: 1
  labels:
    app: a-deployment
    chart: base-v1.2.17
    fullapp: correct-namespace
    heritage: Tiller
    release: a-deployment-correct-namespace
    tier: backend
    version: v1.2.17
  name: a-deployment-authn
  namespace: correct-namespace
  resourceVersion: "281486392"
  selfLink: /apis/authentication.istio.io/v1alpha1/namespaces/correct-namespace/policies/a-deployment-authn
  uid: bf1eaa37-f40c-11e9-8d86-42010ac50709
spec:
  origins:
  - jwt:
      issuer: issuer1
      jwksUri: https://auth-provider-jwks.example.com/.well-known/jwks.json
      trigger_rules:
      - excluded_paths:
        - exact: /health
        - prefix: /docs
        - exact: /health
        - exact: /metrics
        included_paths:
        - prefix: /
  - jwt:
      issuer: issuer2
      jwksUri: https://auth-provider-jwks.example.com/.well-known/jwks.json
      trigger_rules:
      - excluded_paths:
        - exact: /health
        - prefix: /docs
        - exact: /health
        - exact: /metrics
        included_paths:
        - prefix: /
  principalBinding: USE_ORIGIN
  targets:
  - name: a-deployment

Kubernetes and Istio resources for other-deployment in wrong-namespace:
VirtualService
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  creationTimestamp: "2019-08-14T10:09:51Z"
  generation: 3
  labels:
    app: other-deployment
    chart: base-v1.2.17
    fullapp: wrong-namespace
    heritage: Tiller
    release: other-deployment-wrong-namespace
    version: v1.2.17
  name: other-deployment
  namespace: wrong-namespace
  resourceVersion: "294862447"
  selfLink: /apis/networking.istio.io/v1alpha3/namespaces/wrong-namespace/virtualservices/other-deployment
  uid: a7b23296-be7b-11e9-bf65-42010ac5070b
spec:
  gateways:
  - default/ingressgateway
  hosts:
  - wrong-namespace.dev.my.domain.com
  - other-url.dev.my.domain.com
  http:
  - corsPolicy:
      allowCredentials: false
      allowHeaders:
      - origin
      - x-requested-with
      - accept
      - content-type
      - x-requestId
      - x-requestSessionId
      - authorization
      - cache-control
      allowOrigin:
      - '*'
      maxAge: 600s
    match:
    - uri:
        prefix: /other-deployment/
    rewrite:
      uri: /
    route:
    - destination:
        host: other-deployment.wrong-namespace.svc.cluster.local
        port:
          number: 80

Service
apiVersion: v1
kind: Service
metadata:
  annotations:
  creationTimestamp: "2019-08-14T10:09:51Z"
  labels:
    app: other-deployment
    chart: base-v1.2.17
    fullapp: wrong-namespace
    heritage: Tiller
    release: other-deployment-wrong-namespace
    version: v1.2.17
  name: other-deployment
  namespace: wrong-namespace
  resourceVersion: "435658730"
  selfLink: /api/v1/namespaces/wrong-namespace/services/other-deployment
  uid: a7afea06-be7b-11e9-bf65-42010ac5070b
spec:
  clusterIP: <IP_ADDRESS>
  ports:
  - name: http-other-deployment-wrong-namespace
    port: 80
    protocol: TCP
    targetPort: 8080
  selector:
    app: other-deployment
    release: other-deployment-wrong-namespace
  sessionAffinity: None
  type: ClusterIP

Policy
apiVersion: authentication.istio.io/v1alpha1
kind: Policy
metadata:
  creationTimestamp: "2019-09-11T10:26:43Z"
  generation: 1
  labels:
    app: other-deployment
    chart: base-v1.2.17
    fullapp: wrong-namespace
    heritage: Tiller
    release: other-deployment-wrong-namespace
    tier: backend
    version: v1.2.17
  name: other-deployment-authn
  namespace: wrong-namespace
  resourceVersion: "294862440"
  selfLink: /apis/authentication.istio.io/v1alpha1/namespaces/wrong-namespace/policies/other-deployment-authn
  uid: a64ba2ce-d47e-11e9-bf65-42010ac5070b
spec:
  origins:
  - jwt:
      issuer: issuer3
      jwksUri: https://auth-provider-jwks.example.com/.well-known/jwks.json
      trigger_rules:
      - excluded_paths:
        - exact: /monitoring/health
        - prefix: /doc/
  principalBinding: USE_ORIGIN
  targets:
  - name: other-deployment

As for the config dump file, it is attached.
istio-config-dump-edited.json.gz
I hope this information is useful.
Thanks!

This may just be some recency bias, but this feels a lot like https://github.com/istio/istio/issues/20676. tl;dr is a pod IP gets re-used, causing pilot to generate config for the old pod instead of the new pod. So presumably, if this was the case, there was a pod with some ip <IP_ADDRESS> in service-from-another-namespace.wrong-namespace, then later your new pod in service correct-service.our-namespace comes up with pod ip <IP_ADDRESS> and gets the wrong config. I think this can only happen with pre-emptible nodes though, are you using those?
The tell-tale sign of this is if you see this pattern in the logs:
Handling event update for pod pod1-sha123 in namespace foo -> <IP_ADDRESS>
Handling event update for pod pod1-sha123 in namespace foo -> <IP_ADDRESS> # same pod name, new IP
Handling event update for pod new-pod-sha345 in namespace foo -> <IP_ADDRESS> # re-use the old pod

@howardjohn In our case the nodes are long-living, they are on-prem and have been running for nearly a year.

Hi @howardjohn , we are indeed using preemtible nodes (and not preemtible).
I've search for "Handling event update for pod" in Stackdriver logs (whole cluster) and I couldn't find a single match. (Also tested substrings)

@pmoncadaisla if you are using pre-emptible nodes it seems likely the root cause. Thats weird it doesn't match, that log happens any time a pod is changed at all, do you not have info level logging enabled?

@howardjohn I can see this in the istio-proxy container of any POD: --proxyLogLevel="warning" and --log_output_level="default:info"
Pre-emptible notes seems to me the root cause, but, why is this happening after the upgrade from 1.3.3 to 1.4.3 and not before? We've seem this exact behaviour in 2 different Kubernetes clusters, upgraded from and to the same Istio version.

My understand was that this code path is entirely unchanged, so I am surprised it change during upgrade - very possible its a different root cause. The logs I am referring to are on pilot not the proxy.

You are right @howardjohn , I was looking for logs in a cluster were logs from pilot are excluded from ingestion at Stackdriver.
I've checked for the same one I reported before, and I can see what you described:
2020-02-05T12:10:59.408811Z info Handling event update for pod other-deployment-6d94d5f9db-8mt4d in namespace wrong-namespace -> <IP_ADDRESS>
2020-02-05T12:12:50.781199Z info Handling event update for pod other-deploymenti-6d94d5f9db-8mt4d in namespace wrong-namespace  -> <IP_ADDRESS>
2020-02-05T15:24:21.009595Z info Handling event update for pod a-deployment-794f446794-clvbg in namespace correct-namespace -> <IP_ADDRESS>

In this case IP address <IP_ADDRESS> is being reused as you described.
I guess our options if we are affected by this issue are:

Shutdown preemtible nodes
Wait for 1.5 and expect #20676 to be included

@pmoncadaisla this will be backported to 1.4 as well. If you want, you can run the dev builds that include this commit: https://github.com/istio/istio/wiki/Dev Builds. You can see all commits at https://github.com/istio/istio/commits/release-1.4. Note that we don't validate these much, so it would be at your own risk

Hi @howardjohn , we have removed our preemptible nodes until the fix is included in a release.
We will be monitoring and we will keep you informed if we see the same behaviour after removing preemptible nodes.
If we don't have problems, then our issue is not related to @jasonwoodman-ascend 's

Its possible @jasonwoodman-ascend is the same issue without pre-emptible nodes. The symptom here is a running pod has its IP address changed. I've only seen it on node restarts, but perhaps it could happen in other cases?

@howardjohn  @pmoncadaisla I think my issue can be explained by the same root cause.  In our case, though the nodes are long living, we do restart them for patching.  I am guessing our issue started in our last patching cycle, the timing seems about right.
At this point I am waiting for the fix to be released and will re-evaluate then as I think it will most likely fix it.

I think, we have same or very similar issue, so that's why I'm not filing a new bug. In our case as well istio pickups listeners from completely different namespace (kube-system) instead of namespace where service is deployed. However, it's intermittent issue, we have to run delete-create loop for deployment/service to reproduce it. The only thing that helped as is to manually define Sidecar object and repeat all the ports defined in Service object.

This should be fixed in 1.4+ now. If you still see this issue on these versions, please reopen/open another issue. Thanks!


Fixed: Leaderboard shows infinite loading when no search results are found

Fixes #406

Thank you for submitting your pull request! 🙌 We'll review it as soon as possible. In the meantime, please ensure that your changes align with our CONTRIBUTING.md. If there are any specific instructions or feedback regarding your PR, we'll provide them here. Thanks again for your contribution! 😊


Build name is included as a module id after publishing a maven build

Describe the bug
When using JFrog CLI to compile and build, publish maven builds, the build name is also getting included as one of the Published modules under the builds section
To Reproduce
Step 1: Clone the project https://github.com/jfrog/project-examples/tree/master/maven-examples/maven-jib-example
Step 2: Use JFrog-CLI 1.47.3 and Artifactory 6.23.15 version
Step 3: Configure the project to use JFrog CLI
Step 4: Steps to be performed to collect env variables, compile and publish:

Collect the build information using: $ jfrog rt bce maven 2
Build the project using: $ jfrog rt mvn clean install -f pom.xml --build-name=maven --build-number=2 -Dartifactory.publish.artifacts=true
Publish the build using: $ jfrog rt bp maven 2

Expected behavior
After performing the "jfrog rt bp maven 2" it is expected to see only the modules available within the project and it should not consider the build name as one of the published modules
Screenshots

Versions

JFrog CLI version: 1.47.3
JFrog CLI operating system: Centos 7, Mac
Artifactory Version: 6.23.15

Additional context
This behaviour is not observed when using Jenkins and observed only when using JFrog-CLI

I also observed this incorrect behaviour when doing a python build.
I can conclude that running the rt bp command inserts the following in the "modules" array in the build info json.
    {
        "properties": {},
        "id": "<build name>"
    }

The rt bp command should not add any module information at all to the build info since there is no module associated with build environments.

Looking into the source it might be that this is an issue in jfrog-cli-core.
I have very limited Go knowledge, but to me it looks like when we get to here:
https://github.com/jfrog/jfrog-cli-core/blob/5d91a428da61ab2cf350b864e628990a7f711156/artifactory/commands/buildinfo/publish.go#L138
the modules array is not empty, and the code ends up adding the build name as "id" to an otherwise empty module.
Might help someone with better knowledge of Go to submit a PR for this issue. Or I could be completely wrong in my analysis.


Individual plants no longer display scientific name

Is there anything Elli has to do to make this work? Is the XML transform not getting the correct information?

unsure how this changed--not understanding what's different about the xslt from Nov/Dec--

I realized this late last night - when we moved to multiple herbarium links (Kew, WFO) we changed the location of the link text.
There is now a new metadata variable for each plant: plant-taxon-content: "Clematis Vitalba L." (for plant 5)
should be able to use that and add it in above the Kew WFO links, below the title.

But it may not be populating. checking now

It's a data problem - @emylonas will fix in the xml file.

fixed with c72e249


Exception "Your hydrator directory must be writable." for writable directory

Bug Report

Q
A

BC Break
no

Version
2.2.2

Summary
Exception "Your hydrator directory must be writable." occurs for a directory that definitely is writable. The exception occurs from time to time when a directory needs to be created and looks like a race condition.
The code that throws the exception is similar to this:
https://github.com/kalessil/phpinspectionsea/blob/master/docs/probable-bugs.md#mkdir-race-condition
Current behavior
I got the following exception for a directory that definitely was writable:
Your hydrator directory must be writable.
#0 /var/www/releases/20230328170455/backend/vendor/doctrine/mongodb-odm/lib/Doctrine/ODM/MongoDB/Hydrator/HydratorFactory.php(437): Doctrine\ODM\MongoDB\Hydrator\HydratorException::hydratorDirectoryNotWritable()
#1 /var/www/releases/20230328170455/backend/vendor/doctrine/mongodb-odm/lib/Doctrine/ODM/MongoDB/Hydrator/HydratorFactory.php(143): Doctrine\ODM\MongoDB\Hydrator\HydratorFactory->generateHydratorClass()
#2 /var/www/releases/20230328170455/backend/vendor/doctrine/mongodb-odm/lib/Doctrine/ODM/MongoDB/Hydrator/HydratorFactory.php(496): Doctrine\ODM\MongoDB\Hydrator\HydratorFactory->getHydratorFor()
#3 /var/www/releases/20230328170455/backend/vendor/doctrine/mongodb-odm/lib/Doctrine/ODM/MongoDB/UnitOfWork.php(2690): Doctrine\ODM\MongoDB\Hydrator\HydratorFactory->hydrate()
#4 /var/www/releases/20230328170455/backend/vendor/doctrine/mongodb-odm/lib/Doctrine/ODM/MongoDB/Persisters/DocumentPersister.php(635): Doctrine\ODM\MongoDB\UnitOfWork->getOrCreateDocument()
#5 /var/www/releases/20230328170455/backend/vendor/doctrine/mongodb-odm/lib/Doctrine/ODM/MongoDB/Persisters/DocumentPersister.php(504): Doctrine\ODM\MongoDB\Persisters\DocumentPersister->createDocument()
#6 /var/www/releases/20230328170455/backend/vendor/doctrine/mongodb-odm/lib/Doctrine/ODM/MongoDB/Repository/DocumentRepository.php(172): Doctrine\ODM\MongoDB\Persisters\DocumentPersister->load()
...

How to reproduce

I have a web app where I use doctrine/mongodb-odm
I have a writable directory /some/path/temp
The configuration of the DocumentManager looks like this:$config = new Configuration;
$config->setProxyDir('/some/path/temp/doctrine/proxy');
$config->setHydratorDir('/some/path/temp/doctrine/hydrator');
// ...
DocumentManager::create(null, $config)

I originally got an exception on the production server when I was doing the deployment of the new version. At the moment I switched the app to the new directory /some/path/temp, I got an exception Your hydrator directory must be writable.
Later I was able to reproduce this in my stage environment. I first remove /some/path/temp/doctrine directory and then run: ab -c 50 -n 50 https://.... After several tries I get an exception "Your hydrator directory must be writable." in the app logs.

Expected behavior
The directory is created without any exceptions.

The easiest solution is to avoid this race condition altogether and have the folders created before ODM tries to do so itself. Is that an option? There also was a schoold of pre-generating all hydrators/proxies before during deployment :)

Yes, that's an option for me, thanks for the tip!
If I generate hydrators and proxies when I build the app before the deployment, can I leave the directories for them read-only in that case? The application code and all dependencies are not changed after the build. Build and deploy are performed on different machines.

Yes, the code generation branch is executed only if the file does not exist:
https://github.com/doctrine/mongodb-odm/blob/bc49b1e2f9fe9d224ecff8dd9fc1557c67dda983/lib/Doctrine/ODM/MongoDB/Hydrator/HydratorFactory.php#L147-L152
You may also consider using Configuration::AUTOGENERATE_NEVER mode which will just fail if the file was not generated earlier.


Turn coverage off before publishing

Hard to test without merging it, but I think this will get @cranst0n unblocked.

Codecov Report

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

@@            Coverage Diff             @@
##           master    #1418      +/-   ##
==========================================
- Coverage   71.26%   70.91%   -0.35%
==========================================
  Files         259      259
  Lines        6041     6041
  Branches      364      364
==========================================
- Hits         4305     4284      -21
- Misses       1736     1757      +21

Impacted Files
Coverage Δ

.../scala/org/http4s/testing/ArbitraryInstances.scala
92.21% <0%> (-7.79%)
:arrow_down:

core/src/main/scala/org/http4s/Uri.scala
85.48% <0%> (-3.23%)
:arrow_down:

core/src/main/scala/org/http4s/HttpVersion.scala
93.33% <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 4bc143d...ddc1485. Read the comment docs.

It's just a snapshot... going to merge now and ask forgiveness later.


Perrmit decimal values on unmute delay

Great app.
It works better than others similars but, sometimes, unmute delay option cut the beginning of track. Even when that happens its better than ad audio.
Thanks.

I second that (no pun intended).
With 0 delay I can often hear the end of the ad. With 1 it cuts the beginning of track. More granular would be ideal.

:+1: will not take much efforts to add, will include it in next release


feat/hugmod 10801

Add hugo.mod test
step 1: Rename main go.mod > hugo.mod

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you all sign our Contributor License Agreement before we can accept your contribution.1 out of 2 committers have signed the CLA.:white_check_mark: bep:x: dionysiusYou have signed the CLA already but the status is still pending? Let us recheck it.


Both scaleable and draggable chart implemented

Implements #1720
I used the idea from #1721 and implemented FlScaleEvent but without explicitly specifying detectScale to disable drag fully when scaling. detectScale could've been set dynamically but it was combursome and couldn't get it working. Implementing a new FLTouchEvent seemed better option.
The drawback was as in #1721 mentioned PanGestureRecognizer  and ScaleGestureRecognizer does not like to be used together. But ScaleGestureRecognizer event details also feeds the PanGestureRecognizer event details (except onDown) see, so instead of disabling dragging fully when you want to scale, I notify ScaleEvent when there are two points and drag when one point is in contact with the screen. Same idea of this comment
! Details feeding into FlPan...Event have been switched to Scale details. Testing may be needed.
You can get TouchEvent from touchcallback as
touchCallback: (FlTouchEvent touchEvent, lineTouchRsp) {
              if (touchEvent is FlScaleStartEvent) {
                       // https://api.flutter.dev/flutter/gestures/ScaleStartDetails-class.html
                       }
             if (touchEvent is FlScaleUpdateEvent) {
                      // You can see the details of touch event with:  touchEvent.details
                     // https://api.flutter.dev/flutter/gestures/ScaleUpdateDetails-class.html
                       }
             if (touchEvent is FlPanUpdateEvent) {
                     // NOT https://api.flutter.dev/flutter/gestures/DragUpdateDetails-class.html
                     // https://api.flutter.dev/flutter/gestures/ScaleUpdateDetails-class.html
                       }
}

with the FlScaleEvent I am able to set minX and maxX to zoom in/out chart without the scale is being also interpreted as drag. See #71

Would be great if this could be merged for the next implementation.

Hi @adamsocrat  @imaNNeo , joining the conversation here.
I think it might be a bit inconsistent with the rest of the flutter framework to raise scale events for 2 fingers and pan for 1 finger.
To my limited understanding, the idea behind this is that - scale is also a pan. with the scale events, you could implement pan because it already has all the necessary information.
I think whatever implementation you guys end choosing, should be consistent with how GestureDetector works in this scenario.

Hello, any progress with this ?

Unfortunately I had no time to debug and implement better. I think in #1793 they are working on a better solution. So I am closing this issue.


Formatting in publication author list

Hi,
Thanks for a great theme. I'm trying to build a personal academic site using this theme, and I was wondering whether there is any way to add annotations/formatting to the author list for publications. For example, if I am not the first author, I would like to make my name bold in the author list, and other similar formatting. In case of some of my co-authors, they have special characters in their names, which I would like to add.
Is there any way to implement this?
Thanks.

@saurabhbelsare glad you like the theme, let me know if you have any other feedback.
Academic keeps things simple and uses plain text for author names, so the easiest way to highlight names would be to postfix a symbol (e.g. *) to denote something special like many journal/conference authors do.
Otherwise, you can add full markdown formatting to the authors text by:

Edit /themes/academic/layouts/partials/publication_li_detailed.html
Change {{ delimit . ", " }} (approx. line 43) to {{ delimit . ", " | markdownify }}
Edit /themes/academic/layouts/publication/single.html
Apply the same change as above (to approx. line 10)

@gcushen This is exactly what I was looking for. Thanks a lot!


Move Word and WordR function to view.go

IMO it'd still be useful to have these functions in buffer for non-lime users. We could create a new WordEx(seps string, offset int) Region function so that view can specify the separators to consider.

Totally agree, Also I think we should do the same thing for Classify method.
IMO Word function and other similar functions should use Classify method with appropriate classes, but currently Classify is using regex for detecting all classes and its slow so until moving Word function logic  to Classify for CLASS_WORD_START and CLASS_WORD_END.

All excellent points :)


[FEAT] Enable UDF to handle arbitrary number of Daft series

Enables using *args to pass an arbitrary number of Daft series to a UDF.

closes https://github.com/Eventual-Inc/Daft/issues/1895


Move code to wait and log errors to library code

Move the code to eagerly/deferredly trap Process.wait errors to Child_processes.Termination, instead of having duplicated code.
Pass the module and location to the library code, don't use the log ppx, so that error logs show where this new function is called from.
Untested, but the wait code is the same as in #8352.

This should have been part of PR #8352, and we agreed to take it in stand yesterday. Merging.


⚠ ClamAV has degraded performance

In 4ff3808, ClamAV (https://spamassassin.apache.org/) experienced degraded performance:

HTTP code: 200
Response time: 72 ms

Resolved: ClamAV performance has improved in f39e530.


var(--safe-area-inset-*) is 0px when plugin is enabled at capacitor.config.json

Describe the bug
if plugin is enabled at capacitor.config.json, var(--safe-area-inset-*) is 0px.
To Reproduce
Steps to reproduce the behavior:

Set config as below at capacitor.config.json

{
  "plugins": {
    "SafeArea": {
      "enabled": true,
      "customColorsForSystemBars": true,
      "statusBarColor": '#00000000',
      "statusBarContent": 'dark',
      "navigationBarColor": '#00000000',
      "navigationBarContent": 'dark'
    }
  }
}

Run app
Both top & bottom safe area in css are 0px

Expected behavior
Both top & bottom safe area in css should be the same as status bar & navigation bar's height.
Smartphone (please complete the following information):

Device: Samsung S22
OS: Android 14

Additional context
I need call following code again to make the top & bottom safe area css as normal:
import { SafeArea } from '@capacitor-community/safe-area';

SafeArea.enable({
  config: {
    customColorsForSystemBars: true,
    statusBarColor: '#00000000',
    statusBarContent: 'dark',
    navigationBarColor: '#00000000',
    navigationBarContent: 'dark',
  },
});

Anyway, I try to call following code, but it does NOT make the top & bottom safe area css as normal:
import { initialize } from '@capacitor-community/safe-area';

initialize();

I have the same issue using it with svelte 5. I build using the svelte static adapter (so mainly SSR), point capacitor to it and --safe-area-inset-top is always max(0px, 0px). I tried with initialize and/or SafeArea.enable.


Running linkcheck before spelling breaks contraction filtering

I kept getting spelling errors like
api.rst:756:shouldn:
api.rst:756:doesn:
api.rst:1516:doesn:
api.rst:2522:isn:

After some searching (found #22, am using 4.3.0) and head-banging, I finally discovered that appears to be caused by me running
sphinx-build -M clean . _build/
sphinx-build -M linkcheck . _build/
sphinx-build -M spelling . _build/ -W --keep-going

If I skip linkcheck (and run it after spelling) the spelling errors go away.  Alternatively, nuking _build/doctrees/ between the linkcheck and spelling runs also makes the spelling errors go away.  BTW, it is not linkcheck specific.  I get the same behavior when running spelling after conversion to html or latexpdf and guess that it happens with any other builder (that creates a doctree) as well.
I'm not sure this is spelling's fault and don't know whether there's anything that can be done about this but it should probably be noted somewhere at the very least.

We don't see this behavior in the doc build for this repo. tox.ini runs an HTML build and then a spelling build.
I wonder if there is some difference in the configuration causing what you're seeing? Could you post (or link to) your conf.py file?

I can't reproduce this problem locally or in CI (see #163). I suspect it has something to do with your build environment or some other extension in your build. If it's still a problem for you and you can create a minimal environment for reproducing it please let me know and I'll look at it again.


Test Only: Bug: Undefined Error when Uploading Emissions Data from File

When a user navigates to the Emissions page,
Then clicks the Import Data button,
Then selects "Import from File" from the dropdown,
A red error banner appears that reads "undefined undefined".
[Uploading... image.png]
Note: Kyle is investigating this issue an may turn into a testonly

Issue resolved


WRP-6254: Scroller/List not scroll with touch when native scroll mode

Checklist

[x] I have read and understand the contribution guide
[ ] A CHANGELOG entry is included
[x] At least one test case is included for this feature or bug fix
[x] Documentation was added or is not needed
[x] Documentation was verified or is not changed
[x] UI test was passed or is not needed
[x] Screenshot test was verified or is not needed
[ ] This is an API breaking change

Issue Resolved / Feature Added
Scroller/List not scroll with touch when native scroll mode.
Refer to TouchEvent.scale value to prevent zoom.
Resolution
Touchevent.scale is non-standard.
So, event.scale becomes 'undefined' in chrome and all touchmove gestures are blocked.
Changed to refer to TouchEvent.touches.length to prevent only the pinch zoom gesture.
Additional Considerations
Links
WRP-6254
Comments
Enact-DCO-1.0-Signed-off-by: SJ RO<EMAIL_ADDRESS>

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you all sign our Contributor License Agreement before we can accept your contribution.1 out of 2 committers have signed the CLA.:white_check_mark: sjro:x: enact-adminYou have signed the CLA already but the status is still pending? Let us recheck it.

Code coverage drops due to removal of JS code. It is okay.


How to disable title?

I try put null on .SetTitle(null), but no go.

Thanks for reporting, this is fixed in 1.0.16-SNAPSHOT. :dancer:


@inheritdoc is not working

I've seen multiple mentions that this feature is supposedly supported, but it doesn't seem to be working.
For example:
declare class Tracer extends opentracing.Tracer {
  /** @inheritdoc */
  inject(spanContext: SpanContext | Span, format: string, carrier: any): void;
}

If I don't override the method the documentation is properly displayed.

Hello @rochdev. There are a few known issues with @inheritdoc at the moment. Does the method you are overriding differ at all in its type signature? If so, this might be the same as #793. If no, could you please provide more information about how we can reproduce this?

@aciccarello Just tried with the exact same types (no subclass) and it's still not working.

FWIW it doesn't seem to work for the class documentation either. I don't know if it's the same issue, or if it's simply not implemented for the class description.

I hate to necrobump this issue, but this is one I've been running into on my project (https://github.com/benrr101/node-taglib-sharp). I have classes (eg. Id3v1Tag) that inherits from an abstract class (Tag) that has a lot of long comments for properties I'd like to copy over using inheritDoc. While fiddling with syntax to see if I was just doing it wrong, I noticed my classes that inherited from an interface copied over correctly (eg, ApeStreamHeader inheriting from ICodec). Is it possible the inheritDoc functionality just isn't working with abstract class inheritance?
This could totally be a different issue, if so, let me know and I'll make a new issue from this.

That might be the case... however I also might have fixed this in recent work done on v0.20.
With these changes:
diff --git a/src/id3v1/id3v1Tag.ts b/src/id3v1/id3v1Tag.ts
index 7fd0154..f053c78 100644
--- a/src/id3v1/id3v1Tag.ts
+++ b/src/id3v1/id3v1Tag.ts
@@ -122,13 +122,8 @@ export default class Id3v1Tag extends Tag {
      */
     public set performers(value: string[]) { this._artist = value ? value.join(";") : ""; }

-    /** @inheritDoc */
+    /** @inheritdoc */
     public get album(): string { return this._album || undefined; }
-    /**
-     * @inheritDoc
-     * @description When stored on disk, only the first 30 bytes of the latin-1 encoded value will
-     *     be stored. This may result in data loss.
-     */
     public set album(value: string) { this._album = value ? value.trim() : ""; }

     /** @inheritDoc */

diff --git a/tsconfig.json b/tsconfig.json
index ac5cf56..bc08008 100644
--- a/tsconfig.json
+++ b/tsconfig.json
@@ -17,11 +17,11 @@
     "./src/**/*"
   ],
   "typedocOptions": {
-    "inputFiles": ["./src"],
+    "entryPoints": ["./src/index.ts"],
     "mode": "modules",
     "out": "docs/",
     "excludePrivate": true,
     "disableSources": true,
     "listInvalidSymbolLinks": true
   }
-}
\ No newline at end of file
+}

diff --git a/package.json b/package.json
index 502b7b9..e48d86a 100644
--- a/package.json
+++ b/package.json
@@ -46,7 +46,7 @@
     "tslint": "^5.13.1",
     "typemoq": "^2.1.0",
     "typescript": "^3.9.7",
-    "typedoc": "^0.19.2",
+    "typedoc": "0.20.0-beta.10",
     "typedoc-plugin-markdown": "^3.0.11",
     "uuid": "^7.0.2"
   }

I ran npx typedoc --plugin none (typedoc-plugin-markdown doesn't work with 0.20 yet) and it generated this page:

Well hot damn, that's great to see! I guess I'll just hang on a bit longer until typedoc-plugin-markdown supports 0.20 (or I get annoyed with markdown and just start hosting the docs as html somewhere else).
Out of curiosity, what was the reason for removing the tsdoc for the set accessor?

There was a bug in the accessor converter that broke things if the set accessor had comments - now fixed, but I didn't realize it when first looking at this issue.


Wondering about the perfdata on the pg_dump_backup service

Not sure if this is a bug or not.
When I use the pg_dump_backup service and when the delta is beyond the warning and/or critical values, it gives me the size of the latest backup in the perfdatas. It looks like this:
POSTGRES_PGDUMP_BACKUP CRITICAL: 'b1_delta'=2301687B
From the name of the label, I thought it was the size of the delta for my b1 database. But actually, it is the size of the latest backup. Shouldn't it be the size of the delta?

Sorry for the delay.
The delta perfdata is calculated this way :
@perf_delta  = exists $db_sizes{$db} ?
( "${db}_delta",  $lasts{$db}[1] - $db_sizes{$db}[1], 'B' )
: ( "${db}_delta", 0, 'B' );
db_sizes holds the size of a dump as detected since last call. lasts holds the current dump size.
Was your first backup empty or anything ? Were you running this service for the first time ever ? At first look, you should not get this kind of message in this second case. I'll take a further look on monday.
Thanks for the report

Hi,
Sorry again for the big delay regarding this issue. I guess you encountered the case I explained: this service was probably run for the first time ever.
The delata perfdata is correctly calculated in other cases.
Please, reopen the issue if you have a test case.
Thanks for the report


No way to add duplicate headers using json config (e.g. two Set-Cookie lines)

I think there is no way to set multiple cookies in one response using json config. The below config will only give foo2 in the response (because json doesnt support duplicate keys). Is there a workaround? If there is, I dont think it is mentioned in the documentation.
...
    "response": {
        "headers": {
            "Set-Cookie": "foo=bar; path=/",
            "Set-Cookie": "foo2=bar2; path=/",
...

Which version of WireMock you're using
2.19
How you're starting and configuring WireMock, including configuration or CLI the command line
java -jar wiremock-standalone-2.19.0.jar --global-response-templating

You can set multiple values for a given response header by using an array value like this:
"response": {
        "headers": {
            "Set-Cookie": ["foo=bar; path=/", "foo2=bar2; path=/"]
        }
}

Marking this as a feature request as a reminder to document this properly.

That works perfectly, thanks!

Added a doc note in fea7cde3c3a6f05b323579ee950ff435069c242f


barplot (WIP)

[ ] make tests!!
[ ] add better examples for documentation
[ ] work in progress:
how will legend work since bar plots have their own way legend.text and args.legend
currently treating bars/groups of bars as values on x-axis
using names.arg puts names on top of x-axis values
creates an empty plot and then this (because add=FALSE, so plot.new() is called) BUT using add=TRUE is funky
lower ylim is not lined up with x-axis

Sort of working:
fake <- runif(10, 0, 25)
fake_mat <- matrix(fake, nrow=2, byrow=TRUE)

gs_mat <- gsplot() %>%
    barplot(fake_mat, beside=TRUE, col=c("blue", "green"),
            density=5, space=c(0.1,0.5),
            names.arg=c("one", "two", "three", "four", "five"))
gs_mat

update.packages()?

https://github.com/USGS-R/gsplot/blob/master/R/calc_views.R#L123 looks like we need height for y. Not sure how we handle width here.

@jread-usgs is that for fixing something?

This might be something, similar to curve, that you will need to break down into its components. Which I think are just rectangle elements. Have you looked into that approach?

We've decided to not implement bar graphs at this time -- users can create them using rectangles


[Sponsor] Return date should contain 2 items: date and time

@Mastaleru Can we add "Return Date/Time" (instead of "Return Date")?


Application name was not added in advanced signature properties

Is there a way to configure the application name in the signature properties instead of Not Available

thanks for the info, check the current version from git

@m32 Thank you.  can we please make it configurable

ok - udct['application'], default is endesive