Error on connect Postgres with Service Entry

Is this the right place to submit this?

[X] This is not a security vulnerability or a crashing bug
[X] This is not a question about how to use Istio

Bug Description
I have some applications that consume an external Postgres database.
If I create a service entry for the database, the application cannot connect. Analyzing the envoy logs, I saw the following lines
2024-07-08T20:51:57.134513Z	trace	envoy connection external/envoy/source/common/network/raw_buffer_socket.cc:25	[Tags: "ConnectionId":"162"] read returns: 428	thread=22
2024-07-08T20:51:57.134531Z	trace	envoy connection external/envoy/source/common/network/raw_buffer_socket.cc:39	[Tags: "ConnectionId":"162"] read error: Resource temporarily unavailable, code: 0	thread=22
2024-07-08T20:51:57.134541Z	trace	envoy filter external/envoy/source/common/tcp_proxy/tcp_proxy.cc:696	[Tags: "ConnectionId":"162"] downstream connection received 428 bytes, end_stream=false	thread=22
2024-07-08T20:51:57.134555Z	trace	envoy connection external/envoy/source/common/network/connection_impl.cc:529	[Tags: "ConnectionId":"163"] writing 428 bytes, end_stream false	thread=22
2024-07-08T20:51:57.134566Z	trace	envoy connection external/envoy/source/common/network/connection_impl.cc:614	[Tags: "ConnectionId":"163"] socket event: 2	thread=22
2024-07-08T20:51:57.134573Z	trace	envoy connection external/envoy/source/common/network/connection_impl.cc:737	[Tags: "ConnectionId":"163"] write ready	thread=22
2024-07-08T20:51:57.134632Z	trace	envoy connection external/envoy/source/extensions/transport_sockets/tls/ssl_socket.cc:316	[Tags: "ConnectionId":"163"] ssl write returns: 428	thread=22
2024-07-08T20:51:57.215781Z	trace	envoy filter external/envoy/source/extensions/filters/listener/original_dst/original_dst.cc:22	original_dst: new connection accepted	thread=22
2024-07-08T20:51:57.215817Z	debug	envoy filter external/envoy/source/extensions/filters/listener/original_dst/original_dst.cc:69	original_dst: set destination to <IP_ADDRESS>:5432	thread=22
2024-07-08T20:51:57.215866Z	debug	envoy filter external/envoy/source/common/tcp_proxy/tcp_proxy.cc:243	[Tags: "ConnectionId":"208"] new tcp proxy session	thread=22
2024-07-08T20:51:57.215877Z	trace	envoy connection external/envoy/source/common/network/connection_impl.cc:401	[Tags: "ConnectionId":"208"] readDisable: disable=true disable_count=0 state=0 buffer_length=0	thread=22
2024-07-08T20:51:57.215896Z	debug	envoy filter external/envoy/source/common/tcp_proxy/tcp_proxy.cc:436	[Tags: "ConnectionId":"208"] Creating connection to cluster outbound|5432||dbapiruat01.xxxxxxxxxx	thread=22
2024-07-08T20:51:57.215927Z	debug	envoy misc external/envoy/source/common/upstream/cluster_manager_impl.cc:2328	Allocating TCP conn pool	thread=22
2024-07-08T20:51:57.215967Z	debug	envoy pool external/envoy/source/common/conn_pool/conn_pool_base.cc:291	trying to create new connection	thread=22
2024-07-08T20:51:57.216005Z	trace	envoy pool external/envoy/source/common/conn_pool/conn_pool_base.cc:292	ConnPoolImplBase 0x5654070648c0, ready_clients_.size(): 0, busy_clients_.size(): 0, connecting_clients_.size(): 0, connecting_stream_capacity_: 0, num_active_streams_: 0, pending_streams_.size(): 1 per upstream preconnect ratio: 1	thread=22
2024-07-08T20:51:57.216010Z	debug	envoy pool external/envoy/source/common/conn_pool/conn_pool_base.cc:145	creating a new connection (connecting=0)	thread=22
2024-07-08T20:51:57.216057Z	debug	envoy connection external/envoy/source/common/network/connection_impl.cc:1009	[Tags: "ConnectionId":"209"] connecting to <IP_ADDRESS>:5432	thread=22
2024-07-08T20:51:57.216218Z	debug	envoy connection external/envoy/source/common/network/connection_impl.cc:1028	[Tags: "ConnectionId":"209"] connection in progress	thread=22
2024-07-08T20:51:57.216233Z	trace	envoy pool external/envoy/source/common/conn_pool/conn_pool_base.cc:131	not creating a new connection, shouldCreateNewConnection returned false.	thread=22
2024-07-08T20:51:57.216238Z	trace	envoy connection external/envoy/source/common/network/connection_impl.cc:469	[Tags: "ConnectionId":"208"] raising connection event 2	thread=22
2024-07-08T20:51:57.216243Z	trace	envoy filter external/envoy/source/common/tcp_proxy/tcp_proxy.cc:750	[Tags: "ConnectionId":"208"] on downstream event 2, has upstream = false	thread=22
2024-07-08T20:51:57.216251Z	debug	envoy conn_handler external/envoy/source/common/listener_manager/active_tcp_listener.cc:160	[Tags: "ConnectionId":"208"] new connection from <IP_ADDRESS>:36684	thread=22
2024-07-08T20:51:57.216268Z	trace	envoy misc external/envoy/source/common/network/tcp_listener_impl.cc:114	TcpListener accepted 1 new connections.	thread=22
2024-07-08T20:51:57.216286Z	trace	envoy connection external/envoy/source/common/network/connection_impl.cc:614	[Tags: "ConnectionId":"208"] socket event: 2	thread=22
2024-07-08T20:51:57.216289Z	trace	envoy connection external/envoy/source/common/network/connection_impl.cc:737	[Tags: "ConnectionId":"208"] write ready	thread=22
2024-07-08T20:51:57.217113Z	trace	envoy connection external/envoy/source/common/network/connection_impl.cc:614	[Tags: "ConnectionId":"209"] socket event: 2	thread=22
2024-07-08T20:51:57.217127Z	trace	envoy connection external/envoy/source/common/network/connection_impl.cc:737	[Tags: "ConnectionId":"209"] write ready	thread=22
2024-07-08T20:51:57.217131Z	debug	envoy connection external/envoy/source/common/network/connection_impl.cc:746	[Tags: "ConnectionId":"209"] connected	thread=22
2024-07-08T20:51:57.217135Z	trace	envoy connection external/envoy/source/common/network/connection_impl.cc:469	[Tags: "ConnectionId":"209"] raising connection event 2	thread=22
2024-07-08T20:51:57.217139Z	trace	envoy connection external/envoy/source/common/network/connection_impl.cc:401	[Tags: "ConnectionId":"209"] readDisable: disable=true disable_count=0 state=0 buffer_length=0	thread=22
2024-07-08T20:51:57.217151Z	debug	envoy pool external/envoy/source/common/conn_pool/conn_pool_base.cc:328	[Tags: "ConnectionId":"209"] attaching to next stream	thread=22
2024-07-08T20:51:57.217164Z	debug	envoy pool external/envoy/source/common/conn_pool/conn_pool_base.cc:182	[Tags: "ConnectionId":"209"] creating stream	thread=22
2024-07-08T20:51:57.217169Z	trace	envoy connection external/envoy/source/common/network/connection_impl.cc:401	[Tags: "ConnectionId":"209"] readDisable: disable=false disable_count=1 state=0 buffer_length=0	thread=22
2024-07-08T20:51:57.217176Z	debug	envoy router external/envoy/source/common/tcp_proxy/upstream.cc:255	Attached upstream connection [C209] to downstream connection [C208]	thread=22
2024-07-08T20:51:57.217188Z	trace	envoy connection external/envoy/source/common/network/connection_impl.cc:401	[Tags: "ConnectionId":"208"] readDisable: disable=false disable_count=1 state=0 buffer_length=0	thread=22
2024-07-08T20:51:57.217195Z	debug	envoy filter external/envoy/source/common/tcp_proxy/tcp_proxy.cc:830	[Tags: "ConnectionId":"208"] TCP:onUpstreamEvent(), requestedServerName: 	thread=22
2024-07-08T20:51:57.217206Z	trace	envoy connection external/envoy/source/common/network/connection_impl.cc:614	[Tags: "ConnectionId":"209"] socket event: 2	thread=22
2024-07-08T20:51:57.217215Z	trace	envoy connection external/envoy/source/common/network/connection_impl.cc:737	[Tags: "ConnectionId":"209"] write ready	thread=22
2024-07-08T20:51:57.217218Z	trace	envoy connection external/envoy/source/common/network/connection_impl.cc:614	[Tags: "ConnectionId":"208"] socket event: 3	thread=22
2024-07-08T20:51:57.217221Z	trace	envoy connection external/envoy/source/common/network/connection_impl.cc:737	[Tags: "ConnectionId":"208"] write ready	thread=22
2024-07-08T20:51:57.217224Z	trace	envoy connection external/envoy/source/common/network/connection_impl.cc:654	[Tags: "ConnectionId":"208"] read ready. dispatch_buffered_data=0	thread=22
2024-07-08T20:51:57.217240Z	trace	envoy connection external/envoy/source/common/network/raw_buffer_socket.cc:25	[Tags: "ConnectionId":"208"] read returns: 8	thread=22
2024-07-08T20:51:57.217256Z	trace	envoy connection external/envoy/source/common/network/raw_buffer_socket.cc:39	[Tags: "ConnectionId":"208"] read error: Resource temporarily unavailable, code: 0	thread=22
2024-07-08T20:51:57.217262Z	trace	envoy filter external/envoy/source/common/tcp_proxy/tcp_proxy.cc:696	[Tags: "ConnectionId":"208"] downstream connection received 8 bytes, end_stream=false	thread=22
2024-07-08T20:51:57.217266Z	trace	envoy filter source/extensions/filters/network/metadata_exchange/metadata_exchange.cc:157	Alpn Protocol Not Found. Expected istio-peer-exchange, Got 	thread=22

and
2024-07-08T20:51:57.930528Z	debug	envoy connection external/envoy/source/extensions/transport_sockets/tls/ssl_socket.cc:368	[Tags: "ConnectionId":"203"] SSL shutdown: rc=0	thread=22
2024-07-08T20:51:57.930540Z	trace	envoy connection external/envoy/source/common/network/connection_impl.cc:614	[Tags: "ConnectionId":"185"] socket event: 2	thread=22
2024-07-08T20:51:57.930543Z	trace	envoy connection external/envoy/source/common/network/connection_impl.cc:737	[Tags: "ConnectionId":"185"] write ready	thread=22
2024-07-08T20:51:57.930560Z	debug	envoy connection external/envoy/source/extensions/transport_sockets/tls/ssl_socket.cc:368	[Tags: "ConnectionId":"185"] SSL shutdown: rc=0	thread=22
2024-07-08T20:51:57.930570Z	trace	envoy connection external/envoy/source/common/network/connection_impl.cc:614	[Tags: "ConnectionId":"173"] socket event: 2	thread=22
2024-07-08T20:51:57.930573Z	trace	envoy connection external/envoy/source/common/network/connection_impl.cc:737	[Tags: "ConnectionId":"173"] write ready	thread=22
2024-07-08T20:51:57.930591Z	trace	envoy connection external/envoy/source/common/network/connection_impl.cc:614	[Tags: "ConnectionId":"171"] socket event: 2	thread=22
2024-07-08T20:51:57.930598Z	trace	envoy connection external/envoy/source/common/network/connection_impl.cc:737	[Tags: "ConnectionId":"171"] write ready	thread=22
2024-07-08T20:51:57.930616Z	trace	envoy connection external/envoy/source/common/network/connection_impl.cc:614	[Tags: "ConnectionId":"173"] socket event: 2	thread=22
2024-07-08T20:51:57.930620Z	trace	envoy connection external/envoy/source/common/network/connection_impl.cc:737	[Tags: "ConnectionId":"173"] write ready	thread=22
2024-07-08T20:51:57.930623Z	trace	envoy connection external/envoy/source/common/network/connection_impl.cc:614	[Tags: "ConnectionId":"171"] socket event: 2	thread=22
2024-07-08T20:51:57.930625Z	trace	envoy connection external/envoy/source/common/network/connection_impl.cc:737	[Tags: "ConnectionId":"171"] write ready	thread=22
2024-07-08T20:51:57.930628Z	trace	envoy connection external/envoy/source/common/network/connection_impl.cc:614	[Tags: "ConnectionId":"163"] socket event: 2	thread=22
2024-07-08T20:51:57.930630Z	trace	envoy connection external/envoy/source/common/network/connection_impl.cc:737	[Tags: "ConnectionId":"163"] write ready	thread=22
2024-07-08T20:51:57.930648Z	debug	envoy connection external/envoy/source/extensions/transport_sockets/tls/ssl_socket.cc:368	[Tags: "ConnectionId":"163"] SSL shutdown: rc=0	thread=22
2024-07-08T20:51:57.930713Z	trace	envoy connection external/envoy/source/common/network/connection_impl.cc:614	[Tags: "ConnectionId":"207"] socket event: 3	thread=23
2024-07-08T20:51:57.930727Z	trace	envoy connection external/envoy/source/common/network/connection_impl.cc:737	[Tags: "ConnectionId":"207"] write ready	thread=23
2024-07-08T20:51:57.930731Z	trace	envoy connection external/envoy/source/common/network/connection_impl.cc:654	[Tags: "ConnectionId":"207"] read ready. dispatch_buffered_data=0	thread=23
2024-07-08T20:51:57.930750Z	trace	envoy connection external/envoy/source/extensions/transport_sockets/tls/ssl_socket.cc:126	[Tags: "ConnectionId":"207"] ssl read returns: 0	thread=23
2024-07-08T20:51:57.930755Z	trace	envoy connection external/envoy/source/extensions/transport_sockets/tls/ssl_socket.cc:166	[Tags: "ConnectionId":"207"] ssl error occurred while read: ZERO_RETURN	thread=23
2024-07-08T20:51:57.930758Z	trace	envoy connection external/envoy/source/extensions/transport_sockets/tls/ssl_socket.cc:202	[Tags: "ConnectionId":"207"] ssl read 0 bytes	thread=23
2024-07-08T20:51:57.930813Z	trace	envoy filter external/envoy/source/common/tcp_proxy/tcp_proxy.cc:778	[Tags: "ConnectionId":"206"] upstream connection received 0 bytes, end_stream=true	thread=23
2024-07-08T20:51:57.930819Z	trace	envoy connection external/envoy/source/common/network/connection_impl.cc:529	[Tags: "ConnectionId":"206"] writing 0 bytes, end_stream true	thread=23
2024-07-08T20:51:57.930824Z	debug	envoy connection external/envoy/source/common/network/connection_impl.cc:714	[Tags: "ConnectionId":"207"] remote close	thread=23
2024-07-08T20:51:57.930827Z	debug	envoy connection external/envoy/source/common/network/connection_impl.cc:278	[Tags: "ConnectionId":"207"] closing socket: 0	thread=23
2024-07-08T20:51:57.930872Z	trace	envoy connection external/envoy/source/common/network/connection_impl.cc:469	[Tags: "ConnectionId":"207"] raising connection event 0	thread=23
2024-07-08T20:51:57.930883Z	debug	envoy pool external/envoy/source/common/conn_pool/conn_pool_base.cc:495	[Tags: "ConnectionId":"207"] client disconnected, failure reason: 	thread=23
2024-07-08T20:51:57.930890Z	trace	envoy main external/envoy/source/common/event/dispatcher_impl.cc:228	item added to deferred deletion list (size=1)	thread=23
2024-07-08T20:51:57.930894Z	debug	envoy pool external/envoy/source/common/conn_pool/conn_pool_base.cc:463	invoking 1 idle callback(s) - is_draining_for_deletion_=false	thread=23
2024-07-08T20:51:57.930897Z	trace	envoy upstream external/envoy/source/common/upstream/cluster_manager_impl.cc:2209	Idle pool, erasing pool for host <IP_ADDRESS>:5672	thread=23
2024-07-08T20:51:57.930900Z	trace	envoy main external/envoy/source/common/event/dispatcher_impl.cc:228	item added to deferred deletion list (size=2)	thread=23
2024-07-08T20:51:57.930904Z	debug	envoy pool external/envoy/source/common/conn_pool/conn_pool_base.cc:215	[Tags: "ConnectionId":"207"] destroying stream: 0 remaining	thread=23
2024-07-08T20:51:57.930910Z	debug	envoy pool external/envoy/source/common/conn_pool/conn_pool_base.cc:463	invoking 0 idle callback(s) - is_draining_for_deletion_=false	thread=23
2024-07-08T20:51:57.930914Z	debug	envoy connection external/envoy/source/common/network/connection_impl.cc:146	[Tags: "ConnectionId":"206"] closing data_to_write=0 type=0	thread=23
2024-07-08T20:51:57.930920Z	debug	envoy connection external/envoy/source/common/network/connection_impl.cc:278	[Tags: "ConnectionId":"206"] closing socket: 1	thread=23
2024-07-08T20:51:57.931008Z	trace	envoy connection external/envoy/source/common/network/connection_impl.cc:469	[Tags: "ConnectionId":"206"] raising connection event 1	thread=23
2024-07-08T20:51:57.931085Z	trace	envoy filter external/envoy/source/common/tcp_proxy/tcp_proxy.cc:750	[Tags: "ConnectionId":"206"] on downstream event 1, has upstream = false	thread=23
2024-07-08T20:51:57.931136Z	trace	envoy conn_handler external/envoy/source/common/listener_manager/active_stream_listener_base.cc:126	[Tags: "ConnectionId":"206"] tcp connection on event 1	thread=23
2024-07-08T20:51:57.931172Z	debug	envoy conn_handler external/envoy/source/common/listener_manager/active_stream_listener_base.cc:136	[Tags: "ConnectionId":"206"] adding to cleanup list	thread=23
2024-07-08T20:51:57.931192Z	trace	envoy main external/envoy/source/common/event/dispatcher_impl.cc:228	item added to deferred deletion list (size=3)	thread=23
2024-07-08T20:51:57.931195Z	trace	envoy main external/envoy/source/common/event/dispatcher_impl.cc:228	item added to deferred deletion list (size=4)	thread=23
2024-07-08T20:51:57.931199Z	trace	envoy main external/envoy/source/common/event/dispatcher_impl.cc:122	clearing deferred deletion list (size=4)	thread=23
2024-07-08T20:51:57.931230Z	trace	envoy connection external/envoy/source/common/network/connection_impl.cc:614	[Tags: "ConnectionId":"205"] socket event: 3	thread=22
2024-07-08T20:51:57.931244Z	trace	envoy connection external/envoy/source/common/network/connection_impl.cc:737	[Tags: "ConnectionId":"205"] write ready	thread=22
2024-07-08T20:51:57.931250Z	trace	envoy connection external/envoy/source/common/network/connection_impl.cc:654	[Tags: "ConnectionId":"205"] read ready. dispatch_buffered_data=0	thread=22
2024-07-08T20:51:57.931265Z	trace	envoy connection external/envoy/source/extensions/transport_sockets/tls/ssl_socket.cc:126	[Tags: "ConnectionId":"205"] ssl read returns: 0	thread=22
2024-07-08T20:51:57.931269Z	trace	envoy connection external/envoy/source/common/network/connection_impl.cc:614	[Tags: "ConnectionId":"183"] socket event: 3	thread=23
2024-07-08T20:51:57.931270Z	trace	envoy connection external/envoy/source/extensions/transport_sockets/tls/ssl_socket.cc:166	[Tags: "ConnectionId":"205"] ssl error occurred while read: ZERO_RETURN	thread=22
2024-07-08T20:51:57.931273Z	trace	envoy connection external/envoy/source/common/network/connection_impl.cc:737	[Tags: "ConnectionId":"183"] write ready	thread=23
2024-07-08T20:51:57.931276Z	trace	envoy connection external/envoy/source/extensions/transport_sockets/tls/ssl_socket.cc:202	[Tags: "ConnectionId":"205"] ssl read 0 bytes	thread=22
2024-07-08T20:51:57.931277Z	trace	envoy connection external/envoy/source/common/network/connection_impl.cc:654	[Tags: "ConnectionId":"183"] read ready. dispatch_buffered_data=0	thread=23
2024-07-08T20:51:57.931282Z	trace	envoy filter external/envoy/source/common/tcp_proxy/tcp_proxy.cc:778	[Tags: "ConnectionId":"204"] upstream connection received 0 bytes, end_stream=true	thread=22
2024-07-08T20:51:57.931299Z	trace	envoy connection external/envoy/source/common/network/connection_impl.cc:529	[Tags: "ConnectionId":"204"] writing 0 bytes, end_stream true	thread=22
2024-07-08T20:51:57.931285Z	trace	envoy connection external/envoy/source/common/network/raw_buffer_socket.cc:25	[Tags: "ConnectionId":"183"] read returns: 0	thread=23
2024-07-08T20:51:57.931304Z	debug	envoy connection external/envoy/source/common/network/connection_impl.cc:714	[Tags: "ConnectionId":"205"] remote close	thread=22
2024-07-08T20:51:57.931308Z	debug	envoy connection external/envoy/source/common/network/connection_impl.cc:278	[Tags: "ConnectionId":"205"] closing socket: 0	thread=22
2024-07-08T20:51:57.931308Z	trace	envoy filter external/envoy/source/common/tcp_proxy/tcp_proxy.cc:778	[Tags: "ConnectionId":"182"] upstream connection received 0 bytes, end_stream=true	thread=23
2024-07-08T20:51:57.931320Z	trace	envoy connection external/envoy/source/common/network/connection_impl.cc:529	[Tags: "ConnectionId":"182"] writing 0 bytes, end_stream true	thread=23
2024-07-08T20:51:57.931325Z	debug	envoy connection external/envoy/source/common/network/connection_impl.cc:714	[Tags: "ConnectionId":"183"] remote close	thread=23
2024-07-08T20:51:57.931328Z	debug	envoy connection external/envoy/source/common/network/connection_impl.cc:278	[Tags: "ConnectionId":"183"] closing socket: 0	thread=23
2024-07-08T20:51:57.931340Z	trace	envoy connection external/envoy/source/common/network/connection_impl.cc:469	[Tags: "ConnectionId":"205"] raising connection event 0	thread=22
2024-07-08T20:51:57.931351Z	trace	envoy connection external/envoy/source/common/network/connection_impl.cc:469	[Tags: "ConnectionId":"183"] raising connection event 0	thread=23
2024-07-08T20:51:57.931367Z	debug	envoy pool external/envoy/source/common/conn_pool/conn_pool_base.cc:495	[Tags: "ConnectionId":"183"] client disconnected, failure reason: 	thread=23

Service Entry and Destination rule
apiVersion: networking.istio.io/v1alpha3
kind: ServiceEntry
metadata:
  name: dbapiruatus01
  namespace: microservices
spec:
  hosts:
  - dbapiruat01.xxxxxxxx
  ports:
  - number: 5432
    name: postgres
    protocol: TCP
  resolution: DNS
  location: MESH_EXTERNAL
---
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: disable-mtls-dbapiruatus01
  namespace: microservices
spec:
  host: dbapiruat01.xxxxxxxx
  trafficPolicy:
    tls:
      mode: DISABLE

Following information:
Azure Database for PostgreSQL single server
PostgreSQL version: 11
SSL settings: ENABLED
TLS setting: 1.2

Version
$ istioctl version
client version: 1.21.2
control plane version: 1.21.2
data plane version: 1.21.2 (90 proxies), 1.22.1 (45 proxies)
kubectl version
Server Version: v1.27.9

Additional Information
No response

I have a similar issue when connecting my Redis cluster https://github.com/istio/istio/discussions/51938. It seems that when using TCP, hosts are ignored in SE? Using IPs maybe works according to https://preliminary.istio.io/latest/blog/2018/egress-mongo/#egress-control-for-tls.

Does anyone know how to solve this problem when using a service entry with TLS (postgres in particular)?
I've seen that there are some issues on the topic, but none conclusive so far...
https://github.com/istio/istio/issues/33345
https://github.com/istio/istio/issues/47895


MATLAB fails to launch when extra whitespace is added to installPath setting

When the installPath setting has leading or trailing whitespace, MATLAB fails to launch.

This has been resolved in v1.2.5.


Remove monkey-patched LoginView methods in apps.py

In apps.py, two methods of LoginView have been monkey-patched with the decorated versions from django-axes. This makes the library methods unusable as they have been replaced with their decorated versions. This is a serious problem in django applications that do not use the vanilla django LoginView and create other LoginViews by inheriting from django LoginView.
Also, now django-axes can no longer be used with django-simple-captcha since a new LoginView with CaptchaFields cannot be created.
We had to create workarounds for this problem (https://github.com/freedombox/Plinth/pull/1155/files#diff-731aef8cc92c441d1d49eed734cb4f46) to be able to use django-simple-captcha.
This monkey-patching makes a huge assumption that users of this library never create inherited LoginViews. The documentation should be updated to let the users know how to decorate their LoginViews themselves.

I had the same feeling when doing the changes but I couldn't find a better way to do it.
If you have a better implementation please send a PR.
Thanks.

I have the same issue. I am using the Django 1.8.16 and its not working.

@camilonova, @JosephKiranBabu
I can think of two possible solutions for this issue:

Add a settings like AXES_MONKEYPATCH_DJANGO_AUTH and only patch the methods if it's True.
Pros:

Super-easy to do (a single if in apps.py should be enough)
Does not break BC

Cons:

It's still monkeypatching, so it's rather dirty

Provide an AxesLoginView that inherits from LoginView and overrides said methods. That would require people to change the way they use axes now, but I like it better, because it's explicit and there's no monkeypatching. The two overridden methods could even be provided by a mixin, like this:
class AxesLoginMixin(object):
    @method_decorator(axes_dispatch)
    def dispatch(self, request, *args, **kwargs):
        return super(AxesLoginMixin, self).dispatch(request, *args, **kwargs)

    @meethod_decorator(axes_form_invalid)
    def form_invalid(self, form):
        return super(AxesLoginMixin, self).form_invalid(form)

class AxesLoginView(AxesLoginMixin, LoginView):
    pass

That way, users using custom LoginViews could simply add a mixin to their classes to get the desired behaviour.
Pros:

No monkeypatching
Allows for more customisation in the future
Users only need to add a mixin to their custom views instead of patching two methods

Cons:

Breaks BC

What do you think?

IMO it is better to break backwards compatibility and have a clear migration & upgrade route with clean code than to continue doing horrible things.

@D3X Thank you, but no thank you.

@camilonova Thanks for the constructive critique and lots of great arguments!
You ask for better solutions, I provide you with not one, but two and you basically say "fuck you" instead of, I don't know, iterating on the idea? Saying why you don't like it?
That's not how you have a discussion with the community.

@D3X Michał, your response to @camilonova is offensive and unprofessional, and frankly way out of line for this discussion. I consider it a breach of our code of conduct and putting you on notice for it. I suggest to reconsider your words carefully and change the comment appropriately. An apology to @camilonova wouldn't hurt either.

@camilonova sorry if you felt offended by my comment. I overreacted.
Can you please elaborate on your response? What is it that you don't like about this solution?

@D3X Gladly I didn't get the last response.
I can see it's more complicated than what we have right now. I cannot see how this improves the current situation.
I'm sorry if I can't give you a more detailed explanation on this but my time is very limited.
This is just how I see it, but is not about me (personally), I'm just a contributor.
On this current approach I think it does not add any value, so I'm closing this issue.
I'm sure a better approach would be to create a PR and let others to review it.
Thank you.

Sorry, I'm new here and not familiar with the norms of this project.
This issue has been closed without resolution. Should it be assumed that it's closed as a won't fix?
Maybe I wasn't clear on what the exact problem is. I wasn't merely suggesting a refactoring. This is a bug that must be fixed. I should've probably stated the problem instead of giving a suggestion.
django-axes is doing infinite redirects to /locked when it reaches the threshold of failed logins. (https://github.com/freedombox/Plinth/issues/1138). The workaround I mentioned above is to fix that problem from the library user's side. This should ideally be fixed in the library itself.
I see that all the tests on the project are passing. Probably there isn't a test to handle this case?

@JosephKiranBabu as I mentioned earlier:

I'm sure a better approach would be to create a PR and let others to review it.


Is token access possible for APIs when using Auth Host Mode

I have Traefik 2/Keycloak/TFA solution running.
The config is using auth host mode and I get the expected re-direction to keycloak.mydomain/auth to supply credentials and re-direction back via auth.mydomain/_oauth to myapp.mydomin.
What I am trying to do now is to find some way to create a long lived access token to allow me to consume the traefik API with node-red (i.e. parse the JSON returned from https://traefik.mydomain/api/http/routers).
So far I have
client_id
client_secret
username
password
etc.

I want to call authentication_endpoint and/or token_endpoint generate a long lived (bearer?) token.
I want to add the resulting code to my node-red http call as a header or parameter:
https://traefik.mydomain/api/http/routers?whattoken=whatvalue
Can this be achieved and what are the general steps needed?
I'll happily document the scenario as an example if I get it to work.
best regards
Steve

The technique I use for this is to create static tokens and then apply them in rules, for example:
# Allow based on access token in query
rule.allow_api1.action = allow
rule.allow_api1.rule = Host(`traefik.mydomain`) && Path(`/api/http/routers`) && Query(`whattoken `, `whatvalue`)

# Allow based on access token in header
rule.allow_api2.action = allow
rule.allow_api2.rule = Host(`traefik.mydomain`) && Path(`/api/http/routers`) && Headers(`X-whattoken `, `whatvalue`)

# Allow based on access token in query or header
rule.allow_api3.action = allow
rule.allow_api3.rule = Host(`traefik.mydomain`) && Path(`/api/http/routers`) && (Query(`whattoken `, `whatvalue`) || Headers(`X-whattoken `, `whatvalue`))

Would that work?

Hi Thom,
thanks for getting back to me.
When you say create your own static tokens - are you using keycloak to generate them?
For you proposal, I can see that this can work in principle but I feel that this does not respect the segregation of duties though - as Traefik will be authorizing the request itself.
I found this article http://www.bubblecode.net/en/2016/01/22/understanding-oauth2/#Authorization_header#Access_token_usage helped my understand what I think I should be doing - i.e. adding Authorization header.
In my current setup I need to have a cookie called _forward_auth as the authorization. What I want is to have a bearer token so that i can make calls like this:
curl --location \
    --request GET 'https://whoami1.mydomain \
    /?access_token=IN0q...5RS_Q%3D|1590905678|email@address' \
    --header 'Authorization: Bearer IN0q...5RS_Q=|1590905678|email@address'

i.e. Either a URI parameter acess_token or an Authorization header
Is this possible with traefik_forward_auth?
best regards
Steve

Hello @thomseddon,
I have followed this thread https://keycloak.discourse.group/t/how-to-use-api-keys-with-keycloak/2390/14 and received a suggested flow for how to obtain and use a token.
To summarise
curl -v -d "client_id=keycloak-client" -d<EMAIL_ADDRESS>-d "password=password" -d "grant_type=password" -X POST "http://localhost:8080/auth/realms/realm-name/protocol/openid-connect/token" | jq -r .access_token;

This retrieves the access_token which is added to the Authorization: Bearer header in the following call:
curl --location --request GET 'https://whoami.mydomain/api/http/routers' \
--header 'Accept: application/json' \
--header 'Authorization: Bearer eyJhbG...L_J8g' \
--header 'Cookie: _forward_auth_csrf=958ae1cb0c5ff311123b81daad0052a5'

This call results in a redirection to the Keycloak logon scheme.
Can you tell me if this should be workable with the traefik_forward_auth setup?

Unfortunately, the only way rules can work is if the token is static (i.e. doesn't change once generated and doesn't need to be dynamically cycled), if this fits your situation you can generate the token, then do:
# Allow based on access token in header
rule.allow_api2.action = allow
rule.allow_api2.rule = Host(`traefik.mydomain`) && Path(`/api/http/routers`) && Headers(`Authorization `, `Bearer eyJhbG...L_J8g`)

However, if you would like the token to be generated and used dynamically, then I think this goes beyond the scope of how this app works.
A better approach may be to build a direct integration between your application and keycloak, as shown in the api key example: https://github.com/zak905/keycloak-api-key-demo/blob/master/rest-api-service/index.js (I'm assuming the client is your own application, if not it would be good to know what it is to understand your use case?).
You could still keep traefik-forward-auth for other services in the cluster, but either don't apply the middleware to your API application, or create a rule to allow requests through traefik-forward-auth, and handle the authentication yourself in the client :)

Thanks' for the feedback Thom. I'll work on getting nodeRed built in authentication working instead.
best regards
Steve

No problem, this is an interesting angle - in the future I hope to add different types of providers and perhaps an "api-key" provider would make sense.


prevent memory leak when writing before ready

while trying to add a callback function to flush in pino I got into a situation where I logged and flushed before the file was ready so the cb never got called

I just noticed that the branch name has nothing to do with the fix 😅

let's merge this so I can continue working on pino flush? (don't forget hacktoberfest 😅  I need some shirts 😂 )

Can you please release that so pinojs/pino#1827 can be merged?


Upgrade to gradle 4.1

Ran ./gradlew wrapper --gradle-version=4.1 to upgrade. Tested build and test tasks

Codecov Report

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

@@             Coverage Diff              @@
##             master     #784      +/-   ##
============================================
- Coverage     66.09%   66.07%   -0.02%
- Complexity     3937     3949      +12
============================================
  Files           343      343
  Lines         25926    26059     +133
  Branches       3241     3257      +16
============================================
+ Hits          17135    17218      +83
- Misses         7888     7934      +46
- Partials        903      907       +4

Impacted Files
Coverage Δ
Complexity Δ

...main/java/com.github.ambry.store/StoreMetrics.java
95.83% <0%> (-4.17%)
6% <0%> (ø)

.../com.github.ambry.store/StorageManagerMetrics.java
96.87% <0%> (-3.13%)
5% <0%> (ø)

.../main/java/com.github.ambry.store/HardDeleter.java
79.67% <0%> (-2.59%)
40% <0%> (-3%)

...b.ambry.network/BlockingChannelConnectionPool.java
64.03% <0%> (-2.2%)
8% <0%> (ø)

...in/java/com.github.ambry.store/BlobStoreStats.java
83.49% <0%> (-1.68%)
90% <0%> (-2%)

...m.github.ambry.replication/ReplicationMetrics.java
73.29% <0%> (-0.94%)
15% <0%> (ø)

.../com/github/ambry/account/HelixAccountService.java
90.18% <0%> (-0.78%)
41% <0%> (+9%)

...ls/src/main/java/com.github.ambry.utils/Utils.java
64.85% <0%> (-0.55%)
69% <0%> (ø)

...github.ambry.frontend/AmbryBlobStorageService.java
93.79% <0%> (-0.05%)
60% <0%> (+1%)

...n/java/com.github.ambry/store/DiskReformatter.java
0% <0%> (ø)
0% <0%> (ø)
:arrow_down:

... and 2 more

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 85c150c...7236ad5. Read the comment docs.

Were all these files manually changed or the upgrade process automatically changes them?
Also could you also run the allJar and idea targets?

@vgkholla All 3 files were autogenerated by the command mentioned in the description. Just tried idea, allJar, and clean. Getting an "Invalid or corrupt jarfile ambry.jar" error when running the jar generated by allJar, so let's hold off on merging this.


Update temporal-tables.md

typo

@TeddMcAdams : Thanks for your contribution! The author, @CarlRabeler, has been notified to review your proposed change.

verified correction


Remove old images from collectionView cells

At the moment cells show images of previous meals while loading new ones

See #44 discussion


WebGLPoints

When using WebGLPoints, how to make the target repeatedly displayed on the 180-degree meridian thanks

Duplicate of https://github.com/openlayers/openlayers/issues/11131

Is there any other way to solve it now? Thank you 🙏


Request: vertical base wallpaper

I was able to make a vertical version of the base wallpaper by pasting it over an Android wallpaper and fiddling with layer scale and position, but it would be nice to have a pre-made version for those who can't do that. Pretty much just a 9:16 version of the Android wallpaper, but with the Android logo removed.

Done: f761e88


Rename repository to 'qiskit-core'

Description
Rename all references to qiskit-sdk-py to the new repository name,
QISKit/qiskit-core, including a handful of instances where the
IBM/qiskit-sdk-py form was used.
Fixes #467
Motivation and Context

How Has This Been Tested?

Screenshots (if appropriate):
Types of changes

[ ] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

[ ] My code follows the code style of this project.
[ ] My change requires a change to the documentation.
[ ] I have updated the documentation accordingly.
[ ] I have read the CONTRIBUTING document.
[ ] I have added tests to cover my changes.
[ ] All new and existing tests passed.

Please note that after renaming the repository, the old URL will still be working (both in the github interface and in the remotes) - it might be advisable to announce the change a bit, for a cleaner transition and avoid confusion.
The PR also changes the string in some travis related files (the actual .travis.yml and the badge in the README) - it seems travis will be able to pick the renaming, but we will check after it is completed.

PLEASE NOTE: Even though local repository clones will still work after the renaming, it's highly encouraged to update local clones with the new URL:
git remote set-url origin https://github.com/QISKit/qiskit-core


Wrong type detection

When I calculating some values "on the fly" they are getting type LONGLONG and represented as strings in javascript. Which is wrong sometimes, for example FALSE represented as "0" which is truthy value in javascript.
Here is es6 code example to reproduce this issue
import mysql from 'mysql';

const pool = mysql.createPool({
  host: process.env.MYSQL_HOST,
  port: process.env.MYSQL_PORT,
  user: process.env.MYSQL_USER,
  password: process.env.MYSQL_PASSWORD,
  supportBigNumbers: true,
  bigNumberStrings: true,
  charset: 'UTF8MB4',
});

pool.query({
  sql: 'SELECT 0 AS zero, TRUE AS ok, 42 AS number, "text" as str, 3.13 AS floating',
  typeCast: (field, next) => {
    console.log(`"${field.name}" - ${field.type}`);
    return next();
  },
}, (err, res) => {
  console.log(res);
});

Which outputs following:
"zero" - LONGLONG
"ok" - LONGLONG
"number" - LONGLONG
"str" - VAR_STRING
"floating" - NEWDECIMAL
[ RowDataPacket { zero: '0', ok: '1', number: '42', str: 'text', floating: '3.13' } ]

But when I'm checking types in MySQL they are different:
mysql> CREATE TEMPORARY TABLE temp
    -> SELECT 0 AS zero, TRUE AS ok, 42 AS number, "text" as str, 3.13 AS floating;
Query OK, 1 row affected (0.00 sec)
Records: 1  Duplicates: 0  Warnings: 0

mysql> DESCRIBE temp;
+----------+--------------+------+-----+---------+-------+
| Field    | Type         | Null | Key | Default | Extra |
+----------+--------------+------+-----+---------+-------+
| zero     | int(1)       | NO   |     | 0       |       |
| ok       | int(1)       | NO   |     | 0       |       |
| number   | int(2)       | NO   |     | 0       |       |
| str      | varchar(4)   | NO   |     |         |       |
| floating | decimal(3,2) | NO   |     | 0.00    |       |
+----------+--------------+------+-----+---------+-------+
5 rows in set (0.00 sec)

mysql>

So why do types are different inside MySQL and node-mysql?

Hi @olessavluk, if you do a packet capture, you'll find that the type information is not detected by this module--it's actually part of the MySQL protocol and your MySQL server is saying that the type of that column is a LONGLONG, so that's how this module treats it.

Thank you @dougwilson !
This is really strange MySQL behaviour. Now I understand why bigNumberStrings set to false by default, because it can break things.

Yea, I don't quite understand how MySQL determines the types when not coming directly from a column, but in general it seems to just choose the largest possible type.


Insert implicit i(0) in snippets that don't have it

Everything else looks fine :+1:

Nice! Thanks a lot!


add javascript support as a language for expressions

Besides grel, python and clojure it would be wise to add javascript support.
Sometimes grel is just not enough, and in those cases I turn to python, but there are lots of developers pretty familiar with javascript.
The jvm has a pretty good support for js as a scripting language.

I guess that would be OK for now.  Although wonder about Java 16 and later https://github.com/mozilla/rhino#java-16-and-later

Also, Apache Hop uses org.mozilla.javascript it seems.
https://hop.apache.org/manual/latest/pipeline/transforms/javascript.html
https://github.com/apache/hop/blob/master/plugins/transforms/javascript/src/main/java/org/apache/hop/pipeline/transforms/javascript/ScriptValuesDialog.java#L63

org.mozilla.javascript and Rhino are the same thing, I think (or I would be really surprised if Mozilla maintained two different Javascript interpreters in Java)

Now I am scratching my head...
https://mvnrepository.com/search?q=org.mozilla.javascript
https://mvnrepository.com/artifact/org.mozilla/rhino

I have created an extension which adds support for Javascript as expression language:
https://github.com/wetneb/refine-js
So I am tentatively closing this.


Added Risk of Options support.

Added Risk of Options support as a soft dependency. Works in game per my testing. Didn't add an icon or anything though.

Hey, thanks for the pull request, adding support for that mod is something I'd planned but never got time/motivation to do it. There's a couple issues with your code though :

Although you added a SoftDependency, the way you implemented it makes the mod not work if they don't have Risk_Of_Options installed. Here's a tutorial on how to do it properly.
I get why you added spaces to entry names, but doing so will erase the previous values when people will update their mod, and I don't really want to do that. I'm pretty sure there's a way to change the display name of a ConfigEntry in Risk_Of_Options, and I would rather do that.

Thanks, I pushed a new version that should fix the issues. I'm a front-end person and I'm not very good with code. I tested with and without ROO and both worked with no issues.

Looks good to me ! I'll test everything works tomorrow ( not that I don't trust your tests, but I prefer double checking 😄 ) then I'll merge and push an update to Thunderstore.

Best to double check in case I missed something! Thanks!


handle ACDC of ACDC creation

fixes #8432

@amaltaro, Alan please review. Still need to be tested

It is tested now.
https://reqmgr2-dev.cern.ch/reqmgr2/fetch?rid=sryu_ACDC_ACDC_RelVal_Premix_sryu_180201_232602_4505

test this please

test this please

test this please

Actually it's not just putting those 3 lines back because now the concept of OriginalRequestType is different. With your latest changes, OriginalRequestType is the RequestType of the very first workflow, while before it was the RequestType of the parent workflow (the one being ACDC'ed).
All in all, it wasn't consistent and it isn't yet, since OriginalRequestType and OriginalRequestName are sort of no longer correlated.
It works, so I'm going to merge it and we can revisit it in the future if we want. I also tested updating Memory, Multicore and TimePerEvent and it works too. Thanks Seangchan!

Actually it's not just putting those 3 lines back because now the concept of OriginalRequestType is different. With your latest changes, OriginalRequestType is the RequestType of the very first workflow, while before it was the RequestType of the parent workflow (the one being ACDC'ed).

Yes I think we discussed before and if we keep the concept the patch is a little messy.
In the wrong run, it might be better to change it though.
We can change OriginalRequest -> ParentRequest.

Agreed!


Issue with Glow using Stereo Rendering - Rift Valley and Oculus Rift Support.

Glow shader glitches on stereo rendering like the one seen in the Rift Valley demo. It's exactly like this issue we are having: http://www.garagegames.com/community/forums/viewthread/131991
Steps to Repeat:

Open the rift valley demo
Select an object and set glow on the texture.
See it with stereo rendering.

Resolved


Reaction pages no longer render

Example
http://localhost:3000/reaction/D-Glucose 1-phosphate-->D-Glucose 6-phosphate
Due to problem with REST endpoint
https://api.datanator.info/reactions/kinlaw_by_name/?_from=0&size=1000&bound=tight&substrates=D-Glucose 1-phosphate&products=D-Glucose 6-phosphate

Example
http://localhost:3000/reaction/D-Glucose 1-phosphate-->D-Glucose 6-phosphate
Due to problem with REST endpoint
https://api.datanator.info/reactions/kinlaw_by_name/?_from=0&size=1000&bound=tight&substrates=D-Glucose 1-phosphate&products=D-Glucose 6-phosphate

I forgot to project out a non json-serializable object when I was changing how taxon distance was obtained. It has been fixed now.

Thanks!. Looks good now.


Download to CSV is working

Downloading the data on clicking download to csv .
As soon as the chart is loaded, if we click the toggle button on the top on righthand side of the chart, and on clicking download to csv - it is not downloading rather it will give you error as below.
_### Cannot assign to read only property 'data' of object '#'
TypeError: Cannot assign to read only property 'data' of object '#'
at m (http://localhost:3000/static/js/vendors-node_modules_react-apexcharts_dist_react-apexcharts_min_js.chunk.js:5803:22)
at http://localhost:3000/static/js/vendors-node_modules_react-apexcharts_dist_react-apexcharts_min_js.chunk.js:5822:34
at Array.map ()
at t.value (http://localhost:3000/static/js/vendors-node_modules_react-apexcharts_dist_react-apexcharts_min_js.chunk.js:5821:115)
at t.value (http://localhost:3000/static/js/vendors-node_modules_react-apexcharts_dist_react-apexcharts_min_js.chunk.js:8310:15)_
It should get dwonloaded if the chart is loaded already.

The below image is the chart loaded.

Am looking for a better suggestion or a good solution for the issue....Please respond as soon as possible.
Thank you.

Did not provide required reproduction


Try using the GraphQL API, for faster response times, and more flexibility on what you can request.

Try using the Replit GraphQL API, since it offers more flexible tooling for the client. We could try and make this a wrapper for easy interactions with the API.

yes, we already tried this and couldn't do it for python, thanks for the suggestion tho!


CVE-2020-15824 vulnerability in Okhttp

Our Dependency check software flagged the following dependency in Okhttp CVE-2020-15824. We wanted to log this as a vulnerability, but your policy states "Issues related to software not under our control (such as external dependencies)".
We noted that this vulnerability was fixed in Kotlin V1.4, but Okhttp is using 1.3.72. Are there any plans to upgrade Kotlin?

OkHttp does not use Kotlin's scripting. That being said, Kotlin 1.4 has not been released, but yes, we will upgrade when it's available.
On Tue, Aug 11, 2020, at 7:25 AM, johannesJemstep wrote:

Our Dependency check software flagged the following dependency in Okhttp CVE-2020-15824 https://nvd.nist.gov/vuln/detail/CVE-2020-15824. We wanted to log this as a vulnerability, but your policy states "Issues related to software not under our control (such as external dependencies)".

We noted that this vulnerability was fixed in Kotlin V1.4 https://blog.jetbrains.com/blog/2020/08/06/jetbrains-security-bulletin-q2-2020/, but Okhttp is using 1.3.72 https://github.com/square/okhttp/blob/master/build.gradle. Are there any plans to upgrade Kotlin?

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub https://github.com/square/okhttp/issues/6219, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAAQIEP2XPSMJ7IA6UN2TODSAETBLANCNFSM4P25Z4HA.

OkHttp does not use Kotlin's scripting. That being said, Kotlin 1.4 has not been released, but yes, we will upgrade when it's available.
…
On Tue, Aug 11, 2020, at 7:25 AM, johannesJemstep wrote: Our Dependency check software flagged the following dependency in Okhttp CVE-2020-15824 https://nvd.nist.gov/vuln/detail/CVE-2020-15824. We wanted to log this as a vulnerability, but your policy states "Issues related to software not under our control (such as external dependencies)". We noted that this vulnerability was fixed in Kotlin V1.4 https://blog.jetbrains.com/blog/2020/08/06/jetbrains-security-bulletin-q2-2020/, but Okhttp is using 1.3.72 https://github.com/square/okhttp/blob/master/build.gradle. Are there any plans to upgrade Kotlin? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#6219>, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAAQIEP2XPSMJ7IA6UN2TODSAETBLANCNFSM4P25Z4HA.

Thanks for the reply @JakeWharton. I will close this issue then, seeing that an upgrade to Kotlin 1.4 will happen when its released.

Unfortunately OkHttp 4.9.2 still uses a Kotlin version where CVE-2020-15824 and CVE-2020-29582 will set off the dependency check from OWASP.
CVE-2020-29582 should be fixed in Kotlin version 1.4.21. And the warning for CVE-2020-15824 seems to be a false positive as that is fixed with Kotlin 1.4.


Rust and WebAssembly working group meeting #36

Our next meeting will be Thursday, March 14th at 17:00 UTC.
Add agenda items here: https://paper.dropbox.com/doc/RustWebAssembly-WG-dcXi5F7Bqlvg10zd7dKve
As usual, we'll be holding open office hours, so if you have any questions about Rust and WebAssembly, feel free to add a bullet point to the agenda!
We use Zoom for video meetings, so make sure you've downloaded the client! (It's free, but you have to sign up.) Here is our meeting room: https://zoom.us/j/715879536
Anyone interested in Rust and WebAssembly is invited to join! Yes, that includes you!

Hello everyone, i hope that you recorded this meeting and it will be placed on YT soon ;) can't wait.

Thanks for the meeting everyone!
@ArekMiszcz it is up on youtube now!


Different templates for different toastr's

Hello,
is it possible to change the template for every toastr?
I tried something like this:
toastr.info("Document ready text", "Document ready header" , {
                'templates': {
                    'toast': 'new-document-toastr.html'
                },
                'extraData': {
                    'userDocument': userDocument
                }
            });

I added a template with the 'new-document-toastr.html' to the template cache. Because I want to use the standard toastr for other toastr messages I added the
"angular-toastr/dist/angular-toastr.tpls.js"
file to my index.html

It is not possible right now. I had lot of troubles with custom templates due to replace: true and I need to rewrite the whole css to fix that. Still will take a peek to see if I can workaround that for that feature.

What is the status with this feature? Is it possible to have multiple different custom templates at the same time now?


simple theorymaps and simple pushouts

This adds a new instance of AbsTheoryMap which maps generators to generators, rather than to complex terms. For this kind of map we can easily compute pushouts, which is a matter of renaming.
The universal property of these colimits is not yet implemented.
Also, this is all at the GAT data structure level, rather than the module level.

My thought is that we are going to use the multiple-inheritance branch instead of this, so this should not be merged, is that right @kris-brown?

I imagined them as two different means of doing the same thing - I'd be happy to re-implement this down the line (in case we discover a need for programmatically merging theories), using the underlying implementation in multiple-inheritance, so I think it's fine to put this branch on pause / close the PR for now.


Laravel 5.8 Shift

This pull request includes the changes for upgrading to Laravel 5.8. Feel free to commit any additional changes to the shift-19040 branch.
Before merging, you need to:

Checkout the shift-19040 branch
Review all pull request comments for additional changes
Update your dependencies for Laravel 5.8
Run composer update (if the scripts fail, add --no-scripts)
Thoroughly test your application (no tests?)

If you need help with your upgrade, check out the Human Shifts. You may also join the Shifty Coders Slack workspace to level-up your Laravel skills.

:x: Shift could not upgrade the following configuration files since they differed from the default Laravel version. You will need to compare these configuration files against the Laravel 5.8 configuration files and merge any changes:

[ ] config/app.php
[ ] config/database.php
[ ] config/logging.php
[ ] config/mail.php
[ ] config/queue.php
[ ] config/services.php

:warning: Laravel 5.8 introduced a set of AWS environment variables to help consolidate configuring the various AWS services. You should rename the following native environment variables to their new names. While you don't have to rename any custom environment variables you created for AWS services, you should consider following the new naming convention.

SQS_KEY to AWS_ACCESS_KEY_ID
SQS_SECRET to AWS_SECRET_ACCESS_KEY
SQS_REGION to AWS_DEFAULT_REGION
SES_KEY to AWS_ACCESS_KEY_ID
SES_SECRET to AWS_SECRET_ACCESS_KEY
SES_REGION to AWS_DEFAULT_REGION

:x: Laravel 5.8 has a development dependency for filp/whoops of ^2.0. You have a modified dependency for filp/whoops in your composer.json. You should review your dependency and ensure it meets the new version requirement.

:x: Laravel 5.8 has a development dependency for beyondcode/laravel-dump-server of ^1.0. You have a modified dependency for beyondcode/laravel-dump-server in your composer.json. You should review your dependency and ensure it meets the new version requirement.

:x: Laravel 5.8 has a development dependency for fzaninotto/faker of ^1.4. You have a modified dependency for fzaninotto/faker in your composer.json. You should review your dependency and ensure it meets the new version requirement.

:warning: Laravel 5.8 changed the TTL for the Cache methods from minutes to seconds. Shift automated this change, however, given the dynamic nature of PHP your application may still contain some TTL arguments in minutes.
While your application will still run, this would lead to early expiration for your cached values. You should review your caching calls to ensure the TTL was upgraded to seconds.

:warning: Laravel 5.8 changed several of the core contracts with new implementations and methods. You should review the Upgrade Guide for more detail on these respective changes:

Illuminate\Contracts\Validation\Validator

Shift found references to these contracts within:

[ ] app/Http/Controllers/Auth/RegisterController.php
[ ] app/Http/Requests/Request.php

:information_source: Laravel 5.8 changed the minimum requirement for password length from 6 characters to 8 character. To preserve the 6 character limit requires you to create a custom PasswordBroker. If possible, you should use this opportunity to update the password policy for your application to 8 characters.

:information_source: If you are using JSON values in your MySQL or MariaDB tables, the query builder now returns unquoted JSON values in Laravel 5.8.

:information_source: If you are using SQLite, the oldest supported version in Laravel 5.8 is SQLite 3.7.11. Laravel recommends running SQLite 3.8.8 or higher.

:information_source: Laravel 5.8 correctly pluralizes multi-word model names ending in a word with an irregular pluralization. For example, Laravel 5.7 incorrectly pluralized the table name for the UserFeedback model as user_feedbacks. Laravel 5.8 correctly pluralizes this table name as user_feedback.
If you were relying on this irregular pluralization, you should rename your table name or set the $table property for your model. If you were overriding this behavior by setting the $table property, you may remove it and now rely on the framework.

:information_source: The Nexmo and Slack notification channels have been extracted into first-party packages. To use these channels in your application, run the following command to require the respective packages:
composer require laravel/nexmo-notification-channel
composer require laravel/slack-notification-channel

:information_source: In Laravel 5.8, the env helper treats environment variables as immutable. As such, you may no longer change an environment variable at runtime. Instead, you may use a configuration value which can be retrieved using the config helper.

❌ Laravel 5.8 has a development dependency for beyondcode/laravel-dump-server of ^1.0. You have a modified dependency for beyondcode/laravel-dump-server in your composer.json. You should review your dependency and ensure it meets the new version requirement.

@driesvints, we have explicit references to versions of beyondcode/laravel-dump-server, filp/whoops and fzaninotto/faker in our composer.json. Are you happy I remove these and utilise the constraints which ship with Laravel or do we need those particular versions?

@joedixon you can remove dump server and bump the whoops and faker. whoops will go away anyway with the 6.0 shift but you don't need to remove it in this pr.

@driesvints I've been though all comments from the shift and updated the relevant parts of the app.
Can you take a look and see if you are happy? I'm assuming you'll want me to squash all the commits of this PR?

I made those tweaks @driesvints - let me know if good to go.

@joedixon looks good. Feel free to squash 👍

@driesvints this is good to go

I'll buy the 6.0 shift tomorrow


Note for CBA

Added note for CBA and Graph API

@chrisda FYI

Docs Build status updates of commit 4a42329:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

exchange/exchange-ps/exchange/Add-UnifiedGroupLinks.md
:white_check_mark:Succeeded
View (exchange-ps)

For more details, please refer to the build report.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
For any questions, please:Try searching the docs.microsoft.com contributor guidesPost your question in the Docs support channel

Docs Build status updates of commit bbf975d:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

exchange/exchange-ps/exchange/Add-UnifiedGroupLinks.md
:white_check_mark:Succeeded
View (exchange-ps)

For more details, please refer to the build report.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
For any questions, please:Try searching the docs.microsoft.com contributor guidesPost your question in the Docs support channel


I'm getting internal server error when requesting transcript

The request takes a very long time, even when I'm giving it a tiny audio file and using the tiny.en model, and it eventually always ends in an internal server error.
Could it be that the micro-service only accepts audio files in some subset of file formats / codecs? If yes, which ones?
I've tried .mp3 and .wav so far.
I was hoping that running the tiny.en model locally in my docker environment would return a result faster than using OpenAI's whisper API, but that does not seem to be the case.

Hi @Evertt can you please tell me how long is the audio and show me the internal server error?

Hi @Evertt can you please tell me how long is the audio and show me the internal server error?

Hi @Evertt can you please tell me how long is the audio and show me the internal server error?


add

add <h3-worldmap-demo> <h3-worldmap-projection-select>
display <h3-worldmap-demo> in dev/index.html

TODO

revise the file/folder structure
revise the responsibilities of components
revise names of components, properties, e.t.c.
revise communication between components
tidy up

Preliminary notes by @rudifa:

revise the file/folder structure:
[] will do as suggested, makes sense

revise the responsibilities of components
So, we shall have the 2 components exported by the package, H3Worldmap and
H3WorldmapProjectionSelect;  the H3WorldmapDemo will show one way to hook up these 2 components

revise names of components, properties, e.t.c.
So, eventId should be a fixed constant inside H3WorldmapProjectionSelect , right?
The label text could also be a fixed constant inside H3WorldmapProjectionSelect , right?

revise communication between components
TBD - I need to understand / try out the suggested mechanism

tidy up
TBD - simplify the use of AVAILABLE_PROJECTIONS, clarify naming

The more I consider the form of our list of available D3 geo projections, the more questions pop up:

why do we need an identifier in first place, to pick a projection in the projection attribute of our ‹h3-worldmap› element? There is no standard nomenclature for such identifiers in D3-geo;
we need a human representation of the projection name for the selector;
the only mapping we have at hand, between D3-geo projection builder functions and names, is the one @fil defined in a cell in a @d3/projection-comparison Observable notebook
so why wouldn't we use such name as our projection attribute value?

I have now a branch, add-h3-worldmap-demo-3 that implements all (I think) of improvements discussed in the 'revise' series above.
This branch is rebased on today's main  c937564 (upstream/main, origin/main, origin/HEAD, main)(2022-05-02 11:13:20 +0200)(GitHub).
The corresponding PR will replace PR#25.
h3-worldmap % git lg 5                                                                                [add-h3-worldmap-demo-3 L|✔]
* 1ee0dae (HEAD -> add-h3-worldmap-demo-3)(2022-05-02 13:45:34 +0200)(Rudi Farkas)h3-worldmap-projection-select: rename event to update-selected, simpify event dispatch; move in the import AVAILABLE_PROJECTIONS and its use from h3-worldmap-demo
* 769c9f7(2022-05-02 13:45:34 +0200)(Rudi Farkas)move  src/demo/h3-worldmap-demo.js -> dev/h3-worldmap-demo.js, src/demo/h3-worldmap-projection-select.js -> h3-worldmap-projection-select.js, update dev/index.html
* 14c9a32(2022-05-02 13:45:34 +0200)(Rudi Farkas)add <h3-worldmap-demo> <h3-worldmap-projection-select>, display in dev/index.html
* 0ed0363(2022-05-02 13:45:34 +0200)(Rudi Farkas).gitignore: add .DS_store
*   c937564 (upstream/main, origin/main, origin/HEAD, main)(2022-05-02 11:13:20 +0200)(GitHub)Adds `firstLayout()` lifecycle method and calls `_measureSVGElement()`
|\

Here we go

cherry-picked 2 commits (my work of this morning) on top of your commit 0ff599a
merged main into branch add-h3-worldmap-demo
@olange please review and test, and forget the PR#29, une entité de trop

Entia non sunt multiplicanda praeter necessitatem


fix: config install

Checklist

[ ] the contributor license agreement is signed
[ ] commit message follows commit guidelines
[ ] tests are included
[ ] screenshots are included showing significant UI changes
[ ] documentation is changed or added

Description of change

I just realize println might give the system enough time to load the element, so the error never happened so far. :thinking:

I can't replicate the issue at all :cry:


Extension issue

Issue Type: Bug
Extension Name: microsoft-authentication
Extension Version: 0.0.1
OS Version: Linux x64 5.15.8-76051508-generic
VS Code version: 1.60.1

:warning: We have written the needed data into your clipboard. Please paste! :warning:
{
	"messages": [],
	"activationTimes": {
		"codeLoadingTime": 274,
		"activateCallTime": 3,
		"activateResolvedTime": 3852,
		"activationReason": {
			"startup": false,
			"extensionId": {
				"value": "vscode.microsoft-authentication",
				"_lower": "vscode.microsoft-authentication"
			},
			"activationEvent": "onAuthenticationRequest:microsoft"
		}
	},
	"runtimeErrors": [],
	"runningLocation": 1
}

VS Code version: 1.60.1

Please update to latest version which is 1.63.2 and check again.


Republish config as an eslint plugin

This reformats the repository to work as an eslint plugin. This approach should allow us to drop in a small eslintrc into each project:
extends:
    "plugin:bodylabs/common"

And then invoke eslint with a minimum of command-line arguments.
This also makes eslint --fix easy to invoke, which is really nice.
Next, since a plugin can accommodate multiple configs, we can merge bodylabs-frontend-style into this repo, as a second named config. That should make it simpler to pull in these configs, and easier to keep everything in sync.

Neat 👍

👍  Awesome!
Just curious, are we going to do another migration round to get our important repos using this system now?

Yeah, we should update our important repos after this. I did blue-server as a test but we should probably update the other key repos as well.

Thanks Max and David.


Add survey table

Now that we are doing validations, we should merge this PR after review to add survey id to interviews

@tahini Can you review this please? Thanks!


subscriber: record and send a histogram of Task poll times

We currently send the total elapsed time that a task spends inside its poll function, but it'd be helpful to also include more statistics. This would help to see average poll time, which would make it easier to identify tasks that are "blocking" too long in their poll functions. It would also help to identify when only sometimes a poll takes too long. And we could eventually use this data in the console to show a warning of tasks with poll times that are too high.
Using a histogram to record this seems like a good balance, since a simple average can lose the spikiness of some polls. I imagine we can use something like hdrhistogram.

per @jonhoo, I believe hdrhistogram is also compact enough that we should be able to have a fairly small wire representation for sending them to the console.

This sounds like fun. I have some free time these days and if no one else is working on this already, I'd like to take this on. :)

You got it! Let us know if you have questions here, or you can join the #console channel at discord.gg/tokio.


Add basic const/static type inference

This adds basic const/static type inference discussed in #887.
Currently the inference does not work for const/static declared inside a block. In addition the inference does not work inside the bodies of const/static.

Looks good to me, thanks!
bors r+
(Btw, there's not really anything special about 'local' consts as opposed to functions or use statements within a body -- they're all just normal items, but contained in an 'anonymous' module...)


get rid of unused use_openssl.sh script

the script use_openssl.sh doesn't appear to be used by anyone (nor run by any tests)
make is no longer the recommended way to build, one should use bazel or CMake
simplify generated Makefile

Also see https://github.com/grpc/grpc/issues/19483

Known failures:
https://github.com/grpc/grpc/issues/21615


linuxPackages.ddcci-driver: 0.3.3 -> 0.4.1

Motivation for this change
I noticed that this was out of date while checking out-of-tree modules for compatibility with Linux 5.14.  All I've done with this update is test that it builds.
Things done

Built on platform(s)

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

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
21.11 Release Notes (or backporting 21.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[x] Fits CONTRIBUTING.md.

Breaks compat with pre ~5
https://gitlab.com/ddcci-driver-linux/ddcci-driver-linux/-/commit/7f2c8e73e9e9f11466473ef971b4c583b4a3ece8
error: builder for '/nix/store/jl58jx619hgf7qbi2m15v0k0818w0hii-ddcci-driver-4.19.205-0.4.1.drv' failed with exit code 2;
       last 10 log lines:
       >    55 | static_assert(sizeof_field(struct ddcci_device, module) > 8);
       >       |               ^~~~~~~~~~~~
       > make[5]: *** [/nix/store/phz1jcdpywc01k4hs7jm8156vjvf5bzi-linux-4.19.205-dev/lib/modules/4.19.205-hardened1/source/scripts/Makefile.build
:310: /build/source/ddcci/ddcci.o] Error 1
       > make[4]: *** [/nix/store/phz1jcdpywc01k4hs7jm8156vjvf5bzi-linux-4.19.205-dev/lib/modules/4.19.205-hardened1/source/Makefile:1549: _module
_/build/source/ddcci] Error 2
       > make[3]: *** [Makefile:146: sub-make] Error 2
       > make[2]: *** [Makefile:24: __sub-make] Error 2
       > make[2]: Leaving directory '/nix/store/phz1jcdpywc01k4hs7jm8156vjvf5bzi-linux-4.19.205-dev/lib/modules/4.19.205-hardened1/build'
       > make[1]: *** [Makefile:38: ddcci.ko] Error 2
       > make[1]: Leaving directory '/build/source/ddcci'
       > make: *** [Makefile:28: ddcci] Error 2
       For full logs, run 'nix log /nix/store/jl58jx619hgf7qbi2m15v0k0818w0hii-ddcci-driver-4.19.205-0.4.1.

@Artturin thanks, I've added that to meta.


Ideas on defining register class symbols in std::arch module for inline assembly

https://internals.rust-lang.org/t/pre-rfc-2-inline-assembly/11310/147?u=luojia

I agree with the response at https://internals.rust-lang.org/t/pre-rfc-2-inline-assembly/11310/150 . I don't think we can define arbitrary register classes, and I don't think we should define the built-in register classes as symbols.

As for now it's not possible as the dependencies the rustc relies on does not support this feature. Close by now, if there could be advancements in the future, this issue may be reopened.


test(groups): add unit tests for Groups API methods

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 16.13%. Comparing base (69780f4) to head (8415cb6).

Additional details and impacted files
@@            Coverage Diff             @@
##             main      #16      +/-   ##
==========================================
+ Coverage   12.90%   16.13%   +3.24%
==========================================
  Files          23       23
  Lines        1047     1054       +7
==========================================
+ Hits          135      170      +35
+ Misses        881      852      -29
- Partials       31       32       +1

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


created Chakra UI Docs Extension

Description
created  a new extension for seeing the docs of Chakra UI
Screencast

Checklist

[x] I read the extension guidelines
[x] I read the documentation about publishing
[x] I ran npm run build and tested this distribution build in Raycast
[x] I checked that files in the assets folder are used by the extension itself
[x] I checked that assets used by the README are placed outside of the metadata folder

Hi 👋
Thanks for your contribution 💪
Did you see this extension before making this?
It could be that your extension has some features that are not in the other one so you could contribute to that instead.

whoops! didn't saw this one when i was searching, it is very limiting so yeah i can contribute to this instead.
thanks for your suggestion.


Adds travis builds with sanitizers support

We could then add the whole generated fuzzing corpus to be tested (to test for regressions with new pull requests for instance)

Can you do a new PR with all commits squashed? Thanks!


wrap sub CLI

I have a CLI tool like jenkins-cli.jar, that tool is provided by Jenkins.
And i want to use click to build new CLI by composing that CLI.
I have below code snippets:
@click.command()
@click.option('--identifer', '-i', help="jenkins master identifer" , type=click.Choice(Settings.get_identifers()), required=True)
@click.argument('subcmds', nargs=-1)
@click.pass_context
def entry(*subcmds, **kwargs):
"""jenkins operation entry"""
t = Jenkins(**kwargs)
t.run()
The subcmds will be passed to CLI:
java -jar jenkins-cli -s -v
And the final CLI i execute in console like below:
[root@apiserver com.interface.jenkins]# ^C
[root@apiserver com.interface.jenkins]# python -m com.interface.jenkins -i 5g-cimaster-3 build test -s -v
Usage: main.py [OPTIONS] [SUBCMDS]...
Try "main.py --help" for help.
Error: no such option: -s
How can i bypass the click check for "-s" "-v", what i want it just gather the options and arguments and pass to the inner CLI, but it is blocked by the click options check rules.
I am looking forward your reply.

https://click.palletsprojects.com/en/7.x/advanced/#forwarding-unknown-options
Please use Stack Overflow for questions about your own code. This tracker is for issues related to the project itself. Be sure to include a minimal, complete, and verifiable example.


Support Multithread Execution in RSpec

RSpec today does not support parallel execution of tests in the core. There are bunch of gems that allow for parallel execution, but all of these are process based and not thread based.
With JRuby/Rubinius support proper threading today, and MRI being the only major Ruby with a GIL, it might make more sense for RSpec to start supporting threads now. I understand this a major change, and it might just make sense to do it in the timeframes for RSpec 3.0.
Integration Tests are mostly IO Bound, and the process model though works is a needless use of system resources. Threads here could work really well. With support for parallelization out of the box, and the fact that parallel tests will need tests to run in random order, will give a good incentive for people to write good isolated tests and run them much faster.
Here's the barebones API that I am looking at...
describe TestMeInParallel
  run_order :parallel

  it "does something" do
  end

  it "does something else" do
  end
end

Each describe block should allow for setting the order, so that folks can slowly start moving parts of their test-suite to parallel execution. In terms of over-all RSpec run order, I'd expect RSpec to do the same thing here, that Minitest does, that is run all the non parallel tests first in the event there's some shared state, and then run the tests that can execute in parallel.
P.S I decided to open this issue, after a quick chat with @myronmarston on Twitter. https://twitter.com/KarthikDot/status/424608731285176320

+1 (y)

Since 3.0 is now out, are there more concrete plans to have this be implemented for a 3.x release? Is there any kind of technical summary somewhere outlining the necessary changes for this to be done properly? Just thinking about lowering the barrier to iterating on the implementation.

Well someone has to go over things to find out what isn't thread safe first... Off the top of my head the biggest headache is probably going to be the global state sort of expected at RSpec.configuration

Since 3.0 is now out, are there more concrete plans to have this be implemented for a 3.x release?  Is there any kind of technical summary somewhere outlining the necessary changes for this to be done properly? Just thinking about lowering the barrier to iterating on the implementation.

All that has been discussed is in this thread.  But now is a great time to make more concrete plans, now that you've brought it up?

Well someone has to go over things to find out what isn't thread safe first...   Config is generally set before the first example runs, and then remains unchanged for the rest of the process.  Mutating config while examples are running is pretty non-standard, and I don't think we need to make RSpec.configuration mutation thread safe.  I think it's sufficient to document the multi-threaded mode with a list of caveats/unsupported things and mention RSpec.configuration mutation as one of them.
More generally, I think we need to define what the goal is.  Is it to get RSpec in a state where all public RSpec APIs can be used in any fashion while multithreaded example execution is taking place?  I think that's a hard goal to achieve, and is unnecessary to ship something useful we can iterate on.  Besides; I don't think it's ever fully achievable -- consider that if you use rspec-mocks to stub a class method, it's going to interfere with any other examples running at the same time that expect the method to be unstubbed.  This is simply how stubbing a globally accessible object works...it's not solvable by us; it's solvable by the user using better practices (such as dependency injection).
I think a better goal/plan would be:

Ship support for multi-threaded execution.  Announce it as an experimental feature in the initial release (much like refinements in Ruby 2.0).  Document it with known caveats (such as "RSpec configuration mutation is not supported from examples that are running concurrently").
Audit rspec-core, rspec-mocks and rspec-expectations for thread safety issues.  Solve the ones that have easy solutions, but I think it's OK to document the others in our caveat list.  (This is much like our :all/:context hooks -- they are documented as not supporting certain things).  Ideally, this audit would happen before the initial release of the multi-threaded execution support, but as long as our initial release is marked as experimental I think it's OK to do this after we first ship -- it would just have to be done before we remove the experimental label from the feature.

IMO, what we need to figure out first is:

How we want the multithreaded execution to work.
What API(s) we want to expose for controlling it.
How multithreaded execution interacts with formatters.

I think it's useful to be able to apply multithreaded execution to only part of your spec suite, so I think it's something that we'll want to support via example group metadata to opt-in to it.  A big question in my mind is: should it piggy back on :order metadata (e.g. :order => :parallel)?  Or be a separate metadata key?

Besides; I don't think it's ever fully achievable -- consider that if you use rspec-mocks to stub a class method, it's going to interfere with any other examples running at the same time that expect the method to be unstubbed. This is simply how stubbing a globally accessible object works...it's not solvable by us

This might be a totally idiotic thought that doesn't work, but could method stubbing come with some kind of locking? If a thread stubs Post.published, then if a subsequent thread tries to interact with Post by stubbing or calling Post.published (or any other method on Post, potentially?), it would have to first wait for the first thread/example to finish. I'm worried about the amount of sheer complexity this entails, though, assuming it's even realistic.

I think it's useful to be able to apply multithreaded execution to only part of your spec suite, so I think it's something that we'll want to support via example group metadata to opt-in to it.

I'd guess this is the safest way to get something functional out there and tried out.

How we want the multithreaded execution to work.
[...]
A big question in my mind is: should it piggy back on :order metadata (e.g. :order => :parallel)? Or be a separate metadata key?

How do you see order: :parallel (or any equivalent, like parallel: true) example groups affecting test ordering in relation to the whole suite? For example, if I have random test ordering for my test suite, and there are 100 example groups with 10 of them marked as running in parallel, do the parallel groups run first, together? Or does marking an example as parallel indicate that it can run concurrently with any other group?

Regarding stubbing, another possibility is to opt-in to parallelization for specific specs (or one could set the default for their spec suite as parallelizable and then opt-out for specific specs), and then raise an error if a spec marked as parallelizable tries to stub anything.

This might be a totally idiotic thought that doesn't work, but could method stubbing come with some kind of locking? If a thread stubs Post.published, then if a subsequent thread tries to interact with Post by stubbing or calling Post.published (or any other method on Post, potentially?), it would have to first wait for the first thread/example to finish. I'm worried about the amount of sheer complexity this entails, though, assuming it's even realistic.

That's an interesting idea that I hadn't considered.  It does sound complicated, though, and I suspect it would affect perf for non-multihreaded cases.  On top of that, we can't assume that another thread is rspec-core running another example. Sometimes users write specs that spawn threads, and the spawned thread can't be forced to block while waiting for the example thread to finish -- that would be a deadlock situation.

Regarding stubbing, another possibility is to opt-in to parallelization for specific specs (or one could set the default for their spec suite as parallelizable and then opt-out for specific specs), and then raise an error if a spec marked as parallelizable tries to stub anything.

It's not stubbing per-se that's the problem.  Consider that if you instantiate an object (such as an rspec-mocks double) and stub it and use it within that example, there are no parallelism conflicts, since no other examples have access to that locally created object.
The problem is that when you stub a globally accessible object, you're mutating a global object.  The more broad problem is global mutation (of which stubbing a globally accessible object is just one form).  Consider, for example, that if I'm writing a spec in rspec-core's suite, and I need RSpec.configuration.color? to return false for a particular example, I can either stub it or set RSpec.configuration.color = false (and then reset it after the example).  The effect is the same: RSpec.configuration.color? will return false, and any other example that depends upon it returning true will not pass while being run in parallel.
I'm convinced that the broader problem of global mutation in specs is not solvable or preventable by us.  Thus, I don't think we should even attempt to do anything for the "stubbing a global object" issue.

How do you see order: :parallel (or any equivalent, like parallel: true) example groups affecting test ordering in relation to the whole suite? For example, if I have random test ordering for my test suite, and there are 100 example groups with 10 of them marked as running in parallel, do the parallel groups run first, together? Or does marking an example as parallel indicate that it can run concurrently with any other group?

These are great questions.  First off, I think we would only support marking example groups as parallel, not individual examples.  The way RSpec runs the suite is to delegate to teach of the top-level example groups, which in turn run their direct examples and also delegate to nested example groups, etc.  Given that...there's really no way to run a single example in parallel with anything else when the group itself is not parallel.
Here's how I'm imagining this working:

At the top level, RSpec would partition its top-level groups into the parallel and non-parallel ones.  It would then run all the parallel groups concurrently.
Once all the parallel groups are done, it would run the non-parallel ones.  Alternately, we could run the non-parallel first but on non-GILd rubies (e.g. JRuby and RBX) the parallelism could provide a speed up on multi-core machines (which is pretty much everyone's machines these days...) so it seems desirable to run the parallel specs first.

One consequence of this is that once a group has been marked as parallel, we can't support anything nested under that to be marked as non-parallel, because there may be other global groups running at the same time.  Ideally, whatever API we have for this would make that clear, but doing so with metadata (which is desirable for consistency with the rest of RSpec) is tricky.  I'll have to think more about it.
One other thing: I imagine we're going to want to have a pool of N worker threads, where N is either configurable or inferred based on how many cores you have, or both.  And then each parallel group would put "jobs" -- nested example or groups -- onto the worker queues and the threads would pop jobs and process them. That way we keep the number of worker threads constant even as we fan out recursively to all the groups.

TL;DR - sadly, I believe it's too detrimental to consider at all (list of issues/alternatives given)
Just my 2 cents:

There will usually be hundreds of tests (and tens of files at least), while there will only be a few cores available - so running simultaneously a handful of rspec processes (each with a portion of all the tests) is as fast as you can get anyway - by contrast, "parallel" specs running under one roof (many threads in one process) will always be slower (if we ignore startup time).

If tests are really slow, that's often due to IO and heavy resource usage (e.g. databases, file systems, bandwidth, RAM) - and those resources may be more limited than cores anyway (e.g. database in Rails). The best solution is mocks (especially with mock verification) and/or adding points of indirection to avoid consuming those resources. Otherwise, just as you'd manage threads and worker queues, you'd have to manage every other resource. Since slow tests are mostly happening "outside" Ruby, it may make sense to only have those slow tests running in a "side" loop. E.g. each full-stack acceptance spec could run remotely on the first available warmed-up docker container from a pool.

Tests and threads and locks are hard. Add mocks and metaprogramming and random failures (--seed won't help and some failures will now become "hardware-dependent") and bugs in JRuby and Rubinius ... and it's probably not worth all dealing within one framework. The extra time spent debugging will quickly nullify any gains from parallel threads. The more locks are added, the slower the tests will be, while "not enough locks" means random errors. (Not to mention how many Ruby platform, interpreter and version specific patches may be needed to get things working). Turn on parallel execution and getting a few failures may mean spending lots of hours just complicating the tests (no benefits related to the app itself) to make them work. This means debugging tests instead of debugging the code being tested. Logging and tracing can also get messed up or become a lot more complicated than necessary.

"Smart workflows", "selective testing" and breaking up projects into smaller gems will pay off faster. Travis builds take long not because there are unused cores - but because there's simply so much work to do anyway. I'd guess statistically most runs involve at least one failure - and since human beings can't fix multiple issues in parallel - then having the RSpec "intelligently" discover the error by postponing tests "likely to succeed" will provide a much bigger productivity boost. And of course such features are much easier to implement without having to worry about breaking parallel testing.

RSpec maintenance costs - if people are going to have problems with this, it's going to be quite hard to understand and reproduce issues, forget fixing them - especially with things going wrong in before/after blocks.

For thread safety, you need exclusivity or independence. If you have exclusivity, there's no gain from parallelism. If you have independence - there's no need to run all the tests (unless you change all the methods in the codebase or global states/names).

Parallelizing code may actually get in the way of JRuby's current and future optimizations (I'm not sure about this, though).

Often time tests won't work if you run them one-by-one (e.g. for i in spec/**/*_spec.rb; do rspec $i; done).

I feel like the feature is exciting, but not really as practical as I'd wish it was. As an analogy - faster bandwidth does not necessarily make people more productive (no matter how true that seems at first).
I fear this would actually be detrimental (the number of test cases may just explode - while handling the corner cases and race conditions in the tests framework). And there would be a false sense of security - that having tests running in parallel is at all related to the tested code being thread safe.
I'd argue that instead of faster tests we need better libraries/foundations. And better libraries are going to happen as a result of better tools, not "faster tools".
On the flipside, I'd say that there's a common denominator between managing jobs for worker queues and workflow-related features ("smart selective testing", minimal-reruns based on coverage, realtime failure reporting, etc.).

This is mostly about being thread safe so we can be used in a threaded environment, not necessarily about parallel execution ourselves. Theres no harm in general in being thread safe with our code even if we don't go down the threaded runner route.

@JonRowe -

being thread safe so we can be used in a threaded environment

I have no idea what that means in practice. If you take away parallel execution, where's the need for thread safety? Single thread = thread safe.
Even if e.g. a user uses RSpec functionality (expect, etc.) from within different threads (which they created within a single test) - that seems like testing RSpec's internal thread safety for no reason (instead of testing their own code). It's up to the user to synchronize/join threads/queue calls - so those called from the main thread.
I don't see a reason for RSpec to be internally thread safe if we take parallel execution out of the picture.

We're designed to be extensible, so we should be good citizens, being thread safe if it doesn't effect our performance unduly is just being nice.

being thread safe so we can be used in a threaded environment
I have no idea what that means in practice. If you take away parallel execution, where's the need for thread safety? Single thread = thread safe.

I have a concrete use case for thread safety: I run custom matchers which test web apps via the network. I use Sidekiq (thread-based queuing) to run many tests in parallel. This is slow-IO-bound, and so I run as many workers as I can, constrained only by RAM in the machine — not CPU cores.
Now, since RSpec isn't thread-safe, each of these threaded workers must start up and shell out to a Ruby/RSpec process. And so I can only run about 10 workers concurrently on a typical 512MB Heroku Dyno. But if RSpec were thread-safe, I could increase the concurrency many times over.
I realize this is not a common use case. It is, though, one more datapoint in favor of 'thread-safety'. IMO heading towards thread-safety would be a good goal: avoiding global state and favoring immutability and idempotence are good practices.
@e2 @JonRowe

@e2 Regarding parallelizing tests using threads: Since in MRI Ruby at least parallel execution is only available when the GIL is released (that is when I/O happens) having a setup of N processes and M threads is very useful for test suites that are I/O intensive.
It's pointless to wait for database queries to complete while other tests could be run.

@thedrow - you can simply use parallel_tests or something. This is better, since each process can have it's own database. You're not worried by RAM here, so multiple processes is not your constraint.
@dogweather - you want threads because of RAM savings. Fair enough. It's a valid use case for me. The only reason it's not typical is because usually integration tests are frequently run on powerful desktops.
The two "must have threads" cases for me are: not enough RAM and process startup overhead.

I still think that the tests will run faster.
We can try to compare with MiniTest.

@thedrow I just happened to read this, Exploring Minitest Concurrency which found pretty substantial gains in JRuby and Rubinius.

Please note our goal here is to be thread safe in order to enable other people to parallelise RSpec for the moment, were not talking about making RSpec run parallel itself just yet.

Right. So if I understand it, RSpec has the makings of being threadsafe. runner.rb creates a new Runner instance to handle each run.
def self.run(args, err=$stderr, out=$stdout)
  ...
  new(options).run(err, out)
end

So whats the status on becoming thread safe?

No change, if you'd like to take up the mantle go for it!

We're designed to be extensible, so we should be good citizens, being thread safe if it doesn't effect our performance unduly is just being nice.

I agree with this in theory, though suspect that in practice @e2's concerns may be more pragmatic - the cost of retrofitting thread safety on such a large project may be prohibitive. I also worry about stuff like #2064.
Leaving open because I'd love someone to prove me wrong :)

Back linking https://github.com/rspec/rspec-rails/issues/2104

Add support for Rails 6 built-in Parallel Testing
Use Rails 6 built-in parallelizer API for running parallel RSpec executors
https://edgeguides.rubyonrails.org/testing.html#parallel-testing
https://github.com/rails/rails/pull/31900#issuecomment-374299402

Going to bump this, mostly because the "Ractor" features in Ruby 3 might make such a feature considerably cheaper.


fix(editor): Make "Z" suffix optional in Monaco's date parsing definition (fixes #149).

Description

fix(editor): Make "Z" suffix optional in Monaco's date parsing definition.

Validation performed

Repeated the reproduction steps in #149 and observed the date getting colored as green as expected.

Summary by CodeRabbit

New Features

Enhanced date string matching in the Monaco editor to optionally include the 'Z' character.

Bug Fixes

Improved flexibility in date format recognition for better compatibility.

For the PR title, how about:
fix(editor): Make "Z" suffix optional in the custom Monaco log language definition (fixes #149).

With just "Z" in the title there could be a lack of context. shall we mention the "date"?
e.g.,
fix(editor): Make "Z" suffix optional in the custom Monaco log language's date definition (fixes #149).

With just "Z" in the title there could be a lack of context. shall we mention the "date"? e.g.,
fix(editor): Make "Z" suffix optional in the custom Monaco log language's date definition (fixes #149).

How about
fix(editor): Make "Z" suffix optional in date token of the custom Monaco log language definition (fixes #149).


[BUG] Questtracker cuts off objective title

Module Version: v0.7.11
Describe the bug
When creating an objective with more than 2 words, it will get cut off in the quest tracker. I think the problem is, that the quest tracker converts each space into a newline. This only happens for objectives yet to be completed. Completed objectives are shown as expected.
To Reproduce
Steps to reproduce the behavior:

Create new quest
Create an objective called "Objective with a really long title"
Activate the quest
Open quest tracker
Click on the active quest
See cut off objective (Screenshots below)

Expected behavior
Show the complete objective title in the quest tracker for all non-completed quests.
Screenshots
Quest with long objective

Completed quest

Another quest with a minimal 3 word objective

Browser:

Foundry NodeJS-Standalone

Foundry Version: v10.291
Game System: Splittermond

Quite likely this is a CSS conflict with the game system or another module. Can you try disabling all modules and check again. Then try another game system like dnd5e and check again. If this was a common occurrence I would have known about it before now. There was recently reported another game system that also improperly scoped its CSS / styles which you can read about here: #30.

I did detect some potential style conflicts with the game system, but this seems to be a conflict with another module that you are using. FQL scopes its styles appropriately, but not all other Foundry packages may use good practices. Since it is not the game system at fault per se you'll just have to work through the modules you have enabled to figure out which one is misbehaving. Once you find it feel free to post a message here and I'll create an issue on the offending modules repository to make a note of the conflict.
Here is a pict when I have Splittermond loaded and really long quest objectives:

Oh yeah. Sorry for not testing all modules earlier.
The culprit is JTCS - Art Gallery.
It does add buttons on the lower left of documents, that maybe interfere here:

Can you still fix it, since it works for completed objectives or should I contact the creator of JTCS?

HI @gsterling. I have opened an issue with the JCTS module. Looking through the issues in that repository there are several other clashes with other modules and possibly even game systems. It indeed is an issue that JCTS needs to fix and not FQL. As things go the JCTS module uses many non-specific CSS class names that can easily override or conflict with properly scoped CSS. A bit more details on the specific conflicting CSS rule from JCTS is in this issue which you can subscribe to for any updates when JCTS makes them.
https://github.com/Evannessa/Journal-To-Canvas-Slideshow/issues/48
I'm going to close this issue as won't fix as the problem is not with FQL.


⚠ Bofrost.lu has degraded performance

In 25bced6, Bofrost.lu (https://www.bofrost.lu) experienced degraded performance:

HTTP code: 200
Response time: 825 ms

Resolved: Bofrost.lu performance has improved in cc89941 after 24 minutes.


FEAT: Update Tableau Parquet files based on S3 Metdata Version field

Previously, all Tableau parquet files were being deleted and re-created on every application deployment.
This change utilizes the S3 Metadata head field to store a lamp_version value to determine when datasets should be re-freshed / re-created.
Asana Task: https://app.asana.com/0/1189492770004753/1206729585163530

i'm tempted to say that the version of the tableau file should be tied to the version of lamp itself rather than a version we increment when we feel we need to.
this would result in move overwrites then we strictly need, but it would make some forms of debugging easier if we could look at a file and know the conditions it was made under. i was thinking of tying them to minor versions of lamp, so when we jump from 1.0.6 to 1.1.0 it would require a bump.
that would require we have a method for determining the version, that we run minor version bumps when this changes for any of our public files, and that we have a way to run version bumps on staging without triggering prod deploys.


Establish "Terms of service"

Please check this out: https://docs.google.com/document/d/1t4t4jherqq4CJMy4jJAZtMb3-0fPEIr1yO9UG9sVuA4/edit?usp=sharing
@SofiaBee-W @khammami


feat: IDSSE Dataset

This PR adds the initial version of the dataset accompanying the paper "An integrated dataset of synchronized spatiotemporal and event data in elite soccer" which is currently in submission at Nature Scientific Data. The dataset contains seven full matches of position and event data from the German Bundesliga first and second division.
This PR should be fully functional, however documentation, testing and cosmetics will be improved in the next commits.

Hi @manuba95 and @VellaRo
one more general comment: I've noticed  you have been using the requests module for file downloads in the added parsers/datasets. Is there a reason for it? I know we have it as a transitive dependency, but so far we've been relying exclusively on urllib. I know requests is widely recommend and liked, but all we ever going to do http wise is send get requests, so basic functionality only. And that's always going to be faster with urllib as we don't need to load a gazillion fancy request features. (we might want to update to urllib3, though).
Reason I'm asking is because we have dedicated download functions in the io/utils.py submodule, but the new parsers are deviating from this. I'd prefer if we'd think about this and see if we can find a unified way, or at least have good reasons should we end up with multiple download strategies/packages/submodules.
Any thoughts?

Fully agree on that! Simply a misunderstanding from my side on what the download functions in the utils would do. Changed it in the wrapper function. @vellaro I suggest you do the same in your respective features as this is a pretty easy fix.