UNAVAILABLE:upstream connect error or disconnect/reset before headers. reset reason: connection failure

Bug description
When I set this disablePolicyChecks: false in istio installation it's giving me below error:

UNAVAILABLE:upstream connect error or disconnect/reset before headers. reset reason: connection failure

Expected behavior
It should run the services respecting the policy checks.
Steps to reproduce the bug
Install istio using disablePolicyChecks: false
Version (include the output of istioctl version --remote and kubectl version and helm version if you used Helm)
1.3.5
1.14.8
How was Istio installed?
helm template
Environment where bug was observed (cloud vendor, OS, etc)
AKS
policyCheckFailOpen is set to false
Please let me know if you need detailed logs of any specific pod.

Have you installed istio-policy? Do you have istio-policy running at all?

@kyessenov Yes.
istio-policy-69c8bbd685-7k6gx               2/2     Running     0          58m

@kyessenov Please let me know if you need additional logs information. Thanks!

I suspect something went wrong with your install. The error you are seeing is because of a failure to establish a connection to istio-policy. Do you know if you enabled control plane security? Maybe istio-policy has mTLS on but mixer client is not using TLS?

So, Control plane security is controlPlaneSecurityEnabled: false and mTLS is true
mtls:
    # Default setting for service-to-service mtls. Can be set explicitly using
    # destination rules or service annotations.
    enabled: true

@kyessenov Let me share the entire config file and the way I installed on AKS.
helm template install/kubernetes/helm/istio-init --name istio-init --namespace istio-system --set certmanager.enabled=true | kubectl apply -f -
helm template install/kubernetes/helm/istio --name istio --namespace istio-system -f ../istio_dev_values.yaml | kubectl apply -f -

istio_dev_values.yaml
# Top level istio values file has the following sections.
#
# global: This file is the authoritative and exhaustive source for the global section.
#
# chart sections: Every subdirectory inside the charts/ directory has a top level
#       configuration key in this file. This file overrides the values specified
#       by the charts/${chartname}/values.yaml.
#       Check the chart level values file for exhaustive list of configuration options.

#
# Gateways Configuration, refer to the charts/gateways/values.yaml
# for detailed configuration
#
gateways:
  enabled: true
  istio-ingressgateway:
    loadBalancerIP: xx.xx.xx.xx
    externalTrafficPolicy: Local
    serviceAnnotations:
      service.beta.kubernetes.io/azure-load-balancer-resource-group: test-rg-name
    sds:
      enabled: true
    resources:
      requests:
        cpu: 200m
        memory: 128Mi
      limits:
        cpu: 1000m
        memory: 256Mi
  istio-egressgateway:
    enabled: true

#
# sidecar-injector webhook configuration, refer to the
# charts/sidecarInjectorWebhook/values.yaml for detailed configuration
#
sidecarInjectorWebhook:
  enabled: true
  rewriteAppHTTPProbe: true

#
# galley configuration, refer to charts/galley/values.yaml
# for detailed configuration
#
galley:
  enabled: true

#
# mixer configuration
#
# @see charts/mixer/values.yaml, it takes precedence
mixer:
  policy:
    # if policy is enabled the global.disablePolicyChecks has affect.
    enabled: true

  telemetry:
    enabled: true
    resources:
      requests:
        cpu: 100m
        memory: 128Mi
      limits:
        cpu: 200m
        memory: 128Mi
#
# pilot configuration
#
# @see charts/pilot/values.yaml
pilot:
  enabled: true
  resources:
    requests:
      cpu: 20m
      memory: 128Mi
    limits:
      cpu: 40m
      memory: 128Mi

#
# security configuration
#
security:
  enabled: true

#
# nodeagent configuration
#
nodeagent:
  enabled: false

#
# addon grafana configuration
#
grafana:
  enabled: true

#
# addon prometheus configuration
#
prometheus:
  enabled: true

#
# addon jaeger tracing configuration
#
tracing:
  enabled: true
  zipkin:
    resources:
      requests:
        cpu: 20m
        memory: 128Mi
      limits:
        cpu: 40m
        memory: 128Mi

#
# addon kiali tracing configuration
#
kiali:
  enabled: true
  dashboard:
    jaegerURL: "http://jaeger-query:16686"
    grafanaURL: "http://grafana:3000"

#
# addon certmanager configuration
#
certmanager:
  enabled: true
  email<EMAIL_ADDRESS>  tag: "v0.10.1"
  extraArgs:
    - --webhook-namespace=istio-system

#
# Istio CNI plugin enabled
#   This must be enabled to use the CNI plugin in Istio.  The CNI plugin is installed separately.
#   If true, the privileged initContainer istio-init is not needed to perform the traffic redirect
#   settings for the istio-proxy.
#
istio_cni:
  enabled: false

# addon Istio CoreDNS configuration
#
istiocoredns:
  enabled: false

# Common settings used among istio subcharts.
global:
  # Default hub for Istio images.
  # Releases are published to docker hub under 'istio' project.
  # Daily builds from prow are on gcr.io
  hub: docker.io/istio

  # Default tag for Istio images.
  tag: ISTIO_VERSION

  # Comma-separated minimum per-scope logging level of messages to output, in the form of <scope>:<level>,<scope>:<level>
  # The control plane has different scopes depending on component, but can configure default log level across all components
  # If empty, default scope and level will be used as configured in code
  logging:
    level: "default:info"

  # monitoring port used by mixer, pilot, galley and sidecar injector
  monitoringPort: 15014

  k8sIngress:
    enabled: false
    # Gateway used for k8s Ingress resources. By default it is
    # using 'istio:ingressgateway' that will be installed by setting
    # 'gateways.enabled' and 'gateways.istio-ingressgateway.enabled'
    # flags to true.
    gatewayName: ingressgateway
    # enableHttps will add port 443 on the ingress.
    # It REQUIRES that the certificates are installed  in the
    # expected secrets - enabling this option without certificates
    # will result in LDS rejection and the ingress will not work.
    enableHttps: false

  proxy:
    # Configuration for the proxy init container
    init:
      resources:
        limits:
          cpu: 100m
          memory: 50Mi
        requests:
          cpu: 10m
          memory: 10Mi
    image: proxyv2

    # cluster domain. Default value is "cluster.local".
    clusterDomain: "cluster.local"

    # Resources for the sidecar.
    resources:
      requests:
        cpu: 100m
        memory: 128Mi
      limits:
        cpu: 200m
        memory: 256Mi

    # Controls number of Proxy worker threads.
    # If set to 0, then start worker thread for each CPU thread/core.
    concurrency: 2

    # Configures the access log for each sidecar.
    # Options:
    #   "" - disables access log
    #   "/dev/stdout" - enables access log
    accessLogFile: "/dev/stdout"

    # Configure how and what fields are displayed in sidecar access log. Setting to
    # empty string will result in default log format
    accessLogFormat: ""

    # Configure the access log for sidecar to JSON or TEXT.
    accessLogEncoding: JSON

    # Configure envoy gRPC access log service.
    envoyAccessLogService:
      enabled: false
      host: # example: accesslog-service.istio-system
      port: # example: 15000
      tlsSettings:
        mode: DISABLE # DISABLE, SIMPLE, MUTUAL, ISTIO_MUTUAL
        clientCertificate: # example: /etc/istio/als/cert-chain.pem
        privateKey: # example: /etc/istio/als/key.pem
        caCertificates: # example: /etc/istio/als/root-cert.pem
        sni: # example: als.somedomain
        subjectAltNames: []
        # - als.somedomain
      tcpKeepalive:
        probes: 3
        time: 10s
        interval: 10s

    # Log level for proxy, applies to gateways and sidecars.  If left empty, "warning" is used.
    # Expected values are: trace|debug|info|warning|error|critical|off
    logLevel: ""

    # Per Component log level for proxy, applies to gateways and sidecars. If a component level is
    # not set, then the global "logLevel" will be used. If left empty, "misc:error" is used.
    componentLogLevel: ""

    # Configure the DNS refresh rate for Envoy cluster of type STRICT_DNS
    # This must be given it terms of seconds. For example, 300s is valid but 5m is invalid.
    dnsRefreshRate: 300s

    # Automatic protocol detection uses a set of heuristics to
    # determine whether the connection is using TLS or not (on the
    # server side), as well as the application protocol being used
    # (e.g., http vs tcp). These heuristics rely on the client sending
    # the first bits of data. For server first protocols like MySQL,
    # MongoDB, etc., Envoy will timeout on the protocol detection after
    # the specified period, defaulting to non mTLS plain TCP
    # traffic. Set this field to tweak the period that Envoy will wait
    # for the client to send the first bits of data. (MUST BE >=1ms)
    protocolDetectionTimeout: 100ms

    #If set to true, istio-proxy container will have privileged securityContext
    privileged: false

    # If set, newly injected sidecars will have core dumps enabled.
    enableCoreDump: false

    # Image used to enable core dumps. This is only used, when "enableCoreDump" is set to true.
    enableCoreDumpImage: ubuntu:xenial

    # Default port for Pilot agent health checks. A value of 0 will disable health checking.
    statusPort: 15020

    # The initial delay for readiness probes in seconds.
    readinessInitialDelaySeconds: 1

    # The period between readiness probes.
    readinessPeriodSeconds: 2

    # The number of successive failed probes before indicating readiness failure.
    readinessFailureThreshold: 30

    # istio egress capture whitelist
    # https://istio.io/docs/tasks/traffic-management/egress.html#calling-external-services-directly
    # example: includeIPRanges: "<IP_ADDRESS>/16,<IP_ADDRESS>/16"
    # would only capture egress traffic on those two IP Ranges, all other outbound traffic would
    # be allowed by the sidecar
    includeIPRanges: "*"
    excludeIPRanges: ""
    excludeOutboundPorts: ""

    # pod internal interfaces
    kubevirtInterfaces: ""

    # istio ingress capture whitelist
    # examples:
    #     Redirect no inbound traffic to Envoy:    --includeInboundPorts=""
    #     Redirect all inbound traffic to Envoy:   --includeInboundPorts="*"
    #     Redirect only selected ports:            --includeInboundPorts="80,8080"
    includeInboundPorts: "*"
    excludeInboundPorts: ""

    # This controls the 'policy' in the sidecar injector.
    autoInject: enabled

    # Sets the destination Statsd in envoy (the value of the "--statsdUdpAddress" proxy argument
    # would be <host>:<port>).
    # Disabled by default.
    # The istio-statsd-prom-bridge is deprecated and should not be used moving forward.
    envoyStatsd:
      # If enabled is set to true, host and port must also be provided. Istio no longer provides a statsd collector.
      enabled: false
      host: # example: statsd-svc.istio-system
      port: # example: 9125

    # Sets the Envoy Metrics Service address, used to push Envoy metrics to an external collector
    # via the Metrics Service gRPC API. This contains detailed stats information emitted directly
    # by Envoy and should not be confused with the the Istio telemetry. The Envoy stats are also
    # available to scrape via the Envoy admin port at either /stats or /stats/prometheus.
    #
    # See https://www.envoyproxy.io/docs/envoy/latest/api-v2/config/metrics/v2/metrics_service.proto
    # for details about Envoy's Metrics Service API.
    #
    # Disabled by default.
    envoyMetricsService:
      enabled: false
      host: # example: metrics-service.istio-system
      port: # example: 15000

    # Specify which tracer to use. One of: zipkin, lightstep, datadog, stackdriver.
    # If using stackdriver tracer outside GCP, set env GOOGLE_APPLICATION_CREDENTIALS to the GCP credential file.
    tracer: "zipkin"

  proxy_init:
    # Base name for the proxy_init container, used to configure iptables.
    image: proxy_init

  # imagePullPolicy is applied to istio control plane components.
  # local tests require IfNotPresent, to avoid uploading to dockerhub.
  # TODO: Switch to Always as default, and override in the local tests.
  imagePullPolicy: IfNotPresent

  # controlPlaneSecurityEnabled enabled. Will result in delays starting the pods while secrets are
  # propagated, not recommended for tests.
  controlPlaneSecurityEnabled: false

  # disablePolicyChecks disables mixer policy checks.
  # if mixer.policy.enabled==true then disablePolicyChecks has affect.
  # Will set the value with same name in istio config map - pilot needs to be restarted to take effect.
  disablePolicyChecks: true

  # policyCheckFailOpen allows traffic in cases when the mixer policy service cannot be reached.
  # Default is false which means the traffic is denied when the client is unable to connect to Mixer.
  policyCheckFailOpen: false

  # EnableTracing sets the value with same name in istio config map, requires pilot restart to take effect.
  enableTracing: true

  # Configuration for each of the supported tracers
  tracer:
    # Configuration for envoy to send trace data to LightStep.
    # Disabled by default.
    # address: the <host>:<port> of the satellite pool
    # accessToken: required for sending data to the pool
    # secure: specifies whether data should be sent with TLS
    # cacertPath: the path to the file containing the cacert to use when verifying TLS. If secure is true, this is
    #   required. If a value is specified then a secret called "lightstep.cacert" must be created in the destination
    #   namespace with the key matching the base of the provided cacertPath and the value being the cacert itself.
    #
    lightstep:
      address: ""                # example: lightstep-satellite:443
      accessToken: ""            # example: abcdefg1234567
      secure: true               # example: true|false
      cacertPath: ""             # example: /etc/lightstep/cacert.pem
    zipkin:
      # Host:Port for reporting trace data in zipkin format. If not specified, will default to
      # zipkin service (port 9411) in the same namespace as the other istio components.
      address: ""
    datadog:
      # Host:Port for submitting traces to the Datadog agent.
      address: "$(HOST_IP):8126"

  # Default mtls policy. If true, mtls between services will be enabled by default.
  mtls:
    # Default setting for service-to-service mtls. Can be set explicitly using
    # destination rules or service annotations.
    enabled: true

  # Lists the secrets you need to use to pull Istio images from a private registry.
  imagePullSecrets: []
    # - private-registry-key

  # Specify pod scheduling arch(amd64, ppc64le, s390x) and weight as follows:
  #   0 - Never scheduled
  #   1 - Least preferred
  #   2 - No preference
  #   3 - Most preferred
  arch:
    amd64: 2
    s390x: 2
    ppc64le: 2

  # Whether to restrict the applications namespace the controller manages;
  # If not set, controller watches all namespaces
  oneNamespace: false

  # Default node selector to be applied to all deployments so that all pods can be
  # constrained to run a particular nodes. Each component can overwrite these default
  # values by adding its node selector block in the relevant section below and setting
  # the desired values.
  defaultNodeSelector: {}

  # Default node tolerations to be applied to all deployments so that all pods can be
  # scheduled to a particular nodes with matching taints. Each component can overwrite
  # these default values by adding its tolerations block in the relevant section below
  # and setting the desired values.
  # Configure this field in case that all pods of Istio control plane are expected to
  # be scheduled to particular nodes with specified taints.
  defaultTolerations: []

  # Whether to perform server-side validation of configuration.
  configValidation: true

  # Custom DNS config for the pod to resolve names of services in other
  # clusters. Use this to add additional search domains, and other settings.
  # see
  # https://kubernetes.io/docs/concepts/services-networking/dns-pod-service/#dns-config
  # This does not apply to gateway pods as they typically need a different
  # set of DNS settings than the normal application pods (e.g., in
  # multicluster scenarios).
  # NOTE: If using templates, follow the pattern in the commented example below.
  # podDNSSearchNamespaces:
  # - global
  # - "[[ valueOrDefault .DeploymentMeta.Namespace \"default\" ]].global"

  # If set to true, the pilot and citadel mtls will be exposed on the
  # ingress gateway
  meshExpansion:
    enabled: false
    # If set to true, the pilot and citadel mtls and the plaintext pilot ports
    # will be exposed on an internal gateway
    useILB: false

  multiCluster:
    # Set to true to connect two kubernetes clusters via their respective
    # ingressgateway services when pods in each cluster cannot directly
    # talk to one another. All clusters should be using Istio mTLS and must
    # have a shared root CA for this model to work.
    enabled: false

    # Should be set to the name of the cluster this installation will run in. This is required for sidecar injection
    # to properly label proxies
    clusterName: ""

  # A minimal set of requested resources to applied to all deployments so that
  # Horizontal Pod Autoscaler will be able to function (if set).
  # Each component can overwrite these default values by adding its own resources
  # block in the relevant section below and setting the desired resources values.
  defaultResources:
    requests:
      cpu: 10m
    #   memory: 128Mi
    # limits:
    #   cpu: 100m
    #   memory: 128Mi

  # enable pod distruption budget for the control plane, which is used to
  # ensure Istio control plane components are gradually upgraded or recovered.
  defaultPodDisruptionBudget:
    enabled: true
    # The values aren't mutable due to a current PodDisruptionBudget limitation
    # minAvailable: 1

  # Kubernetes >=v1.11.0 will create two PriorityClass, including system-cluster-critical and
  # system-node-critical, it is better to configure this in order to make sure your Istio pods
  # will not be killed because of low priority class.
  # Refer to https://kubernetes.io/docs/concepts/configuration/pod-priority-preemption/#priorityclass
  # for more detail.
  priorityClassName: ""

  # Use the Mesh Control Protocol (MCP) for configuring Mixer and
  # Pilot. Requires galley (`--set galley.enabled=true`).
  useMCP: true

  # The trust domain corresponds to the trust root of a system
  # Refer to https://github.com/spiffe/spiffe/blob/master/standards/SPIFFE-ID.md#21-trust-domain
  # Indicate the domain used in SPIFFE identity URL
  # The default depends on the environment.
  #   kubernetes: cluster.local
  #   else:  default dns domain
  trustDomain: ""

  # Mesh ID means Mesh Identifier. It should be unique within the scope where
  # meshes will interact with each other, but it is not required to be
  # globally/universally unique. For example, if any of the following are true,
  # then two meshes must have different Mesh IDs:
  # - Meshes will have their telemetry aggregated in one place
  # - Meshes will be federated together
  # - Policy will be written referencing one mesh from the other
  #
  # If an administrator expects that any of these conditions may become true in
  # the future, they should ensure their meshes have different Mesh IDs
  # assigned.
  #
  # Within a multicluster mesh, each cluster must be (manually or auto)
  # configured to have the same Mesh ID value. If an existing cluster 'joins' a
  # multicluster mesh, it will need to be migrated to the new mesh ID. Details
  # of migration TBD, and it may be a disruptive operation to change the Mesh
  # ID post-install.
  #
  # If the mesh admin does not specify a value, Istio will use the value of the
  # mesh's Trust Domain. The best practice is to select a proper Trust Domain
  # value.
  meshID: ""

  # Set the default behavior of the sidecar for handling outbound traffic from the application:
  # ALLOW_ANY - outbound traffic to unknown destinations will be allowed, in case there are no
  #   services or ServiceEntries for the destination port
  # REGISTRY_ONLY - restrict outbound traffic to services defined in the service registry as well
  #   as those defined through ServiceEntries
  # ALLOW_ANY is the default in 1.1.  This means each pod will be able to make outbound requests
  # to services outside of the mesh without any ServiceEntry.
  # REGISTRY_ONLY was the default in 1.0.  If this behavior is desired, set the value below to REGISTRY_ONLY.
  outboundTrafficPolicy:
    mode: REGISTRY_ONLY

  # The namespace where globally shared configurations should be present.
  # DestinationRules that apply to the entire mesh (e.g., enabling mTLS),
  # default Sidecar configs, etc. should be added to this namespace.
  # configRootNamespace: istio-config

  # set the default set of namespaces to which services, service entries, virtual services, destination
  # rules should be exported to. Currently only one value can be provided in this list. This value
  # should be one of the following two options:
  # * implies these objects are visible to all namespaces, enabling any sidecar to talk to any other sidecar.
  # . implies these objects are visible to only to sidecars in the same namespace, or if imported as a Sidecar.egress.host
  # defaultConfigVisibilitySettings:
  #- '*'

  sds:
    # SDS enabled. IF set to true, mTLS certificates for the sidecars will be
    # distributed through the SecretDiscoveryService instead of using K8S secrets to mount the certificates.
    enabled: false
    udsPath: ""
    # The JWT token for SDS and the aud field of such JWT. See RFC 7519, section 4.1.3.
    # When a CSR is sent from Citadel Agent to the CA (e.g. Citadel), this aud is to make sure the
    # JWT is intended for the CA.
    token:
      aud: istio-ca

  # Configure the mesh networks to be used by the Split Horizon EDS.
  #
  # The following example defines two networks with different endpoints association methods.
  # For `network1` all endpoints that their IP belongs to the provided CIDR range will be
  # mapped to network1. The gateway for this network example is specified by its public IP
  # address and port.
  # The second network, `network2`, in this example is defined differently with all endpoints
  # retrieved through the specified Multi-Cluster registry being mapped to network2. The
  # gateway is also defined differently with the name of the gateway service on the remote
  # cluster. The public IP for the gateway will be determined from that remote service (only
  # LoadBalancer gateway service type is currently supported, for a NodePort type gateway service,
  # it still need to be configured manually).
  #
  # meshNetworks:
  #   network1:
  #     endpoints:
  #     - fromCidr: "<IP_ADDRESS>/24"
  #     gateways:
  #     - address: <IP_ADDRESS>
  #       port: 80
  #   network2:
  #     endpoints:
  #     - fromRegistry: reg1
  #     gateways:
  #     - registryServiceName: istio-ingressgateway.istio-system.svc.cluster.local
  #       port: 443
  #
  meshNetworks: {}

  # Specifies the global locality load balancing settings.
  # Locality-weighted load balancing allows administrators to control the distribution of traffic to
  # endpoints based on the localities of where the traffic originates and where it will terminate.
  # Either failover or distribute configuration can be set, but not both. If neither are provided
  # failover mode will be used.
  #
  # localityLbSetting:
  #   enabled: true
  #   distribute:
  #   - from: "us-central1/*"
  #     to:
  #       "us-central1/*": 80
  #       "us-central2/*": 20
  #
  # localityLbSetting:
  #   enabled: true
  #   failover:
  #   - from: us-east
  #     to: eu-west
  #   - from: us-west
  #     to: us-east
  localityLbSetting:
    enabled: true

  # Specifies whether helm test is enabled or not.
  # This field is set to false by default, so 'helm template ...'
  # will ignore the helm test yaml files when generating the template
  enableHelmTest: false

facing the same issue with istio 1.3.5

I am confirming same issue on version 1.4.2
I found this in ingress gateway logs:
{"bytes_sent":"103","upstream_cluster":"-","downstream_remote_address":"xx.xx.xx.xx6:51938","authority":"bookinfo.example.com","path":"/productpage","protocol":"HTTP/2","upstream_service_time":"-","upstream_local_address":"-","duration":"1000","downstream_local_address":"<IP_ADDRESS>:443","upstream_transport_failure_reason":"-","route_name":"-","response_code":"503","user_agent":"Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/79.0.3945.88 Safari/537.36","response_flags":"UAEX","start_time":"2020-01-08T17:12:59.048Z","method":"GET","request_id":"cdca4c80-daea-4a68-864f-f700d3414a26","upstream_host":"-","x_forwarded_for":"xx.xx.xx.xx","requested_server_name":"bookinfo.example.com","bytes_received":"0","istio_policy_status":"\"UNAVAILABLE:upstream connect error or disconnect/reset before headers. reset reason: connection failure\""}
{"response_flags":"UAEX","start_time":"2020-01-08T17:13:00.556Z","method":"GET","request_id":"b36670b5-8395-4670-89e7-c20a41b46e05","upstream_host":"-","x_forwarded_for":"xx.xx.xx.xx","requested_server_name":"bookinfo.example.com","bytes_received":"0","istio_policy_status":"\"UNAVAILABLE:upstream connect error or disconnect/reset before headers. reset reason: connection failure\"","bytes_sent":"103","upstream_cluster":"-","downstream_remote_address":"xx.xx.xx.xx:51938","authority":"bookinfo.example.com","path":"/favicon.ico","protocol":"HTTP/2","upstream_service_time":"-","upstream_local_address":"-","duration":"1002","downstream_local_address":"<IP_ADDRESS>:443","upstream_transport_failure_reason":"-","route_name":"-","response_code":"503","user_agent":"Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/79.0.3945.88 Safari/537.36"}

If mTLS is enabled globally make sure you set controlPlaneSecurityEnabled: true.

Im having similar issue on Istio 1.4.4
Here are my settings
controlPlaneSecurityEnabled: false
disablePolicyChecks: false
mixer:
    policy:
    enabled: true

istio-policy-69c8bbd6889-xxxx 2/2 Running 0 60m
getting frequent
istio-telemetry-759864cb9-7k65s istio-proxy [Envoy (Epoch 0)] [2020-01-10 13:16:08.517][26][warning][filter] [src/istio/mixerclient/report_batch.cc:110] Mixer Report failed with: UNAVAILABLE:upstream connect error or disconnect/reset before headers. reset reason: connection failure

on istio-telemetry

@rnkhouse I was facing the same issue, then I read about https://istio.io/docs/ops/configuration/traffic-management/protocol-selection/. I realised the name of the port in the service definition should start with for example http-. This fixed the issue for me. And . if you face the issue still you might need to look at the tls-check for the pods and resolve it using destinationrules and policies.

@virmanv thanks for sharing! Fixed the problem for me.

Hi @virmanv  and @heikostumpf
I am also getting this issue. Which service definition should you were referring?


Ignore top-level array definitions

Top-level Array types can’t be TypeScript Interfaces, so they should be ignored.
While there may be some practical usecase where this causes issues, at least for our internal specs, all our top-level array specs are referenced elsewhere, and handled correctly.
If this breaks someone’s specific usecase, the solution can be modified.

Codecov Report

Merging #10 into master will decrease coverage by 1.34%.
The diff coverage is 100%.

@@            Coverage Diff             @@
##           master      #10      +/-   ##
==========================================
- Coverage   95.71%   94.36%   -1.35%
==========================================
  Files           2        2
  Lines          70       71       +1
  Branches       17       17
==========================================
  Hits           67       67
- Misses          3        4       +1

Impacted Files
Coverage Δ

src/swagger-2.ts
93.93% <100%> (-1.45%)
:arrow_down:

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 7a2d872...2fb2e36. Read the comment docs.


Reimport error 500 with ASYNC_IMPORT enabled

Bug description
When ASYNC_IMPORT is enabled some of reimports constantly fail with 500 error. Seems like a bug for me, cause if I switch to ASYNC_IMPORT=False everything is ok. scan_type = Generic Findings Import.
Expected behavior
Reimports success with 201 status code with ASYNC_IMPORT enabled.
Deployment method (select with an X)

[x ] Docker Compose

Environment information

Operating System: debian 12
DefectDojo version 2.25.4

Dockerfile.django-debian
...

ENV \

#DD_CELERY_WORKER_POOL_TYPE="solo"
DD_CELERY_WORKER_POOL_TYPE="prefork"
DD_CELERY_WORKER_AUTOSCALE_MIN="24"
DD_CELERY_WORKER_AUTOSCALE_MAX="48"
DD_CELERY_WORKER_CONCURRENCY="24"
DD_CELERY_WORKER_PREFETCH_MULTIPLIER="256"
...
DD_UWSGI_NUM_OF_PROCESSES="4"
DD_UWSGI_NUM_OF_THREADS="4"
...
Logs
[12/Sep/2023 10:59:03] ERROR [dojo.api_v2.exception_handler:36] list index out of range
Traceback (most recent call last):
File "/usr/local/lib/python3.11/site-packages/rest_framework/views.py", line 506, in dispatch
response = handler(request, *args, **kwargs)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.11/site-packages/rest_framework/mixins.py", line 19, in create
self.perform_create(serializer)
File "/app/dojo/api_v2/views.py", line 3471, in perform_create
serializer.save(push_to_jira=push_to_jira)
File "/app/dojo/api_v2/serializers.py", line 2502, in save
) = reimporter.reimport_scan(
^^^^^^^^^^^^^^^^^^^^^^^^^
File "/app/dojo/importers/reimporter/reimporter.py", line 654, in reimport_scan
) = results.get()
^^^^^^^^^^^^^
File "/usr/local/lib/python3.11/site-packages/celery/result.py", line 247, in get
return self.backend.wait_for_pending(
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.11/site-packages/celery/backends/base.py", line 763, in wait_for_pending
return result.maybe_throw(propagate=propagate, callback=callback)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.11/site-packages/celery/result.py", line 361, in maybe_throw
self.throw(value, self._to_remote_traceback(tb))
File "/usr/local/lib/python3.11/site-packages/celery/result.py", line 354, in throw
self.on_ready.throw(*args, **kwargs)
File "/usr/local/lib/python3.11/site-packages/vine/promises.py", line 234, in throw
reraise(type(exc), exc, tb)
File "/usr/local/lib/python3.11/site-packages/vine/utils.py", line 30, in reraise
raise value
IndexError: list index out of range
[12/Sep/2023 10:59:03] ERROR [django.request:241] Internal Server Error: /api/v2/reimport-scan/

Experienced the same issue as well
[08/Jun/2023 15:59:17] ERROR [dojo.api_v2.exception_handler:32] list index out of range
Traceback (most recent call last):
  File "/usr/local/lib/python3.11/site-packages/rest_framework/views.py", line 506, in dispatch
    response = handler(request, *args, **kwargs)
               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/site-packages/rest_framework/mixins.py", line 19, in create
    self.perform_create(serializer)
  File "/app/dojo/api_v2/views.py", line 2447, in perform_create
    serializer.save(push_to_jira=push_to_jira)
  File "/app/dojo/api_v2/serializers.py", line 1846, in save
    reimporter.reimport_scan(scan, scan_type, test, active=active, verified=verified,
  File "/app/dojo/importers/reimporter/reimporter.py", line 654, in reimport_scan
    ) = results.get()
        ^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/site-packages/celery/result.py", line 224, in get
    return self.backend.wait_for_pending(
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/site-packages/celery/backends/base.py", line 764, in wait_for_pending
    return result.maybe_throw(propagate=propagate, callback=callback)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/site-packages/celery/result.py", line 336, in maybe_throw
    self.throw(value, self._to_remote_traceback(tb))
  File "/usr/local/lib/python3.11/site-packages/celery/result.py", line 329, in throw
    self.on_ready.throw(*args, **kwargs)
  File "/usr/local/lib/python3.11/site-packages/vine/promises.py", line 234, in throw
    reraise(type(exc), exc, tb)
  File "/usr/local/lib/python3.11/site-packages/vine/utils.py", line 30, in reraise
    raise value
IndexError: list index out of range
[08/Jun/2023 15:59:17] ERROR [django.request:241] Internal Server Error: /api/v2/reimport-scan/

Here’s my request Payload:
{'scan_type': 'Generic Findings Import', 'product_name': 'Kubernetes Cluster', 'test_title': 'Dynamic Analysis', 'engagement': 3, 'engagement_name': 'DAST Engagement', 'push_to_jira': False, 'active': True, 'verified': True, 'close_old_findings': True, 'minimum_severity': 'Info', 'tags': ['dojo-ci'], 'scan_date': '2023-06-08', 'branch_tag': ''}

Another side effect of async reimports with generic parser - emerging of endpoints that should be migrated
celeryworker_1  | [15/Sep/2023 06:38:13] ERROR [celery.app.trace:270] Task dojo.importers.utils.add_endpoints_to_unsaved_finding[152c578e-b815-41f8-b0a6-33532a5bb244] raised unexpected: Exception('Endpoints in your database are broken. Please access /endpoint/migrate and migrate them to new format or remove them.')

ASYNC_IMPORT should be considered an experimental feature. It works in some cases and doesn't in others. I believe it was written with 'traditional' imports in mind, not re-imports though it's been long enough that I don't trust my memory on the specifics.
Someone should probably add something to settings.py that says "Use at your own risk" TBH.

ASYNC_IMPORT should be considered an experimental feature. It works in some cases and doesn't in others. I believe it was written with 'traditional' imports in mind, not re-imports though it's been long enough that I don't trust my memory on the specifics.
Someone should probably add something to settings.py that says "Use at your own risk" TBH.

Thank you for the explanation, Matt.
I think it should be mentioned here:
https://defectdojo.github.io/django-DefectDojo/getting_started/running-in-production/

We have the same issue by uploading Nessus Scan
Endpoints in your database are broken. Please access /endpoint/migrate and migrate them to new format or remove them. uwsgi_1         | Traceback (most recent call last): uwsgi_1         |   File "/usr/local/lib/python3.11/site-packages/rest_framework/views.py", line 506, in dispatch uwsgi_1         |     response = handler(request, *args, **kwargs) uwsgi_1         |                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ uwsgi_1         |   File "/usr/local/lib/python3.11/site-packages/rest_framework/mixins.py", line 19, in create uwsgi_1         |     self.perform_create(serializer) uwsgi_1         |   File "/app/dojo/api_v2/views.py", line 3266, in perform_create uwsgi_1         |     serializer.save(push_to_jira=push_to_jira) uwsgi_1         |   File "/app/dojo/api_v2/serializers.py", line 2219, in save uwsgi_1         |     ) = importer.import_scan( uwsgi_1         |         ^^^^^^^^^^^^^^^^^^^^^ uwsgi_1         |   File "/app/dojo/importers/importer/importer.py", line 338, in import_scan uwsgi_1         |     serial_new_findings = results.get() uwsgi_1         |                           ^^^^^^^^^^^^^ uwsgi_1         |   File "/usr/local/lib/python3.11/site-packages/celery/result.py", line 250, in get uwsgi_1         |     return self.backend.wait_for_pending( uwsgi_1         |            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ uwsgi_1         |   File "/usr/local/lib/python3.11/site-packages/celery/backends/base.py", line 763, in wait_for_pending uwsgi_1         |     return result.maybe_throw(propagate=propagate, callback=callback) uwsgi_1         |            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ uwsgi_1         |   File "/usr/local/lib/python3.11/site-packages/celery/result.py", line 364, in maybe_throw uwsgi_1         |     self.throw(value, self._to_remote_traceback(tb)) uwsgi_1         |   File "/usr/local/lib/python3.11/site-packages/celery/result.py", line 357, in throw uwsgi_1         |     self.on_ready.throw(*args, **kwargs) uwsgi_1         |   File "/usr/local/lib/python3.11/site-packages/vine/promises.py", line 234, in throw uwsgi_1         |     reraise(type(exc), exc, tb) uwsgi_1         |   File "/usr/local/lib/python3.11/site-packages/vine/utils.py", line 30, in reraise uwsgi_1         |     raise value uwsgi_1         | Exception: Endpoints in your database are broken. Please access /endpoint/migrate and migrate them to new format or remove them.
But changing settings.dist.py to DD_ASYNC_FINDING_IMPORT=(bool, False) not solved this issue.
Any ideas how it can be fixed?

We have the same issue by uploading Nessus Scan

Endpoints in your database are broken. Please access /endpoint/migrate and migrate them to new format or remove them. uwsgi_1         | Traceback (most recent call last): uwsgi_1         |   File "/usr/local/lib/python3.11/site-packages/rest_framework/views.py", line 506, in dispatch uwsgi_1         |     response = handler(request, *args, **kwargs) uwsgi_1         |                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ uwsgi_1         |   File "/usr/local/lib/python3.11/site-packages/rest_framework/mixins.py", line 19, in create uwsgi_1         |     self.perform_create(serializer) uwsgi_1         |   File "/app/dojo/api_v2/views.py", line 3266, in perform_create uwsgi_1         |     serializer.save(push_to_jira=push_to_jira) uwsgi_1         |   File "/app/dojo/api_v2/serializers.py", line 2219, in save uwsgi_1         |     ) = importer.import_scan( uwsgi_1         |         ^^^^^^^^^^^^^^^^^^^^^ uwsgi_1         |   File "/app/dojo/importers/importer/importer.py", line 338, in import_scan uwsgi_1         |     serial_new_findings = results.get() uwsgi_1         |                           ^^^^^^^^^^^^^ uwsgi_1         |   File "/usr/local/lib/python3.11/site-packages/celery/result.py", line 250, in get uwsgi_1         |     return self.backend.wait_for_pending( uwsgi_1         |            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ uwsgi_1         |   File "/usr/local/lib/python3.11/site-packages/celery/backends/base.py", line 763, in wait_for_pending uwsgi_1         |     return result.maybe_throw(propagate=propagate, callback=callback) uwsgi_1         |            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ uwsgi_1         |   File "/usr/local/lib/python3.11/site-packages/celery/result.py", line 364, in maybe_throw uwsgi_1         |     self.throw(value, self._to_remote_traceback(tb)) uwsgi_1         |   File "/usr/local/lib/python3.11/site-packages/celery/result.py", line 357, in throw uwsgi_1         |     self.on_ready.throw(*args, **kwargs) uwsgi_1         |   File "/usr/local/lib/python3.11/site-packages/vine/promises.py", line 234, in throw uwsgi_1         |     reraise(type(exc), exc, tb) uwsgi_1         |   File "/usr/local/lib/python3.11/site-packages/vine/utils.py", line 30, in reraise uwsgi_1         |     raise value uwsgi_1         | Exception: Endpoints in your database are broken. Please access /endpoint/migrate and migrate them to new format or remove them.

But changing settings.dist.py to DD_ASYNC_FINDING_IMPORT=(bool, False) not solved this issue.
Any ideas how it can be fixed?

Have you already tried to migrate endpoints? It's available from dojo GUI

Oh my god!
Really, now it's working fine!
Thank you very much.

I guess this can be closed @mtesauro


Some users can't refresh catalogs

If some users in our rancher instance try to refresh the catalogs, the response is a 404. This extends over Cluster/Project/Global catalogs.

From the rancher CLI the following feedback is sent:
FATA[0000] action [refresh] not available on [&{test catalog map[exportYaml:https://rancher2.organisation.com/v3/catalogs/test/exportyaml remove:https://rancher2.organisation.com/v3/catalogs/test self:https://rancher2.organisation.com/v3/catalogs/test templates:https://rancher2.organisation.com/v3/templates?catalogId=test update:https://rancher2.organisation.com/v3/catalogs/test] map[]}]

Useful
Info

Versions
Rancher v2.4.2 UI: v2.4.14

Hi @KuroObi  What is the role of the user? cluster owner/member or projet owner/member or something else?
By design:

only admin can refresh the global catalog
only admin and cluster owner can refresh the cluster-level catalog
only admin, cluster owner, and project owner can refresh the project-level catalog

With the admin  role it worked like a charm.
Is there a way to allow just the update catalog for a user as a separate role.
We need this for automated scripts.

Hi,
We encounter the same problem since we updated rancher to version 2.4 (previoulsy, we were using version 2.2 and the refresh of global catalogs was OK for non-admin users).
I don't really get it about the design. We use different clusters for dev, staging or production environments and it is useful for our teams to define global catalogs in order to deploy their apps in the different clusters. But we don't want to make them administrators. We thought the global role 'catalogs-use' should allow refresh of the global catalogs (as it used to in previous versions ?)

Hi,
Is there any chance of a return to previous behavior? As a workaround, we have defined a role giving patch and update rights on catalogs and assign it to users, but this is a manual operation that is prone to error.
Thank you for any feedback and any explanation on this design choice that we don't fully understand.


[Bug] "With 0 contextual prompts "

Describe the bug
can not hide "With 0 contextual prompts "
To Reproduce
Steps to reproduce the behavior:
Hide context prompts on
scroll up
Expected behavior
hide "With 0 contextual prompts "
"With 0 contextual prompts " 能不能把这个隐藏掉，超级烦没有任何意义，在手机上还遮盖显示

It's not a bug, when you scrolling up of course it show

不想看的话，把这个弹窗部分的div注释掉就好了，或者换个位置


bug: Llama reproduce error with kernl

Description
When trying to use kernl with default Llama 7B on A100 device, I get this error.
Steps to reproduce

import torch
from transformers import LlamaModel, LlamaConfig, LlamaTokenizer, LlamaForCausalLM
from kernl.model_optimization import optimize_model

config  = LlamaConfig()
model = LlamaForCausalLM(config).cuda()
optimize_model(model)

length = 5
input_ids = torch.randint(low=0, high=model.config.vocab_size, size=(1,length)).cuda()
with torch.inference_mode(), torch.cuda.amp.autocast():
	outputs = model.generate(input_ids=input_ids)

print(outputs.shape)

Expected Behavior
A properly working Llama model.
Actual Behavior
The following message occurs:

Your environment

A100

Self-service

[X] I would be willing to help fix this bug myself.

Code of Conduct

[X] I agree to follow this project's Code of Conduct

It is the same for me, please help up to use LLaMA models :)


docs: hammerjs using systemjs.config

Replace #10653

I confirm that I am ok with my commits being contributed to this project.


FIXED responsiveness of contact us page

Description
i was assigned to complete responsiveness of the contact us page
Related Issue
Fixes #98
Type of change

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

Checklist

[x] My code follows the style guidelines of this project
[x] I have performed a self-review of my own code
[x] I have commented on my code, particularly in hard-to-understand areas
[x] I have added tests that prove my fix is effective or that my feature works
[x] New and existing unit tests pass locally with my changes
[x

] Any dependent changes have been merged and published in downstream modules

We do not need right now

We do not need right now

@subhadipbhowmik but it still UI in Mobile not good right


Open redirect in redirect.gag

We get open redirect on APIM_HOME/repository/deployment/store/site/themes/wso2/templates/user/sign-up/redirector.jag
https://localhost:9443/store/site/themes/wso2/templates/user/sign-up/redirector.jag?redirectToHome=http%3A%2F%2F1432024300%2Fa%3F%2Fstore&tenant=null
API Manager 2.1.0
Can I make only context redirects (like a /store/somewhere) or restrict them to a domain name(s)?

This is already fixed https://github.com/sambaheerathan/carbon-
apimgt/commit/5d0eada2566a3b7dde1db5a50c1127301cfee12c


When charset is set inside the SEO component, it's placed after the title tag

These days, a typical HTML5 file will begin something like:
<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="UTF-8" />
    <meta name="viewport" content="width=device-width, initial-scale=1" />
    ...
    <title>Title comes later</title>

The meta charset tag is almost always the first tag inside the head tag, because the HTML5 specification suggests placing the charset declaration within the first 1024 bytes of the document.
Placing the charset declaration first clarifies the character encoding for the entire document, including the title, ensuring proper interpretation of characters. While modern browsers are robust, in rare cases, placing the title before the charset might lead to rendering issues, especially if the title includes non-ASCII characters.
The SEO component provided by astro-seo lets one set the value of charset. If one does that, the generated HTML has the title tag before the charset declaration. That is an issue.
Thoughts on How to Fix this Issue
The first thing you might be tempted to do is put the meta charset tag first, before the title tag. The problem with that is that there might be lots of other tags before the SEO component, inside the head tag. The SEO component has no control over those tags. They're put there by the user of the SEO component, not by the SEO component itself.
The final generated HTML should have the charset declaration first (inside the head tag), yet the SEO component can't do that.
Moreover, the charset declaration isn't really an SEO thing anyhow. It's more like the meta viewport tag.
Therefore, my conclusion is that the SEO component provided by astro-seo should be changed to no longer accept a value for charset, and it should no longer try to set it. Anyone who tries to use the SEO component to set charset should be told it's being deprecated and they should just set it manually, first thing inside the head tag. Then in the future, the charset prop could be removed from the SEO component completely.

@ttmc Thank you for this great report and thorough engagement with the issue. This is greatly appreciated and I think I agree that the best move here might be to deprecate the attribute.
Another possibility would be to run some JS that would always put the tag as the first child of the head. What's your opinion on that?

@ttmc Thank you for your insights on this, these are very helpful! I wanted to sit down to implement this today, but I don't think I have enough time to turn this into an integration and see if this works. Might I ask if you would be willing to give this a try and then do a PR for this?

I don't really like the idea of using client-side js to place charset ahead of the rest. Maybe things changed, but I remember browsers read a page until they hit the charset and might reload (not visible to the user) after that.
I'm starting to think the best option would be NOT to support charset (warn if used) and let the user insert the meta charset where necessary.

Regarding the SEO library for Astro, while the charset and viewport metadata is crucial for rendering, it's not directly tied to SEO. Let's prioritize optimizing SEO elements, including interesting meta tags and maintain best practices for usability.


Add email-id for rajas and fix slack and github handles

cc @raravena80 @helayoty

@rajaskakodkar , You will need to sign the commit to be able to get this merged.

@rajaskakodkar do you mind signing the commit? Thx!

@raravena80 @helayoty looks like this branch has gone corrupt. I have signed the commits already and tried it again as well. I will create another PR to fix this


Add ChainObserver trait

Add the ChainObserver trait, which is will be used by the chain
controller to notify components of chain updates.
Signed-off-by: Peter Schwarz<EMAIL_ADDRESS>

This isn't the right interface needed for the publisher.


Added Error to RawStatement

Fixes https://github.com/AeneasVerif/charon/issues/112

Looks good, we just need a test now. @sonmarcho what kind of error should we use this for?

Looks good, we just need a test now. @sonmarcho what kind of error should we use this for?

If you look carefully we do not actually introduce the Error kind anywhere at this point, so we can't test it: we need to update the translation from Hax to ULLBC first. However, it might break some micro-passes (not sure, though) so I suggest doing that in a subsequent PR where we will add tests. For the missing features, anything will do and if you need inspiration just look at the translate_statement function (we can use intrinsics, some unsafe features, async/await, yield, etc. - I leave it to you guys :) ).

On a different topic: the CI failure is bizarre, right?

On a different topic: the CI failure is bizarre, right?

It happens because we changed the Cargo.toml, which updates Cargo.lock on the next run of cargo, but the Cargo.lock was not commited.

I will commit it with the change suggested by @sonmarcho

Raw_statement_to_json and charon-ml related changes still need to be propagated

@msprotz this adds a new variant, eurydice will need to be updated

once again foiled by the lazy CI, I forgot to ping you beforehand sorry


OSError: [WinError 10013] An attempt was made to access a socket in a way forbidden by its access permissions

After tried to install your app locally I encountered this error on command line OSError: [WinError 10013] An attempt was made to access a socket in a way forbidden by its access permissions
How can I fix this issue to run locally? I tried to disable Antivirus as suggested on stackoverflow but no success

Looks like something is blocking socket access to the default port. Try changing the default port:
streamlit run main.py --server.port 5998


Handlers pass if service not installed

If you're doing advanced configuration you may want to cater for situations where omero may or may not be installed. For example creating a custom config file /opt/omero/server/config/xxx.omero to configure OMERO.server before the first start-up. In this situation:

If this is the first time the playbook is run OMERO.server is not installed, so you don't want to notify the restart handler.
If the playbook is subsequently run and changes are made to xxx.omero OMERO.server will already be installed, so it should be restarted.

This PR adds a conditional so that you can notify a handler without it erroring when the service isn't installed.
Tag: maybe 0.2.0?

0.2.0 makes sense.


Quick fixes support for zsh (with OhMyZsh & powerlevel10k)

Does this issue occur when all extensions are disabled?: Yes/No does not apply since it is related to ms-vscode-remote.remote-containers.

VS Code Version: 1.73.1
6261075646f055b99068d3688932416f2346dd3b
x64
OS Version: Manjaro Linux x86_64 (5.15.76-1-MANJARO)

Steps to Reproduce:
Prerequisites: remote container with zsh using OhMyZsh & powerlevel10k installed. I also had to add typeset -g POWERLEVEL9K_TERM_SHELL_INTEGRATION=true to the ~/.p10k.zsh file so that shell integrations works, as described here

Use ms-vscode-remote.remote-containers and get into a remote container terminal using zsh
Make sure to cd to a folder that contains a Git repository and git checkout -b to a branch that does not yet exist on the remote repository
Run git push and see that a quick fix is not being provided

Now do the same as above using a terminal that is using bash and see that a quick fix is being provided

@meganrogge this is probably related to the fact that p10k doesn't use support all our shell integration, I think it misses the executed command (633 E) and cwd.

Yes, thus I put this on the backlog

because of that we cannot reliably detect the command line text, so the feature is disabled by design as reliability is essentially when we are suggesting to run a command. So this is as designed for us.


Alternate way to compile non-ivy libraries after removal of ngcc in v16

Command
build
Is this a regression?

[ ] Yes, this behavior used to work in the previous version

The previous version in which this bug was not present was
No response
Description
Is there any alternate way to compile non-ivy packages after removal of ngcc in v16?
There are lots of unmaintained libraries like angular2-query-builder which devs are using. Till we migrated to some other library which is ivy compiled, is there any way to keep using non-ivy packages with angular v16?

Package                      Version
------------------------------------------------------
@angular-devkit/architect    0.1501.1 (cli-only)
@angular-devkit/core         15.1.1 (cli-only)
@angular-devkit/schematics   15.1.1 (cli-only)
@schematics/angular          15.1.1 (cli-only)

C:\Projects\projects\npm>

Anything else relevant?
No response

Hi, using no-Ivy libraries with version 16 will no longer be possible.
IMHO, we did give plenty of time for users to migrate to libraries using Ivy.

@jpike88 Please see https://github.com/ui-router/core/issues/822#issuecomment-1464678027 for the reason, resolution, and workaround.


Added method to invalidate map size when there is any widget

It really fixes #190 issue, but needs these changes in CartoDB.js.
CR: @javisantana

[ ] Point to the last commit from CartoDB.js#v4.


Release/2.14.1

Patch release to fix memmaps leaving open files before garbage collection which is causing failures in astropy CI:
https://github.com/astropy/astropy/pull/14035#issuecomment-1325236928

Please reopen this against the master branch


Dynamic local scopes in with clauses always returns same results, even if scope is different.

Describe the bug
I'm not sure if this is a feature request or bug. I hope you don't mind I put it in bugs.
We're currently using Dynamic Local Query scopes (https://laravel.com/docs/5.8/eloquent#local-scopes -> Dynamic scopes). However it seems that the cache key does not take the dynamic aspect into account, making it rather .. static.
I could imagine that the cache key generation method can check for additional parameters when generating the key as a possible solution?
Eloquent Query
public function scopeOfLesson($query, Lesson $lesson)
{
return $query->where('lesson_id', $lesson->id);
}

return Student::
where('id', 1)
->with(['progress' => static function (HasMany $model) use ($lesson) {
$model->ofLesson($lesson);
}])
->get();

The results is that when given two different $lessons that the cache results will return the result of the first requested $lesson.
Stack Trace
n/a
Environment

PHP: 7.2
OS: n/a
Laravel: 5.8
Model Caching: 0.7.0

Additional context
Thank you for making this package, we use it in every Laravel project to speed things up :heart:!

@hyperized Thanks for reporting this! I will take a look at the implementation and add a test-case to and hopefully find a way to fix it. :)

@hyperized I have been able to reproduce this issue and am trying to figure out a fix. It's complicated because this is a scope inside a relationship query. If the scope were applied to the main model directly, it would work as expected.

Been looking at this for a few hours now and am having a hard time coming to a solution. Any help would be appreciated, if anyone knows how we could analyze the eagerloads that are closures.

Not yet ... if someone is willing to create a PR for this, that would be greatly appreciated. Short of that, even if someone just submits a PR with the test case, that would be great.


Automatically sync all workspaces

Hello. Am I correct to understand that VSC not automatically syncs all my workspaces? And every time after adding a new folder or request to the workspace I have to create a snapshot and push it to the VSC?

Ah just came here to suggest the same thing. Would be nice to have an auto "sync all" feature or maybe an option to include other workspaces when creating the snapshot.

Hello @TahirJalilov, @ravindu1024!
We are looking into having the VCS automatically sync changes in the future.
One of the issues with the automatic legacy sync system that we'd like to fix when doing so was that it would silently ignore merge conflicts (when something has changed both remotely and locally), what would be your preferred behaviour in such a case?
For example, would you prefer it to just pick the most recent change, or get a notification and manually resolve the conflict by picking which version you'd prefer, or something else entirely?

Hello @TahirJalilov, @ravindu1024!
We are looking into having the VCS automatically sync changes in the future.
One of the issues with the automatic legacy sync system that we'd like to fix when doing so was that it would silently ignore merge conflicts (when something has changed both remotely and locally), what would be your preferred behaviour in such a case for you?
For example, would you prefer it to just pick the most recent change, or get a notification and manually resolve the conflict by picking which version you'd prefer, or something else entirely?

Being now used to the old "the last push wins" I'd tend to say that this way one can yes break things.. but another can also repair it once for everyone.
But after better reflections of course a notification about conflicts & what pick option, will be better! 👍

Hi,
Agreed, that I'm missing auto sync feature, I move between couple of PCs quite often and I've lost count the number of times that I've made a request on one machine and so used to the previous sync system, I've forgotten to push the changes to VCS until I get to my other PC and find I'm missing loads of requests.
Would agree that the most recent change is very likely to be the correct case, 9 times out of 10, and on the odd time that it might not be, its likely going to be simple to resolve manually.
Thanks


Fix named export 'Service' to export the constructor function

Fixes #37

I think this changes the behaviour whereby you'd now always need to call mongooseService() with the new keyword. I wrote some tests and verified that v3.0.1 supports import { Service } from 'feathers-mongoose' which will return the constructor.
If you just import mongooseService from 'feathers-service' then "mongooseService" will be the init function so that you can just call without the new keyword.

I'm going to close this because I don't want to change behaviour and I've now written tests to verify that it is working in v3.0.1+.

It wouldn't change the default behaviour of
import mongooseService from 'feathers-service';
mongooseService('/thing', { Model: Thing });

..but it would change what I thought was a mistake:
import mongooseService from 'feathers-service';
mongooseService.service('/thing', { Model: Thing });

... to error.

Right. Let's keep it the way it is for now (even if it is a bit confusing). Thanks for the PR though! :smile:


Uncaught TypeError: Cannot read properties of undefined (reading 'length')

Uncaught TypeError: Cannot read properties of undefined (reading 'length')
    at eval (plugin:obsidian-collapse-all-plugin:367:46)
    at Array.every (<anonymous>)
    at TagPaneProvider.tagsAreCollapsed (plugin:obsidian-collapse-all-plugin:367:22)
    at TagPaneProvider.allCollapsed (plugin:obsidian-collapse-all-plugin:355:21)
    at TagPaneProvider.updateButtonIcon (plugin:obsidian-collapse-all-plugin:208:39)
    at eval (plugin:obsidian-collapse-all-plugin:173:18)
    at Array.forEach (<anonymous>)
    at TagPaneProvider.updateButtonIcons (plugin:obsidian-collapse-all-plugin:172:21)
    at eval (plugin:obsidian-collapse-all-plugin:485:34)
    at Array.forEach (<anonymous>)

Can you give some context on where you see this?

I didn't quite get when is that happening. I am currently debugging it. I found how to fix it already but now I am checking why did it happen at first place. Then I will send a PR

@mnaoumov I'm unable to reproduce the issue. In what scenario do you see this? Are you on an insiders version of Obsidian?

Yes, I am on Insiders version 0.15.5

Released in 1.5.2. Thanks for the PR!


Upgrade to Jersey 2.18

Hello
We are using dropwizard 0.8.1 which rely in Jersey 2.17 (org.glassfish.jersey.core:jersey-client:jar:2.17).
Jersey 2.17 has a known major issue https://java.net/jira/browse/JERSEY-2786 fixed in 2.18,
but we can't update this dependency directly, cause it's a breaking change and migration is needed. https://jersey.java.net/documentation/latest/migration.html
Please consider the upgrade to jersey 2.18
Thanks

Current master is already updated to 2.18. See #1109.
We plan to release 0.9.0 in first weeks of July.

@arteam I do not think the release plan for this, is acceptable. This is a memory leak issue in one of the most core components of Dropwizard, Jersey, whose maintainers categorised it as Critical. Waiting for months until 0.9.X version with the fix is out, shows that you do not handle Dropwizard latest version as a production-worthy framework. We are trying to switch from 0.6.2 to 0.8.x for many months now, waiting for major fixes to be applied and now we need to wait for 0.9.x, with whatever that means in terms of backward compatibility etc!

@pparth, you have a point. But it's worth to mention that if some issues are critical for your organization, you can always make a fork, apply needed changes by hand, and maintain the fork independently from the main repository. Our primary goal is development of the latest version and we don't really have a plan for porting updates for older versions. However, we are happy to make maintenance releases for critical bugs or security updates, if it's needed. The best option to let it happen is to drop a message to the dropwizard-dev mailing list with a proposal of the changes you want to see backported.

@dropwizard/committers What do you think about making 0.8.2 release with backported #1109 and #1137?

@arteam I do not understand the notion of "our goal is just to develop" without trying to offer even a very small number of versions that are production-worthy. We are using version 0.6.2 in hundreds of micro-services of a large company and i can assure you it is production-worthy. We do not care about using latest versions of Jetty, Jersey etc., obviously, by staying at this version, as it is rather old. But it is stable. Since then, there is no other production-worthy versions. The ship has sailed for 0.7.x long ago (i do not even get why you do not mention this in its documentation...) and now you are telling me that 0.8.x is going to have the same fate too!
I get that we can fork and everything but i am really confused: don't you have the need to say to people that you actually maintain a version X that IS battle-tested and they can use it without any major issues until version Z is prepared?

@arteam I'm fine with releasing 0.8.2 with those two fixes (and any other bugs we want to address), and save everything else for 0.9.0

@arteam I'm also fine with an 0.8.2 release with those fixes.
@pparth "Waiting for months until 0.9.X version with the fix is out, shows that you do not handle Dropwizard latest version as a production-worthy framework. We are trying to switch from 0.6.2 to 0.8.x for many months now, waiting for major fixes to be applied and now we need to wait for 0.9.x, with whatever that means in terms of backward compatibility etc!"
First, please mind your tone (implied by the exclamation points).
Second, I think your date math is a bit off. You posted this on June 27th, mere days away from July. @arteam already indicated that 0.9.0 was coming in the early weeks of July, which is hardly months away.
Lastly, understand that Dropwizard is maintained by volunteers. There are no companies explicitly making money or time available to this project with the possible exception of Rent the Runway, which is (I believe) paying some of our hosting fees. For the employee of a company making $1B+ in revenue per year to make angry demands of volunteer staff seems ridiculous. Please try having a bit more respect and understanding for the people you're talking to.

@pparth I've not had problems in production with 0.8, but if I did I would either produce fixes myself or file issues for them and say kind and encouraging things to the DW team. I for one would welcome pull requests from you fixing the many problems you have with 0.8.x so that the entire community might benefit. Open source should not be a one way street.

FWIW, 0.9.0-rc1 seems to contain upgraded Jersey 2.18, and being available via Maven Central should be possible to use before official final 0.9.0, and appears to be solid enough for actual usage.

@ryankennedy @b I have the outmost respect for the work you are doing regarding Dropwizard and if i gave you a different impression then this is my fault and i am truly sorry. I know that you perform work for free, trying to maintain an excellent framework and no-one should be disrespectful to you. My tone had to do with confusion though and not with anger that you do not do your work properly.
I am confused because version 0.6.2 is a perfect example of what you describe in Overview: Its goal is to provide performant, reliable implementations of everything a production-ready web application needs. Because this functionality is extracted into a reusable library, your application remains lean and focused, reducing both time-to-market and maintenance burdens. but later versions seem to miss the point, in my opinion. @codahale was really focused on this initial description about Dropwizard and he was very adamant about Dropwizard being heavily opinionated in order to be a lean, mean, well-oiled machine used in really demanding, high traffic, production systems of companies like Yammer (and Upwork for that matter). The statement in "The Next Steps" section saying that You’ve got a Hello World application ready for production that’s capable of doing 30,000-50,000 requests per second is actually from this era and denotes exactly that: you do not expect this kind of traffic for a web service operating in a simple enterprise application.
Now, i assume that this, initial focus for the project, stays true. If the focus is switched to Dropwizard being a theoretical, academic work that it should not be judged by anyone, that the maintainers do not care in what environments it is used and big companies are especially banned, just let me know so that we can decide what route to follow from now on. Obviously, this has nothing to do with maintaining our own fork, producing fixes with PRs etc. It is about where this thing is headed to.
So, based on my assumptions, 0.7.x is unusable. I really do not understand why it is still documented and mentioned as a release that someone can actually choose to use it. ). 0.8.0 is surely much better but it has a lot of missing functionality, especially regarding Jersey, in compare to 0.6.2. Jersey Client was riddled with configuration issues. Jersey in general was still very unstable with lots of critical bugs. 0.8.1 seems to do the trick and be a strong base to strengthen the product and build on it.
But if you handle https://java.net/jira/browse/JERSEY-2786 which is a Critical memory leak bug, as something that can wait for months to find its way to Dropwizard (the issue was resolved last March and even if you do not want to fork Jersey on your own (???), 2.18 was out on the 5th of June. Assuming that you are going for a 0.9.0 RC in a few weeks, IT IS going to be months until the fix is present in a stable 0.9.x version and i am pretty sure that you are not going to continue maintaining the 0.8.x line), my assumptions are wrong.

I'm going to give you the benefit of the doubt and assume that there may be a language barrier that's preventing me from reading your tone/intent correctly. If English isn't your first language, then understand that your English isn't conveying the "respect" you refer to.
"So, based on my assumptions, 0.7.x is unusable. I really do not understand why it is still documented and mentioned as a release that someone can actually choose to use it."
Companies are using 0.7.x in production today. I believe this is the first time JERSEY-2786 has been brought up within the Dropwizard community (I could be wrong, however). It probably has to do with the fact that it appears to be an issue in Jersey Client, which not everyone is using. If you're only using dropwizard-core but not dropwizard-client then your chances of running into this leak appear to be roughly zero.
"If the focus is switched to Dropwizard being a theoretical, academic work that it should not be judged by anyone, that the maintainers do not care in what environments it is used and big companies are especially banned, just let me know so that we can decide what route to follow from now on."
You seem to be inferring quite a lot, especially with regard to the degree to which maintainers "care". Several maintainers (sadly, this doesn't include me at the moment) are putting in many of their own personal hours on this project. That's a pretty high degree of "care".
On the flip side, many companies (including Yammer, where Dropwizard originated) are using Dropwizard to power their multi-[million|billion] dollar companies without contributing much of anything back. If anyone should be judged, it's them. Especially when they show up in our community indignant over our state of library upgrades.
Yes, the documentation says "production ready out of the box." Yes, we appear to have an unfortunate memory leak in the dependencies of one of the modules in the latest release version. If you have a problem with that I have some possible solutions for you:

Roll up your sleeves and give us a hand.
Convince Upwork to pay for a part/full-time contributor.
Sit patiently on 0.6.x until 0.9.x is ready.
Fork the project.
Go someplace else.

If you're going to roll in here spouting "back when Coda ran this show…", I'm going to quickly shush you and point you towards the door.
Coda is gone.
The community is doing the best it can.
I'm not at all sorry that this free open source project isn't meeting the expectations of a multi-billion dollar company that contributes nothing to it. Give us a hand, lower your expectations, or go someplace else.

I may have the benefit of the doubt because English is not my native language, but there is no doubt about your tone when you continuously say to me "shut up and go someplace else". Nevertheless, i still say that i have a lot of respect to this project and to your work and that i am just judging where this project seems to be heading to, which apparently is something that i should not do because Coda Hale is not here now and all you capitalist employees in your big-time companies, should not talk at all and just go to hell. You are so biased, that i am not going to argue more about this.
We have contributed to this project in numerous ways. In code too, (i am not the only person working on this) but not as much as we or the community could benefit from, indeed. But code is not the only form of contribution you should care about. We contributed in providing our valuable comments for various issues either here or in Google groups, both for Dropwizard and also for Metrics.
We also offer another form of contribution which the community should be very interested in: battle testing Dropwizard in very demanding, high-traffic, production, web services. We are the ones that are taking the major risk of hardening this framework by using it in production. And when a component hicks up even for a few seconds, thousands of requests may go bad. Most of the well-hidden bugs arise in such environments. And we are the ones, naturally, to take the hit. You will never find these in 1rqs/sec traffic. Most things work perfect in such an environment.
We are the ones that give momentum to the fame of this project. Endorsement by major companies is what made Dropwizard known to people out there. We would never use it if Yammer was not behind it back then. Hundreds of Stars are due to people working in these companies. And when the time comes for community members to score a job somewhere, by mentioning that they contribute to the Dropwizard project, they will make it because they will say that Dropwizard is used by Yammer and Upwork and not because @ryankennedy says so.

To get the issue back on track, I'm also for releasing a version 0.8.2 with the mentioned fixes for Jersey as they should basically be cherry-pickable. I would try to keep the changes in 0.8.2 to a bare minimum because we should focus on getting Dropwizard 0.9.0 out of the door.
@pparth Great that you're using Dropwizard! Feel free to join the developers mailing list and discuss the project roadmap and the findings in your environment with the Dropwizard contributors. This issue is not the right place for it.
@ryankennedy @pparth I hope that this linguistic misunderstanding didn't make both of you bitter and that we can still have a constructive discussion on the developers mailing list.
I'm closing this issue now (still open for comments) as the upgrade to Jersey 2.19 has already been merged in #1143.

Thanks @joschi for considering adding these critical Jersey fixes to the 0.8.x line. I really hope that other critical issues we may find in the near future, find their way into 0.8.x without us having to move forward to 0.9.x.

@pparth If you've just started migrating, I'd recommend going for Dropwizard 0.9.x instead of using Dropwizard 0.8.x. You can also take over maintenance over the 0.8.x branch, if it's crucial to your operations.

Got it.
Can you point me to the major changes in 0.9.x comparing to 0.8.x?

@pparth We try to keep the release notes up to date (but no guarantee that they're complete, sorry): https://github.com/dropwizard/dropwizard/blob/master/docs/source/about/release-notes.rst

Sorry for misunderstanding. I was asking about the major points that made you consider moving to a 0.9.x line of code. What were the reasons you did not apply the changes in the release notes to 0.8.x line? Some architectural issues that break things?

I believe the only breaking change in 0.9 is #952, which updates how authorization is accomplished (fixes issue #768). I believe the latest documentation has more details.

At the risk of beating a dead horse...
@pparth "We are the ones that give momentum to the fame of this project. Endorsement by major companies is what made Dropwizard known to people out there... Hundreds of Stars are due to people working in these companies"
Why do you think that contributors of DropWizard are driven by some deep need to be popular?
Do you think you and other people using, deporting it, should be perhaps given a medal, or songs praised extolling your virtues? I do not get this. I have made minor contributions only, and can say that the reason I give back is based on two main things:

Benefit of getting the fixes, improvements integrated TO REDUCE MY OWN MAINTENANCE needs, and
As a minor thank you note for all the value I have gotten, am getting and will get out of this project

Your attitude seems to be along lines of "YOU should be grateful for ME for using your stuff, making it popular". That attitude is very arrogant, and I hope that is not what you intend to convey.
No one owes you (or other users) anything for your "implicit endorsement"; and I highly doubt that you or anyone else has started using DropWizard for purpose of marketing it.
Further, it did definitely sound like you were demanding things that you assume should be provided, without offering to -- for example -- help in that happening. That is a certain way to sour OSS relationships.
The sad part here is that I actually think that parts of what you are asking for are things that we as a community could consider and work towards. For example, creating maintenance branches for purpose of targeted backported fixes, is a reasonable idea. Especially if offering help with managing such branches or releases.
It's just that starting with demands, backed by allegations of incompetence and/or ungratefulness ("we made you popular -- now you don't even support old version I am using!"), is not a way to get anything positive going.
Apologies for continuing the debate beyond its natural end, but this is one area that is close to my heart, as both OSS author and user.

+1

I'm locking this issue now. Everyone has made their point. Please continue on the developer mailing list if you feel that there's more to discuss.


Baseline our KPIs for future reporting to governance bodies

Describe the issue
Our business case for building out the Public Cloud Accelerator Service goes to Digital Investment Board on October 21. It includes several KPIs that will measure our progress towards realizing the desired benefits, and we'll report on these to several governance bodies (ED cloud group (tri-weekly), ADMs (tri-weekly), ES client centric governance model, DIB (quarterly)).
Ideally we should baseline these KPIs in time for the DIB presentation on October 21.
Which Sprint Goal is this issue related to?

Note: 'Milestone' is a ZenHub term that we use synonymously with 'Sprint'.

The 'Milestone' description (created in ZenHub) should clearly list Sprint Goals. This section should indicate which 'goal' this issue is related to.
Additional context
Here are the KPIs proposed in our business case:

Number of compliant public cloud services available to ministry teams
Number of teams onboarded to compliant public cloud platforms
Net Promoter Score (1-10, How likely they are to recommend this service)
Average time to bring a ministry team onboard and enable them to begin deploying an application
Number of digital government services available
Number, duration and cost of outages affecting public cloud digital services

Definition of done
Determine feasibility of measuring each of these KPIs
If any are not feasible, suggest variations or alternatives
Establish repository for recording our KPIs and their measurements (Airtable?)
Record baseline measurements of all KPIs

No longer relevant


Add rossify script

Please verify data integrity with extreme scrutiny
I'm going to tack on the part of the script that adds the current Wagtail user data later.
Test

grab the content dump of auth tables
grab the refresh dump off the server marked with today's date
make a copy of the refresh dump just in case
modify one of the copies to remove the auth table migrations
dump the auth file into a fresh v1 database
cfgov/manage.py migrate auth --fake
cfgov/manage.py migrate
dump the modified refresh dump into the database
cfgov/manage.py runscript rossify_pages
go to users and groups to verify that the content data is there
look around, make users, assign permissions, etc
you'll notice that the Can share pages permission is set for each auth group
you'll also notice that none of the groups have permissions to edit pages (we can just set this later)

Todo's
We'll need to recreate all of our Wagtail users, but that shouldn't be too much of a haul.
Review
@kave @richaagarwal @rosskarchner

the long hours are getting to ya'll 😄

hey i modified the instructions, lemme know if it still makes sense @kurtw

Steps that worked for me, had to do things alittle differently:
After modifying the refresh dump, i imported that first then:

imported content file into a fresh v1 database

noticed all the legacy users/groups etc were intact. haven't run the script yet. i'll do that later tonight

Merging this, because I'll need it in the morning!

ended up getting:
Cannot import module 'scripts.rossify_pages': cannot import name User.
No (valid) module for script 'rossify_pages' found


Pipeline Snakemake glia cell densities rules failing due to atlas-densities

Relevant BBP ticket: https://bbpteam.epfl.ch/project/issues/browse/DKE-1140
Hey y'all,
I've been trying to run the blue_brain_atlas_pipeline using the Singularity image on the cluster, but all of the glia_cell_densities... rules currently fail, even after freshly downloading everything from Nexus Staging. They are all failing at the atlas-densities cell-densities glia-cell-densities steps. Here's an example of a snakemake log from the failure:
[Mon Apr  3 13:53:32 2023]
rule glia_cell_densities_ccfv2_l23split_correctednissl:
    input: cell_density/hierarchy_l23split.json, cell_density/annotation_ccfv2_l23split.nrrd, cell_density/overall_cell_density_ccfv2_l23split_correctednissl, cell_density/glia_ccfv2_l23split.nrrd, cell_density/astrocyte_ccfv2_l23split.nrrd, cell_density/oligodendrocyte_ccfv2_l23split.nrrd, cell_density/microglia_ccfv2_l23split.nrrd, cell_density/glia_proportions_ccfv2_l23split.json
    output: cell_density/cell_densities_ccfv2_l23split_correctednissl/glia_density.nrrd, cell_density/cell_densities_ccfv2_l23split_correctednissl/astrocyte_density.nrrd, cell_density/cell_densities_ccfv2_l23split_correctednissl/oligodendrocyte_density.nrrd, cell_density/cell_densities_ccfv2_l23split_correctednissl/microglia_density.nrrd, cell_density/cell_densities_ccfv2_l23split_correctednissl/neuron_density.nrrd, cell_density/cell_densities_ccfv2_l23split_correctednissl
    log: cell_density/logs/glia_cell_densities_ccfv2_l23split_correctednissl.log
    jobid: 26
    reason: Missing output files: cell_density/cell_densities_ccfv2_l23split_correctednissl/neuron_density.nrrd; Input files updated by another job: cell_density/oligodendrocyte_ccfv2_l23split.nrrd, cell_density/overall_cell_density_ccfv2_l23split_correctednissl, cell_density/glia_proportions_ccfv2_l23split.json, cell_density/astrocyte_ccfv2_l23split.nrrd, cell_density/glia_ccfv2_l23split.nrrd, cell_density/microglia_ccfv2_l23split.nrrd, cell_density/annotation_ccfv2_l23split.nrrd, cell_density/hierarchy_l23split.json
    resources: tmpdir=/tmp

[Mon Apr  3 13:54:46 2023]
Error in rule glia_cell_densities_ccfv2_l23split_correctednissl:
    jobid: 26
    input: cell_density/hierarchy_l23split.json, cell_density/annotation_ccfv2_l23split.nrrd, cell_density/overall_cell_density_ccfv2_l23split_correctednissl, cell_density/glia_ccfv2_l23split.nrrd, cell_density/astrocyte_ccfv2_l23split.nrrd, cell_density/oligodendrocyte_ccfv2_l23split.nrrd, cell_density/microglia_ccfv2_l23split.nrrd, cell_density/glia_proportions_ccfv2_l23split.json
    output: cell_density/cell_densities_ccfv2_l23split_correctednissl/glia_density.nrrd, cell_density/cell_densities_ccfv2_l23split_correctednissl/astrocyte_density.nrrd, cell_density/cell_densities_ccfv2_l23split_correctednissl/oligodendrocyte_density.nrrd, cell_density/cell_densities_ccfv2_l23split_correctednissl/microglia_density.nrrd, cell_density/cell_densities_ccfv2_l23split_correctednissl/neuron_density.nrrd, cell_density/cell_densities_ccfv2_l23split_correctednissl
    log: cell_density/logs/glia_cell_densities_ccfv2_l23split_correctednissl.log (check log file(s) for error details)                                shell:
        atlas-densities cell-densities glia-cell-densities --annotation-path cell_density/annotation_ccfv2_l23split.nrrd             --hierarchy-path cell_density/hierarchy_l23split.json             --cell-density-path cell_density/overall_cell_density_ccfv2_l23split_correctednissl             --glia-density-path cell_density/glia_ccfv2_l23split.nrrd             --astrocyte-density-path cell_density/astrocyte_ccfv2_l23split.nrrd             --oligodendrocyte-density-path cell_density/oligodendrocyte_ccfv2_l23split.nrrd             --microglia-density-path cell_density/microglia_ccfv2_l23split.nrrd             --glia-proportions-path cell_density/glia_proportions_ccfv2_l23split.json             --output-dir cell_density/cell_densities_ccfv2_l23split_correctednissl             2>&1 | tee cell_density/logs/glia_cell_densities_ccfv2_l23split_correctednissl.log
........
        (one of the commands exited with non-zero exit code; note that snakemake uses bash strict mode!)

Removing output files of failed job glia_cell_densities_ccfv2_l23split_correctednissl since they might be corrupted:
cell_density/cell_densities_ccfv2_l23split_correctednissl
Shutting down, this might take some time.
Exiting because a job execution failed. Look above for error message
Complete log: .snakemake/log/2023-04-03T132307.615356.snakemake.log

Here's the actual python error from atlas-densities. The same error (detecting an absolute error larger than the tolerance) is the same for all variations of the glia cell densities rules. I don't know if there's randomness involved in these rules, or if there are deterministic issues at play. Since these glia densities are needed to compute other types of density fields like neuron densities, these errors prevent the rest of the Atlas / new verions from being built, from my understanding.
INFO:atlas_densities.densities.glia_densities:Computing overall glia density field with a target cell count of 39320000 ...
Traceback (most recent call last):
  File "/usr/local/bin/atlas-densities", line 8, in <module>
    sys.exit(cli())
  File "/usr/local/lib/python3.9/site-packages/atlas_densities/app/cli.py", line 24, in cli
    app()
  File "/usr/local/lib/python3.9/site-packages/click/core.py", line 1130, in __call__
    return self.main(*args, **kwargs)
  File "/usr/local/lib/python3.9/site-packages/click/core.py", line 1055, in main
    rv = self.invoke(ctx)
  File "/usr/local/lib/python3.9/site-packages/click/core.py", line 1657, in invoke
    return _process_result(sub_ctx.command.invoke(sub_ctx))
  File "/usr/local/lib/python3.9/site-packages/click/core.py", line 1657, in invoke
    return _process_result(sub_ctx.command.invoke(sub_ctx))
  File "/usr/local/lib/python3.9/site-packages/click/core.py", line 1404, in invoke
    return ctx.invoke(self.callback, **ctx.params)
  File "/usr/local/lib/python3.9/site-packages/click/core.py", line 760, in invoke
    return __callback(*args, **kwargs)
  File "/usr/local/lib/python3.9/site-packages/atlas_commons/app_utils.py", line 51, in wrapper
    function(*args, **kw)
  File "/usr/local/lib/python3.9/site-packages/atlas_densities/app/cell_densities.py", line 313, in glia_cell_densities
    glia_densities = compute_glia_densities(
  File "/usr/local/lib/python3.9/site-packages/atlas_densities/densities/glia_densities.py", line 145, in compute_glia_densities
    glia_densities["glia"] = compute_glia_cell_counts_per_voxel(
  File "/usr/local/lib/python3.9/site-packages/atlas_densities/densities/glia_densities.py", line 62, in compute_glia_cell_counts_per_voxel
    return constrain_cell_counts_per_voxel(
  File "/usr/local/lib/python3.9/site-packages/atlas_densities/densities/utils.py", line 313, in constrain_cell_counts_per_voxel
    raise AtlasDensitiesError(
atlas_densities.exceptions.AtlasDensitiesError: The target sum could not be reached. The absolute error is 0.010990336537361145. It is larger than the tolerance epsilon = 0.001

Thank you for any help you can provide.

@drodarie will have a better idea, but I suspect he'll need access to some of the specific files included in the command:
atlas-densities cell-densities glia-cell-densities                                      \
    --annotation-path cell_density/annotation_ccfv2_l23split.nrrd                       \
    --hierarchy-path cell_density/hierarchy_l23split.json                               \
    --cell-density-path cell_density/overall_cell_density_ccfv2_l23split_correctednissl \
    --glia-density-path cell_density/glia_ccfv2_l23split.nrrd                           \
    --astrocyte-density-path cell_density/astrocyte_ccfv2_l23split.nrrd                 \
    --oligodendrocyte-density-path cell_density/oligodendrocyte_ccfv2_l23split.nrrd     \
    --microglia-density-path cell_density/microglia_ccfv2_l23split.nrrd                 \
    --glia-proportions-path cell_density/glia_proportions_ccfv2_l23split.json           \
    --output-dir cell_density/cell_densities_ccfv2_l23split_correctednissl

I dug in the code a bit. Long story short, in your case, it seems that the placement algorithm fills completely too many voxels with glia cell which prevents it to properly scale the intensity in the other voxels (function utils.optimize_distance_to_line).
This results in an infinite loop, that is prevented by the maximum number of iteration. I will suggest a fix to this bug in a pull request.
Now, while the implementation has definitely some issues, the problem might to be related to your annotation atlas file. Did the snakemake pipeline assembled the two CCFv2 annotation atlases files? Because otherwise the algorithm cannot find the voxels that should be integrally filled with glia cells (fiber tracts regions)

Thanks y'all; Dimitri yes, in each case, most of the computation time was spent in the relevant "combine_..._annotations" rule, before going on to try the glia rules.

I was discussing this with Sebastien Piluso, and he mentioned that he has been able to use this step of atlas-densities successfully ( https://github.com/BlueBrain/atlas-densities#distinguish-neurons-from-glia-cells ) , BUT using the output from him running DeepAtlas ( https://github.com/BlueBrain/atlas-densities#download-realign-and-interpolate-aibs-ish-datasets ). However, the files he got from running DeepAtlas may NOT be (and are probably not) the same as the prerequisite files currently stored on Nexus Staging, which are what is currently used in blue_brain_atlas_pipeline. @lecriste Maybe the problem is that the processed ISH data files (e.g. gene_gad67_correctednissl.nrrd, nissl_corrected_volume.nrrd, etc.) versions which are on Nexus Staging are out of date, or are not the same as the versions used to create the 2021 BBP Atlas?

I think this might have been closed by accident? Unless someone else tested that that commit solved the issue

Perhaps I was hasty; I'm hoping https://github.com/BlueBrain/atlas-densities/pull/28 fixes it.
@lecriste, can you test the commit, and make sure that it passes w/ the pipeline?  If it works, then we can close this.

Yes. I asked Austin to test the standalone command first with his choice of input datasets, and then I will test it w/ the pipeline.

@lecriste > Yes. I asked Austin to test the standalone command first with his choice of input datasets, and then I will test it w/ the pipeline.
I think the pipeline should also be tested right away; I'm a little confused as to how it was working before, but then Austin ran into trouble and it would be good to verify that it's working.

There is no issue related to the pipeline other than the error reported here.
Since you already tested the fix with Austin's choice of the input datasets, I will test it with the pipeline.

First, I did not test my fix with @asoplata datasets because they were not provided within this issue and I do not have access to BBP JIRA. I tested the fix with a toy dataset. So the fix should be tested with Austin's datasets to validate the fix.
Second, even if you face an issue with the same step of the pipeline, the problem might be link to your specific datasets (coming from other repositories), and not the code of atlas-densities.
More generally, I was lucky to have found a bug solely from the description provided by Austin, which I hope is the right one.
IMO, this issue should have been first reported in blue_brain_atlas_pipeline so the process could have been reproduced. Then, if the issue was indeed related to atlas-densities code, then a reproducible example should have been provided.

That's exactly what happened, starting from DKE-1140.
I still can not add you as a watcher...

My apologies for not including reproducible data / script for this bug, I forgot that not everyone has access to everything. I'll try to be better about that in the future.
I'll test this new atlas-densities commit now, and let y'all know the outcome. If I'm still getting the same error (tolerance exceeded), then yeah, the issue could be with the incoming data, not atlas-densities itself. Also, to be clear, I am NOT testing this on custom data of any kind; so far, I have only been using the default blue_brain_atlas_pipeline rules and fetched files with no modifications. In other words, if there are problems with the incoming data I'm testing, then those problems exist for the current pipeline's data.

I think you both miss my main point so I will rephrase it:
atlas-densities is a toolbox: it has functions that allow to compute densities based on literature data and volumetric datasets.
atlas-building-tools is a pipeline which leverage the tools of atlas-densities to build a mouse cell atlas.
You encounter this issue while running the pipeline (not just atlas-densities), you even put a stack trace of atlas-building-tools. Why not putting the issue on atlas-building-tools so we have a better understanding of your process, and also understand how to replicate it?
If the commands of atlas-building-tools are incorrect (e.g. forget to merge the annotation files, using the wrong ISH datasets) there is nothing atlas-densities can do about it!
-> It is as if you were to put an issue on the numpy github because a pandas function (that uses numpy) does not run.
I am just asking you to be more thorough when reporting an issue: Report on the right repository and please provide ways to replicate the issue.

I corrected my previous comment because I used the wrong repo name atlas-building-tools is yet another repo unrelated to this issue. The pipeline repo is blue_brain_atlas_pipeline

Exactly.

Why not putting the issue on blue_brain_atlas_pipeline so we have a better understanding of your process, and also understand how to replicate it?

As I already said, Austin did create a DKE issue first, and only after a few iterations (checking the input annotation files, etc.) I advised him to open this issue.
Probably the input data were not provided also because they are exactly the ones used in this repo README.

Good!
@mgeplf, can we tag a new release of this repo so I can update the atlas pipeline?

@lecriste > can we tag a new release of this repo so I can update the atlas pipeline?
Yup, a new version has been released.


Unable to do mvn clean install package

Am unable to build the package as it says the below errors in multiple files
[ERROR] symbol:   class ObjectId
[ERROR] location: interface com.capitalone.dashboard.service.FeatureService
[ERROR] /D:/Hygieia-master/Hygieia-master/api/src/main/java/com/capitalone/dashb
oard/service/FeatureService.java:[162,27] cannot find symbol
[ERROR] symbol:   class Feature

Please do a "git pull" to ensure you have got everything latest from the repository.
And then do a maven clean build with -X option to enable debug logging so we have more information on the failure. Thanks !

Muraliece88: Wanted to follow up and check if you are still facing this issue? Thanks !

@Muraliece88: Since we didn't hear back from you, assuming your issue has been resolved. Closing this current issue. Thanks !


feat: worker host env api error, add clipboard

Types

[x] 🐛 Bug Fixes

Background or solution
Changelog

worker host env api error, add clipboard

/publish

/publish

/publish