Deploy command fails with context cancelled

Operating system
openSUSE Tumbleweed 20240307
Kluctl Version
2.23.5
Kubernetes Version
v1.28.7+k3s1
kubectl Version
v1.28.7
Bug description
I am currently trying to deploy a (modified for kluctl) version of https://github.com/abacf/sae503 and it fails when deploying and deleting with context canceled
Steps to reproduce
No response
Relevant log output
✓ Loading kluctl project
✓ Initializing k8s client
✓ Rendering templates
✓ Rendering Helm Charts
✓ Building kustomize objects
✓ Postprocessing objects
✓ Writing rendered objects
✓ Getting remote objects by discriminator
✓ Getting 91 additional remote objects
✓ Getting namespaces
✓ kube/namespaces: Applied 3 objects.
✓ kube/prometheus/setup/setup: Applied 16 objects.
✓ kube/traefik: Applied 29 objects. Encountered 4 warnings.
✓ Finished waiting
✓ kube/routes: Applied 3 objects. Encountered 3 warnings.
✓ kube/prometheus/setup: Applied 104 objects. Encountered 23 warnings.
✓ Finished waiting
✓ kube/app: Applied 9 objects. Encountered 3 warnings.

New objects:
  Namespace/staging
  Namespace/prod
  Namespace/dev
  CustomResourceDefinition/podmonitors.monitoring.coreos.com
  CustomResourceDefinition/ingressrouteudps.traefik.containo.us
  CustomResourceDefinition/tlsstores.traefik.containo.us
  CustomResourceDefinition/middlewaretcps.traefik.containo.us
  CustomResourceDefinition/scrapeconfigs.monitoring.coreos.com
  CustomResourceDefinition/probes.monitoring.coreos.com
  CustomResourceDefinition/tlsstores.traefik.io
  CustomResourceDefinition/traefikservices.traefik.io
  CustomResourceDefinition/ingressroutes.traefik.containo.us
  CustomResourceDefinition/serverstransports.traefik.containo.us
  CustomResourceDefinition/tlsoptions.traefik.io
  CustomResourceDefinition/middlewares.traefik.io
  CustomResourceDefinition/servicemonitors.monitoring.coreos.com
  CustomResourceDefinition/thanosrulers.monitoring.coreos.com
  CustomResourceDefinition/middlewaretcps.traefik.io
  CustomResourceDefinition/middlewares.traefik.containo.us
  CustomResourceDefinition/alertmanagers.monitoring.coreos.com
  CustomResourceDefinition/ingressrouteudps.traefik.io
  CustomResourceDefinition/alertmanagerconfigs.monitoring.coreos.com
  CustomResourceDefinition/serverstransports.traefik.io
  CustomResourceDefinition/ingressroutetcps.traefik.containo.us
  CustomResourceDefinition/prometheusagents.monitoring.coreos.com
  CustomResourceDefinition/traefikservices.traefik.containo.us
  CustomResourceDefinition/ingressroutes.traefik.io
  CustomResourceDefinition/prometheuses.monitoring.coreos.com
  CustomResourceDefinition/ingressroutetcps.traefik.io
  CustomResourceDefinition/tlsoptions.traefik.containo.us
  CustomResourceDefinition/prometheusrules.monitoring.coreos.com
  APIService/v1beta1.metrics.k8s.io
  default/Alertmanager/main
  default/Prometheus/k8s
  default/PrometheusRule/prometheus-k8s-prometheus-rules
  default/PrometheusRule/grafana-rules
  default/PrometheusRule/kubernetes-monitoring-rules
  default/PrometheusRule/alertmanager-main-rules
  default/PrometheusRule/prometheus-operator-rules
  default/PrometheusRule/kube-prometheus-rules
  default/PrometheusRule/node-exporter-rules
  default/PrometheusRule/kube-state-metrics-rules
  default/ServiceMonitor/prometheus-adapter
  default/ServiceMonitor/kubelet
  default/ServiceMonitor/app-default-rubis-metrics
  default/ServiceMonitor/traefik-monitor
  default/ServiceMonitor/prometheus-k8s
  default/ServiceMonitor/node-exporter
  default/ServiceMonitor/kube-controller-manager
  default/ServiceMonitor/grafana
  default/ServiceMonitor/coredns
  default/ServiceMonitor/redis-default-metrics
  default/ServiceMonitor/kube-scheduler
  default/ServiceMonitor/kube-apiserver
  default/ServiceMonitor/prometheus-operator
  default/ServiceMonitor/blackbox-exporter
  default/ServiceMonitor/kube-state-metrics
  default/ServiceMonitor/alertmanager-main
  ClusterRole/resource-metrics-server-resources
  ClusterRole/blackbox-exporter
  ClusterRole/traefik-ingress-controller
  ClusterRole/prometheus-adapter
  ClusterRole/kube-state-metrics
  ClusterRole/node-exporter
  ClusterRole/system:aggregated-metrics-reader
  ClusterRole/prometheus-operator
  ClusterRole/prometheus-k8s
  ClusterRoleBinding/prometheus-adapter
  ClusterRoleBinding/node-exporter
  ClusterRoleBinding/blackbox-exporter
  ClusterRoleBinding/kube-state-metrics
  ClusterRoleBinding/traefik-ingress-controller
  ClusterRoleBinding/resource-metrics:system:auth-delegator
  ClusterRoleBinding/prometheus-k8s
  ClusterRoleBinding/prometheus-operator
  staging/Role/prometheus-k8s
  kube-system/Role/prometheus-k8s
  dev/Role/prometheus-k8s
  prod/Role/prometheus-k8s
  dev/RoleBinding/prometheus-k8s
  staging/RoleBinding/prometheus-k8s
  kube-system/RoleBinding/prometheus-k8s
  kube-system/RoleBinding/resource-metrics-auth-reader
  prod/RoleBinding/prometheus-k8s
  default/IngressRoute/traefik
  default/IngressRoute/traefik-metrics
  default/Middleware/basic-auth
  default/IngressRoute/grafana-ingressroute
  default/IngressRoute/app-default-rubis-ingress
  default/IngressRoute/alertmanager-ingressroute
  default/IngressRoute/prometheus-ingressroute

Warnings:
  default/Middleware/basic-auth: the underyling custom resource definition for default/Middleware/basic-auth has not been applied yet as Kluctl is running in dry-run mode. It is not guaranteed that the object will actually sucessfully apply
  default/IngressRoute/traefik-metrics: the underyling custom resource definition for default/IngressRoute/traefik-metrics has not been applied yet as Kluctl is running in dry-run mode. It is not guaranteed that the object will actually sucessfully apply
  default/PrometheusRule/kubernetes-monitoring-rules: the underyling custom resource definition for default/PrometheusRule/kubernetes-monitoring-rules has not been applied yet as Kluctl is running in dry-run mode. It is not guaranteed that the object will actually sucessfully apply
  default/PrometheusRule/node-exporter-rules: the underyling custom resource definition for default/PrometheusRule/node-exporter-rules has not been applied yet as Kluctl is running in dry-run mode. It is not guaranteed that the object will actually sucessfully apply
  default/Prometheus/k8s: the underyling custom resource definition for default/Prometheus/k8s has not been applied yet as Kluctl is running in dry-run mode. It is not guaranteed that the object will actually sucessfully apply
  default/ServiceMonitor/redis-default-metrics: the underyling custom resource definition for default/ServiceMonitor/redis-default-metrics has not been applied yet as Kluctl is running in dry-run mode. It is not guaranteed that the object will actually sucessfully apply
  default/ServiceMonitor/alertmanager-main: the underyling custom resource definition for default/ServiceMonitor/alertmanager-main has not been applied yet as Kluctl is running in dry-run mode. It is not guaranteed that the object will actually sucessfully apply
  default/ServiceMonitor/grafana: the underyling custom resource definition for default/ServiceMonitor/grafana has not been applied yet as Kluctl is running in dry-run mode. It is not guaranteed that the object will actually sucessfully apply
  default/PrometheusRule/kube-prometheus-rules: the underyling custom resource definition for default/PrometheusRule/kube-prometheus-rules has not been applied yet as Kluctl is running in dry-run mode. It is not guaranteed that the object will actually sucessfully apply
  default/ServiceMonitor/kube-state-metrics: the underyling custom resource definition for default/ServiceMonitor/kube-state-metrics has not been applied yet as Kluctl is running in dry-run mode. It is not guaranteed that the object will actually sucessfully apply
  default/ServiceMonitor/kube-scheduler: the underyling custom resource definition for default/ServiceMonitor/kube-scheduler has not been applied yet as Kluctl is running in dry-run mode. It is not guaranteed that the object will actually sucessfully apply
  default/ServiceMonitor/app-default-rubis-metrics: the underyling custom resource definition for default/ServiceMonitor/app-default-rubis-metrics has not been applied yet as Kluctl is running in dry-run mode. It is not guaranteed that the object will actually sucessfully apply
  default/Alertmanager/main: the underyling custom resource definition for default/Alertmanager/main has not been applied yet as Kluctl is running in dry-run mode. It is not guaranteed that the object will actually sucessfully apply
  default/ServiceMonitor/node-exporter: the underyling custom resource definition for default/ServiceMonitor/node-exporter has not been applied yet as Kluctl is running in dry-run mode. It is not guaranteed that the object will actually sucessfully apply
  default/ServiceMonitor/prometheus-operator: the underyling custom resource definition for default/ServiceMonitor/prometheus-operator has not been applied yet as Kluctl is running in dry-run mode. It is not guaranteed that the object will actually sucessfully apply
  default/ServiceMonitor/traefik-monitor: the underyling custom resource definition for default/ServiceMonitor/traefik-monitor has not been applied yet as Kluctl is running in dry-run mode. It is not guaranteed that the object will actually sucessfully apply
  default/IngressRoute/prometheus-ingressroute: the underyling custom resource definition for default/IngressRoute/prometheus-ingressroute has not been applied yet as Kluctl is running in dry-run mode. It is not guaranteed that the object will actually sucessfully apply
  default/ServiceMonitor/kube-apiserver: the underyling custom resource definition for default/ServiceMonitor/kube-apiserver has not been applied yet as Kluctl is running in dry-run mode. It is not guaranteed that the object will actually sucessfully apply
  default/ServiceMonitor/coredns: the underyling custom resource definition for default/ServiceMonitor/coredns has not been applied yet as Kluctl is running in dry-run mode. It is not guaranteed that the object will actually sucessfully apply
  default/PrometheusRule/prometheus-k8s-prometheus-rules: the underyling custom resource definition for default/PrometheusRule/prometheus-k8s-prometheus-rules has not been applied yet as Kluctl is running in dry-run mode. It is not guaranteed that the object will actually sucessfully apply
  default/PrometheusRule/prometheus-operator-rules: the underyling custom resource definition for default/PrometheusRule/prometheus-operator-rules has not been applied yet as Kluctl is running in dry-run mode. It is not guaranteed that the object will actually sucessfully apply
  default/ServiceMonitor/prometheus-k8s: the underyling custom resource definition for default/ServiceMonitor/prometheus-k8s has not been applied yet as Kluctl is running in dry-run mode. It is not guaranteed that the object will actually sucessfully apply
  default/IngressRoute/traefik: the underyling custom resource definition for default/IngressRoute/traefik has not been applied yet as Kluctl is running in dry-run mode. It is not guaranteed that the object will actually sucessfully apply
  default/IngressRoute/alertmanager-ingressroute: the underyling custom resource definition for default/IngressRoute/alertmanager-ingressroute has not been applied yet as Kluctl is running in dry-run mode. It is not guaranteed that the object will actually sucessfully apply
  default/IngressRoute/grafana-ingressroute: the underyling custom resource definition for default/IngressRoute/grafana-ingressroute has not been applied yet as Kluctl is running in dry-run mode. It is not guaranteed that the object will actually sucessfully apply
  default/ServiceMonitor/blackbox-exporter: the underyling custom resource definition for default/ServiceMonitor/blackbox-exporter has not been applied yet as Kluctl is running in dry-run mode. It is not guaranteed that the object will actually sucessfully apply
  default/ServiceMonitor/kube-controller-manager: the underyling custom resource definition for default/ServiceMonitor/kube-controller-manager has not been applied yet as Kluctl is running in dry-run mode. It is not guaranteed that the object will actually sucessfully apply
  default/IngressRoute/app-default-rubis-ingress: the underyling custom resource definition for default/IngressRoute/app-default-rubis-ingress has not been applied yet as Kluctl is running in dry-run mode. It is not guaranteed that the object will actually sucessfully apply
  default/PrometheusRule/alertmanager-main-rules: the underyling custom resource definition for default/PrometheusRule/alertmanager-main-rules has not been applied yet as Kluctl is running in dry-run mode. It is not guaranteed that the object will actually sucessfully apply
  default/PrometheusRule/grafana-rules: the underyling custom resource definition for default/PrometheusRule/grafana-rules has not been applied yet as Kluctl is running in dry-run mode. It is not guaranteed that the object will actually sucessfully apply
  default/PrometheusRule/kube-state-metrics-rules: the underyling custom resource definition for default/PrometheusRule/kube-state-metrics-rules has not been applied yet as Kluctl is running in dry-run mode. It is not guaranteed that the object will actually sucessfully apply
  default/ServiceMonitor/kubelet: the underyling custom resource definition for default/ServiceMonitor/kubelet has not been applied yet as Kluctl is running in dry-run mode. It is not guaranteed that the object will actually sucessfully apply
  default/ServiceMonitor/prometheus-adapter: the underyling custom resource definition for default/ServiceMonitor/prometheus-adapter has not been applied yet as Kluctl is running in dry-run mode. It is not guaranteed that the object will actually sucessfully apply
✓ The diff succeeded, do you want to proceed? (y/N) yyyy
⚠ Please type yes or no and then press enter!
✓ The diff succeeded, do you want to proceed? (y/N) y
✓ kube/namespaces: Applied 3 objects.
✓ kube/prometheus/setup/setup: Applied 16 objects.
✓ kube/traefik: Applied 29 objects.
✓ Finished waiting
✓ kube/routes: Applied 3 objects.
✓ kube/prometheus/setup: Applied 104 objects.
✓ Finished waiting
✓ kube/app: Applied 9 objects.
✓ Writing command result

New objects:
  Namespace/prod
  Namespace/dev
  Namespace/staging
  CustomResourceDefinition/serverstransports.traefik.containo.us
  CustomResourceDefinition/prometheusrules.monitoring.coreos.com
  CustomResourceDefinition/ingressroutetcps.traefik.io
  CustomResourceDefinition/middlewares.traefik.io
  CustomResourceDefinition/thanosrulers.monitoring.coreos.com
  CustomResourceDefinition/middlewares.traefik.containo.us
  CustomResourceDefinition/tlsoptions.traefik.io
  CustomResourceDefinition/prometheusagents.monitoring.coreos.com
  CustomResourceDefinition/prometheuses.monitoring.coreos.com
  CustomResourceDefinition/middlewaretcps.traefik.containo.us
  CustomResourceDefinition/ingressrouteudps.traefik.io
  CustomResourceDefinition/ingressroutetcps.traefik.containo.us
  CustomResourceDefinition/middlewaretcps.traefik.io
  CustomResourceDefinition/traefikservices.traefik.containo.us
  CustomResourceDefinition/scrapeconfigs.monitoring.coreos.com
  CustomResourceDefinition/podmonitors.monitoring.coreos.com
  CustomResourceDefinition/servicemonitors.monitoring.coreos.com
  CustomResourceDefinition/serverstransports.traefik.io
  CustomResourceDefinition/ingressroutes.traefik.io
  CustomResourceDefinition/traefikservices.traefik.io
  CustomResourceDefinition/alertmanagerconfigs.monitoring.coreos.com
  CustomResourceDefinition/ingressrouteudps.traefik.containo.us
  CustomResourceDefinition/ingressroutes.traefik.containo.us
  CustomResourceDefinition/alertmanagers.monitoring.coreos.com
  CustomResourceDefinition/tlsstores.traefik.io
  CustomResourceDefinition/tlsoptions.traefik.containo.us
  CustomResourceDefinition/tlsstores.traefik.containo.us
  CustomResourceDefinition/probes.monitoring.coreos.com
  APIService/v1beta1.metrics.k8s.io
  default/Alertmanager/main
  default/Prometheus/k8s
  default/PrometheusRule/node-exporter-rules
  default/PrometheusRule/grafana-rules
  default/PrometheusRule/kubernetes-monitoring-rules
  default/PrometheusRule/prometheus-k8s-prometheus-rules
  default/PrometheusRule/prometheus-operator-rules
  default/PrometheusRule/kube-prometheus-rules
  default/PrometheusRule/kube-state-metrics-rules
  default/PrometheusRule/alertmanager-main-rules
  default/ServiceMonitor/kube-apiserver
  default/ServiceMonitor/prometheus-adapter
  default/ServiceMonitor/kube-scheduler
  default/ServiceMonitor/kubelet
  default/ServiceMonitor/redis-default-metrics
  default/ServiceMonitor/kube-controller-manager
  default/ServiceMonitor/traefik-monitor
  default/ServiceMonitor/node-exporter
  default/ServiceMonitor/prometheus-operator
  default/ServiceMonitor/grafana
  default/ServiceMonitor/coredns
  default/ServiceMonitor/kube-state-metrics
  default/ServiceMonitor/blackbox-exporter
  default/ServiceMonitor/alertmanager-main
  default/ServiceMonitor/prometheus-k8s
  default/ServiceMonitor/app-default-rubis-metrics
  ClusterRole/kube-state-metrics
  ClusterRole/system:aggregated-metrics-reader
  ClusterRole/node-exporter
  ClusterRole/prometheus-operator
  ClusterRole/prometheus-k8s
  ClusterRole/traefik-ingress-controller
  ClusterRole/prometheus-adapter
  ClusterRole/blackbox-exporter
  ClusterRole/resource-metrics-server-resources
  ClusterRoleBinding/blackbox-exporter
  ClusterRoleBinding/traefik-ingress-controller
  ClusterRoleBinding/resource-metrics:system:auth-delegator
  ClusterRoleBinding/prometheus-k8s
  ClusterRoleBinding/kube-state-metrics
  ClusterRoleBinding/prometheus-adapter
  ClusterRoleBinding/node-exporter
  ClusterRoleBinding/prometheus-operator
  staging/Role/prometheus-k8s
  prod/Role/prometheus-k8s
  kube-system/Role/prometheus-k8s
  dev/Role/prometheus-k8s
  dev/RoleBinding/prometheus-k8s
  kube-system/RoleBinding/prometheus-k8s
  prod/RoleBinding/prometheus-k8s
  staging/RoleBinding/prometheus-k8s
  kube-system/RoleBinding/resource-metrics-auth-reader
  default/IngressRoute/traefik
  default/IngressRoute/traefik-metrics
  default/Middleware/basic-auth
  default/IngressRoute/alertmanager-ingressroute
  default/IngressRoute/app-default-rubis-ingress
  default/IngressRoute/grafana-ingressroute
  default/IngressRoute/prometheus-ingressroute

Errors:
  invalid checksum
ⓘ E0326 11:00:55.439203   29905 reflector.go:147] pkg/mod/k8s.io/client-go@v0.29.2/tools/cache/reflector.go:229: Failed to watch *v1.PartialObjectMetadata: Get "https://<IP_ADDRESS>:6443/api/v1/secrets?allowWatchBookmarks=true&labelSelector=kluctl.io%2Fresult&resourceVersion=3911&timeout=6m53s&timeoutSeconds=413&watch=true": context canceled
ⓘ E0326 11:00:55.439203   29905 reflector.go:147] pkg/mod/k8s.io/client-go@v0.29.2/tools/cache/reflector.go:229: Failed to watch *v1.PartialObjectMetadata: Get "https://<IP_ADDRESS>:6443/api/v1/secrets?allowWatchBookmarks=true&labelSelector=kluctl.io%2Fresult&resourceVersion=3911&timeout=6m53s&timeoutSeconds=413&watch=true": context canceled
ⓘ E0326 11:00:55.439203   29905 reflector.go:147] pkg/mod/k8s.io/client-go@v0.29.2/tools/cache/reflector.go:229: Failed to watch *v1.PartialObjectMetadata: Get "https://<IP_ADDRESS>:6443/api/v1/secrets?allowWatchBookmarks=true&labelSelector=kluctl.io%2Fresult&resourceVersion=3911&timeout=6m53s&timeoutSeconds=413&watch=true": context canceled
ⓘ E0326 11:00:55.439203   29905 reflector.go:147] pkg/mod/k8s.io/client-go@v0.29.2/tools/cache/reflector.go:229: Failed to watch *v1.PartialObjectMetadata: Get "https://<IP_ADDRESS>:6443/api/v1/secrets?allowWatchBookmarks=true&labelSelector=kluctl.io%2Fresult&resourceVersion=3911&timeout=6m53s&timeoutSeconds=413&watch=true": context canceled
✗ command failed

@signed-log Thanks for reporting this. Does this happen every time or just from time to time?
I've seen this as well in the past and it seems to be caused by some background tasks, but so far did not cause failure of the command itself. I assume the command failure you see is actually cause by the "invalid checksum" which you already reported in #1032

I might have resolved the issue, since my kubectl and k3s clusters were not on the same version.
By downgrading kubectl from v1.29 to v1.28 branch, I don't get that error anymore

@signed-log Hmm, your local kubectl version schon have no effect on Kluctl as it does not use the kubectl binary. It uses the  k8s client-go and controller-runtime libraries for k8s API access.

I'm also seeing this - seems to happen and then on some retries succeeds. In my case there is an operator that is creating CRDs in the cluster. Could it be connected to this?


add ansible,bash scripts and documentation for podman testing

Signed-off-by: anandrkskd<EMAIL_ADDRESS>What type of PR is this:
/kind tests
What does this PR do / why we need it:
This PR adds Ansible and bash scripts that will be used to set up and run odo tests against podman.
Which issue(s) this PR fixes:
Fixes #6340
PR acceptance criteria:

[ ] Unit test

[ ] Integration test

[x] Documentation

How to test changes / Special notes to the reviewer:

We can use create edge case that we discussed in here, by using config for podman, here is a test run that checked that part.
@feloy, @rm3l, do you want me to remove the config file for podman as well, as it could be used in tests in future?

@anandrkskd during the test, I can see you get this error:

I can see the test-reporter action is failing because of Error: TypeError: stackTrace.split is not a function..
To not block this PR, it is okay to me if we implement the reporting part in a separate PR if you prefer..

@anandrkskd Can you also update the title of this PR to reflect what this PR now does?
The title will show up as the squash commit message in the Git history, and as it is it does not help to understand what this commit does.

/retest

• [FAILED] [45.875 seconds]
odo logs command tests
/go/odo_1/tests/integration/cmd_logs_test.go:14
  when component is created and odo logs is executed
  /go/odo_1/tests/integration/cmd_logs_test.go:69
    when running in Deploy mode
    /go/odo_1/tests/integration/cmd_logs_test.go:129
      [It] should successfully show logs of the running component
      /go/odo_1/tests/integration/cmd_logs_test.go:136

...
Expected
      <string>: main: Thu Jan  5 13:14:44 UTC 2023 - this is infinite while loop
      main[1]:
      main[1]: ><EMAIL_ADDRESS>start /opt/app-root/src
      main[1]: > node server.js
      main[1]:
      main[1]: App started on PORT 3000

  to contain substring
      <string>: main[2]:
  In [It] at: /go/odo_1/tests/helper/helper_generic.go:79
...
Summarizing 1 Failure:
  [FAIL] odo logs command tests when component is created and odo logs is executed when running in Deploy mode [It] should successfully show logs of the running component
  /go/odo_1/tests/helper/helper_generic.go:79

Ran 343 of 603 Specs in 1155.129 seconds
FAIL! -- 342 Passed | 1 Failed | 0 Pending | 260 Skipped

Overriding because this is not related to this PR, but I'm taking a look at this issue as I saw this error reported on more than 2 other PRs.
/override OpenShift-Integration-tests/OpenShift-Integration-tests

Infra errors on Prow.
/override ci/prow/v4.11-integration-e2e


Layout issues on iOS 8

It looks like some of the CSS fails to display correctly on iOS 8.
Unfortunately, this makes it impossible to use the console color picker, amongst other glitches.
For example,

The 'GAME' button in-console is also incorrectly positioned.

iOS 8 was a long time ago (sorry I didn't get around to looking at it). Closing as 'wontfix' for the time being--happy to take a look issues raised against newer versions of iOS and iPadOS (of which there seem to be a few).


game interaction continues after end

we can still interact with the game tiles even after the game ends

Fixed


The code is not excutable

I am very interested in this work. But the code provided is not excutable. The preprocessing part is missing and
a lot of parameters is blank.
Looking forward to excutable code if possilbe.

The parameter setting is shown in the paper. And the preprocessing part is implemented with dgl library. The code is executable if your inputs are dgl graphs. The original dgl graphs are so big, you can generate graphs according to the paper.


Physical/Transition segmentation

From Jeremy Lawson,
I do think the segmentation of transition and physical risk implicit in the report is not ideal. The sections on high physical risk scenarios, for example, generally don’t acknowledge that because they are also scenarios in which the transition is slower, many of the effects on securities outlined in the orderly and disorderly scenarios effectively reverse. I have tried to be explicit about this in my section, but there would be a benefit in saying this in the front of the document.

Useful feedback, the intent of the existing split was to reduce the number of unique bits of text that would need to be written but get that multi-purposing the sections makes it harder to write.  One way out might be giving the option to write scenario specific text as well as the transition/physical.  Need to consider design.


feat: add typescript bindings

Add Typescript bindings. Without it, typescript projects will show errors:

Thanks @IlyaSemenov looks good!

:tada: This PR is included in version 2.17.0 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Enforce Canvas to be LTR to support Moveable

Summary

Relevant Technical Choices

To-do

User-facing changes

Testing Instructions

Turn on RTL Tester plugin or change your locale to RTL language.
Add some elements, move them around and resize
Verify that the elements move as expected
Test that left and right arrow keys move the elements as expected
Test that the text written in the edit mode is still working RTL. (Cursor is in the "beginning" of the text for LTR people)

Fixes #508

Is there any way we can add Karma tests for this?
We'd need to dynamically change the text direction. This requires changing isRTL in the config, and probably also setting dir="rtl" on the root node.
So maybe something like this in fixture.js (like setFlags):
/**
 * Update the config.
 *
 * For instance, to test in right-to-left mode, call `setConfig` before
 * calling the `render()` method:
 * ```
 * beforeEach(async () => {
 *   fixture = new Fixture();
 *   fixture.setConfig({isRTL: true});
 *   await fixture.render();
 * });
 * ```
 *
 * @param {Object} config Config.
 */
setConfig(config) {
  this._config = { ...this._config, ...config };
}

And then in the Fixture.render() method:
root.setAttribute('dir', this._config.isRTL ? 'rtl' : 'ltr' );

This way we could write a simple test that verifies that the layout is flipped (by taking snapshot) and that the Moveable works as expected.
Could also be added for dashboard easily

Hmm, the screenshots display just a white screen for some reason 😕

Verified in QA


PRIORITY: Show progress to roadmap targets

As a [description of user]?
member of the general public in BC,
I want to [functionality]
see BC's roadmap represented visually, with "waypoints",
So that [benefit]
understand if we are on track to meet these targets.
Additional context
Relevant Summary: see that government's goals are measurable and see measures of our progress toward them
Acceptance Criteria
Agreed-upon confirmation of the requirements when done can be deemed as complete

Need for measurable targets captured in #80 but keeping this open for the added context of "visual"


Feature Request : Maintain constant state through reboot

It would be nice when doing OTA updates in ESPHome for Beken chips for the GPIOs not to reset. This is undesirable if you have something like a server or router plugged in and your plug briefly turns off.
From ESPHome page
early_pin_init (Optional, boolean): Specifies whether pins should be initialised as early as possible to known values. Recommended value is false where switches are involved, as these will toggle when updating the firmware or when restarting the device. Defaults to true.

This might be a hardware limitation, as the state is lost before ESPHome can init it.  This would probably need something similar to ESP32's gpio_hold_en/gpio_hold_dis which the BDK doesn't appear to have.
This is difficult to verify how Tuya handled it, as firmware upgrades are so rare on their platform.

this platform (Beken BK7231) is an APP/OTA style, which is different than the usual APP/APP, which means part of the boot process is applying the OTA which is not handled by an OS, but rather the bootloader

Somewhat off topic here, but could this be related to the reason why sometimes the OTA image flashes successfuly but doesn't update the App partition?    A forum post over at Elektroda suggested grounding TX1 while applying power to the device (more specifically they said hold the external button which is connected to TX1 down whilst removing power, and keeping it held while applying power).  Seems to work reliably but I haven't found any material yet that explains the correct method to force apply the OTA.


Display error message when OAuth access_denied occurs

The pop-up window just closes on an error in authentication right now. It would be better to display an error message in addition to this.

The OAuth flow displays an error message now.

Hi @vinodc, we are seeing this error on our end, and I believe it is happening in the file picker during the authentication step. When we do the code exchange on the server to v1/oauth/token after authentication, we just get back an error from Kloudless that says access_denied. I didn't see this on the Error Code Table so I'm not sure why this is occurring. Is this the access_denied from the user, as in they didn't enter the correct credentials? Or perhaps their organization settings didn't allow access?
Thanks!

Hi @vinodc, we are seeing this error on our end, and I believe it is happening in the file picker during the authentication step. When we do the code exchange on the server to v1/oauth/token after authentication, we just get back an error from Kloudless that says access_denied. I didn't see this on the Error Code Table so I'm not sure why this is occurring. Is this the access_denied from the user, as in they didn't enter the correct credentials? Or perhaps their organization settings didn't allow access?
Thanks!

Hi @JackWCollins. That error is part of the OAuth spec and usually indicates that the user has either denied granting access, or the third-party service has denied the user the ability to grant access to the level requested.

Hi @JackWCollins. That error is part of the OAuth spec and usually indicates that the user has either denied granting access, or the third-party service has denied the user the ability to grant access to the level requested.


eject (feature request)

Were you planning on re-adding the eject disk hotkey function from 3RXV2? It was actually rather useful.

I almost have this done. The new version will eject both CDs/DVDs/etc and USB disks, I just need to do a little more testing and I'll get it posted.

Sounds great, take your time.

B5 implements eject functionality:
http://matthew.malensek.net/projects/3RVX/3RVX3-B5.zip
The hotkey UI needs a little improvement (showing the drive letter in the list) but it seems to be working on my setup.

Works with disk drive, haven't had time to do much testing on anything else.


Discussion about Kubbs future

After 2 years working on Kubb, I decided to deprecate Kubb. I started this project as a hobby project to make it possible to generate code based on a specific input. I looked at some plugin systems like Webpack and Rollup and took some of their concepts to create Kubb plugins. This made it possible to separate the logic and develop plugins per use cases.
After that, I had a look at how Kubb's core could be used to transform a Swagger/OpenAPI file to generate code. Thinking about a plugin that could generate types, React-Query hooks, Zod schemas and so on. After some refactoring and rethinking about the core of Kubb, I came up with a system of plugins(one for ts, one for React-Query, ..). That made it easy to update plugin x without the need to make changes in the core of Kubb. For v1 of Kubb that was working fine but more and more I was getting questions about customizations and that is why in v2 I created a new feature called 'templates'.
Templates made it possible to use JSX to create files, use hooks to retrieve information of a specific operation in the Oas/Swagger but that also made it more complex to onboard new maintainers. Suddenly, you also needed to understand how templates work to make changes in Kubb.
I still believe that templates could be something useful to create files based on what most React developers already know: JSX. But that was probably not the perfect change because that made Kubb a little bit harder to understand.
Those 2 layers are also why I had the idea with v3 of Kubb to change that. By removing templates and unnecessary parts so I could create a version that was only focused on the OpenAPI/Swagger to js/ts files. But refactoring this would take some time and doing this on my own would not be possible. I'm quite occupied with my job as front-end lead and I'm also planning to start a photography 📷 business soon.
So that's why I thought about deprecating Kubb and forwarding all developers to use Orval instead.
I had a lot of fun creating Kubb and learned a lot about generation and Oas but sadly this will be the end of Kubb. 👋🏽

Update: after some discussions with some of you I decided to revert the deprecation warnings and take the opportunity to share more about how Kubb works with some of you that want to help out and contribute. This means Kubb is not dead but for the moment no feature will be added until everything has been cleared out. This means there is still a chance that a v3 of Kubb will come but I will leave that up to the community what will be included.

Stijn

I'm sorry to hear that, I really appreciate the contribution you're making and I really hope you have some free time to keep working on this project. It's the best project I've ever seen. Very competent approach to development, it's a source of inspiration for me. Good luck!

@stijnvanhulle
Couldn't agree with @motionrus more, really awesome work and looking forward to using your next project, as I wasn't able to yet use this one!

How about @nestia/editor case?
It also supports every versions of OpenAPI, and provides mockup simulator too.
https://nestia.io/docs/editor/

This is a sad time, I have been working with kubb for the last 6 months , its a brilliant tool and was the creme de la creme of value I brought to my company.

Thank you a lot for your efforts you've put into kubb. It helped me a lot and it was a pleasure contributing. But I also want to thank you for announing the deprecation and not just orphan it.

I only recently discovered Kubb, and it's been working perfectly for us!
Unfortunate (for me) to see this deprecation notice, though I appreciate the up-front decision and transparency. Thank you very much for making it in the first place! Best of luck!

so I could create a version that was only focused on the OpenAPI/Swagger to js/ts files.

+1 on this. Kubb provides much value. But the @kubb/core library still feels heavy at 1.45MB..


Upload file .docx or xlsx always converted to tmp file

$file_documentt = $request->file('documentt');
$cloudinaryImage = $file_documentt->storeOnCloudinary('folder_name');
$url_doc = $cloudinaryImage->getSecurePath();
$public_id_doc = $cloudinaryImage->getPublicId();

basicly this code for storing file with extension .docx or .xlsx
what i'm supposed to change so that file with extension .docx or .xlsx won't turn into format tmp file?

Forgive me for not understanding, but isn't cloudinary for images and videos not for documents?
I'll ping @colbyfayock to clarify this.

You can upload pretty much anything to Cloudinary. Non image and video files are treated as "Raw" and don't include a preview in the Media Library (UI).
https://cloudinary.com/documentation/cloudinary_glossary#raw_asset

what brad said :)

Okay cool, thanks for clarification. Marked this as a bug.


Run unit test on windows

Description
Some bugs are not covered as they are os-specific. Like https://github.com/cloudskiff/driftctl/pull/651
We should setup a windows run in CircleCI to detect theses cases in the future. Maybe we can use CircleCI windows executor https://circleci.com/docs/2.0/executor-types/#using-the-windows-executor

UpVote! 🚀


File name - support

hi there linux novice here need a little help with -o out command
youtube-dl -o '%(uploader)s/%(playlist)s/%(title)s%(id)s.%(ext)s'
uploader/playlist/videotitle videoid.mp4 is the out but what im looking is the id to be within [] so it would look like
uploader/playlist/videotitle [videoid].mp4
is this even possible?
Thanks in advance
Mark

Put brackets into -o and you'll get brackets.


docs: Add Firebird dialect to ECOSYSTEM.md

Mention (knex-firebird-dialect)[https://github.com/Tomas2D/knex-firebird-dialect] library in ECOSYSTEM.md
Related to following issues: #691, #2766, #3511

thank you!


tests multiple python versions in test pipeline

This PR:

runs the test pipeline with all supported python versions instead of only Python 3.8
adds a badge for the test status on master to the README

💪  LGTM


Fixed NSUserDefaults setBool: using incorrect bool objects.

-setBool: was setting an NSString instead of bool NSNumber.

:shipit:

:shipit:

In CI build

CI build successful

@triplef thanks!

@mnithish thanks for the quick merge!


Add UserAgent to SiteRunner headers.

Per topaz @ https://www.reddit.com/r/adventofcode/comments/z9dhtd/please_include_your_contact_info_in_the_useragent/ requests should now include UserAgent headers with contact information of the project maintainer.

Thanks, Andrew! Without your pull request I would have missed this request from topaz at reddit. I also updated nuget package


Cap readable-stream at 4.4.1

Please select one of the following

[ ] I am removing an existing difference between facebook/react-native and microsoft/react-native-macos :thumbsup:
[ ] I am cherry-picking a change from Facebook's react-native into microsoft/react-native-macos :thumbsup:
[ ] I am making a fix / change for the macOS implementation of react-native
[x] I am making a change required for Microsoft usage of react-native

Summary:
#1954 bumped readable-stream to 4.4.2, which depends on an old version of string_decoder. Luckily, we can avoid having to use this by capping readable-stream at 4.4.1.
Changelog:
[INTERNAL] [SECURITY] - Cap readable-stream at 4.4.1
Test Plan:
If CIs pass, we should be good.

Could we force a resolution of string_decoder instead to something newer? Or does that cause other issues?

Could we force a resolution of string_decoder instead to something newer? Or does that cause other issues?

string_decoder is already at the latest version, so this wouldn't do anything.


Add ops warpper

This PR adds mmdet.ops back for back compatibility. In mmdet.ops, wrappers of mmcv.ops are added thus the projects dependent on mmdet do not need to change the origin codes.

for the latest mmcv 1.1.5 and mmdet v2.4.0. the mmdet.ops will import from mmcv.ops import (ContextBlock, Conv2d, ConvTranspose2d, ConvWS2d, and mmcv.ops has no ContextBlock. It still gives import error. How to solve this? Do I need manually change mmdet v2.4.0 mmdet.ops init.py file?


Set DoubleSide on the arrow heads

Before:

After:

Prevents the gap, but I'm not convinced it's the best solution (maybe the line should extend into the arrow instead?)

published 3.0.2


Fix/autoscaling

Description
The pull request is to fix the auto-scaling configuration using object variable rather than individual variables.
Two variables had wrong typing so they were being put in config.toml even if set to -1 which should have resulted in those to return empty strings but they were filled with the values has -1 each.
${runners_off_peak_idle_count}
${runners_off_peak_idle_time}

The 3 spaces for the object-based auto-scaling config was shifted from "template/runner-config.tpl" to "template/runners_machine_autoscaling.tpl" since that particular space placement made it so only the first set of
"[[runners.machine.autoscaling]]" were preceded by 3 spaces
Finally, line 3 of "template/runners_machine_autoscaling.tpl" was missing surrounding double-quotes that would also yield invalid configuration.
Migrations required
NO (Shouldn't be at least seeing as setting up auto-scaling using the object variable is currently not working)
Verification
None of the examples currently use the object configuration method rather than the method marked as deprecated.
The parameter used to test was :
runners_machine_autoscaling = [
    {
      timezone   = var.timezone
      idle_count = 0
      idle_time  = 60
      periods = ["* * 0-7,18-23 * * mon-fri *"]
    },
    {
      timezone   = var.timezone
      idle_count = 0
      idle_time  = 60
      periods = ["* * * * * sat,sun *"]
    }
  ]

Documentation
pre-commit script were run and passed

@skeith45 thanks for your contribution. I put it on my backlog to check the PR in the next days.

I'll recheck for the toml. A bit odd that its not working cause I use the same changes that are in this PR in a repo that is used to deploy runners that are currently in-use. Curious if there could be differences due to terraform version? I'm currently using the latest 0.12 version of terraform.
Regarding the conflict, I followed the contributing doc and used master as the starting point but I see that the other pull request got merged into develop and master has yet to change. Is it safe to assume I should using develop as a base? If so it might be pertinent to update the contributing documentation.
Regarding the tf docs version. I'm using tf docs version 0.11.0 (Windows version to be precise, don't know if it makes any difference). Installed it via chocolatey; I see that there is a version 0.11.2 available however.

I'll recheck for the toml. A bit odd that its not working cause I use the same changes that are in this PR in a repo that is used to deploy runners that are currently in-use. Curious if there could be differences due to terraform version? I'm currently using the latest 0.12 version of terraform.

Did specify in your cae the following variable? runners_machine_autoscaling as is done in the default example?
  # Deprecated, replaced by runners_machine_autoscaling
  # runners_off_peak_periods    = "[\"* * 0-9,17-23 * * mon-fri *\", \"* * * * * sat,sun *\"]"
  # runners_off_peak_timezone   = var.timezone
  # runners_off_peak_idle_count = 0
  # runners_off_peak_idle_time  = 60
  runners_machine_autoscaling = [
    {
      periods    = ["\"* * 0-9,17-23 * * mon-fri *\"", "\"* * * * * sat,sun *\""]
      idle_count = 0
      idle_time  = 60
      timezone   = var.timezone
    }
  ]

see https://github.com/npalm/terraform-aws-gitlab-runner/blob/532eb0b3ecc20502693ad87747274d32aaa8869e/examples/runner-default/main.tf#L81

Regarding the conflict, I followed the contributing doc and used master as the starting point but I see that the other pull request got merged into develop and master has yet to change. Is it safe to assume I should using develop as a base? If so it might be pertinent to update the contributing documentation.

Sorry for the confusion, and I wil upate the contribution guide. Please use the default branch develop.

Regarding the tf docs version. I'm using tf docs version 0.11.0 (Windows version to be precise, don't know if it makes any difference). Installed it via chocolatey; I see that there is a version 0.11.2 available however.

My mistake, it seems my link to the terraform-dcos installation wasn't correct. Generation of the resources was added to version 11. So that is all good.

I put in the content of the variable inside the PR main post (changed the value to 9 to 5 in the comment here however) :
runners_machine_autoscaling = [
{
timezone   = var.timezone
idle_count = 0
idle_time  = 60
periods = ["* *0-9,17-23 * * mon-fri "]
},
{
timezone   = var.timezone
idle_count = 0
idle_time  = 60
periods = [" * * * * sat,sun *"]
}
]
This makes the template file generate two [[runners.machine.autoscaling]] blocks which is how its done in the gitlab runner documentation :
I guess I should probably remove the join call in the template cause that doesn't work with this method of configuring autoscaling as far as I'm aware.

My bad, the period is an array of strings, so I guess it should work if you put multiple periods in it.
But the current code didn't surround the periods with double quotes.
And didn't allow for multiple period block.
I'll try to make sure the multiple period string within same object still work at least. Maybe I broke that.

I think you aprroach is actually better. This avoid the user has to avoid escaping the double quotes. I just checked the defaullt example and set thre periods to:
periods    = ["* * 0-9,17-23 * * mon-fri *", "* * * * * sat,sun *"]

This is working, drawback is that is breaking backwards compatiblity. But we could add a clear direction for migration. Do you see any good option to remain backwards compatible.

I added backward compatibility. It makes the period handling of the template a bit harder to read but it makes it compatible with both methods of writing the autoscaling object.
I didn't test it in an actual runner but I did test the output of the template using the variable below which tests both old and new version of the period. The output is the same for both old and new.
runners_machine_autoscaling = [
  {
    periods    = ["\"* * 0-9,17-23 * * mon-fri *\"", "\"* * * * * sat,sun *\""]
    idle_count = 0
    idle_time  = 60
    timezone   = "Europe/Amsterdam"
  },
  {
    periods    = ["\"* * * * * sat,sun *\""]
    idle_count = 0
    idle_time  = 60
    timezone   = "Europe/Amsterdam"
  },
  {
    periods    = ["* * 0-9,17-23 * * mon-fri *","* * * * * sat,sun *"]
    idle_count = 0
    idle_time  = 60
    timezone   = "Europe/Amsterdam"
  },
  {
    periods    = ["* * * * * sat,sun *"]
    idle_count = 0
    idle_time  = 60
    timezone   = "Europe/Amsterdam"
  }
]


about random kernel generator

In the following code, lamda_1&2 (referred as kernel width) are used to calculate the COV matrix.  But shouldn't the square of lambda be used here for covariance?
https://github.com/JingyunLiang/FKP/blob/5ca3f7c39ba849408993cec64341e2639063984f/data/prepare_dataset.py#L50

Here, lambda_1 and lambda_2 denote $\sigma_1^2$ and $\sigma_2^2$ in the covariance matrix, respectively. Therefore, it has already been squared. Note that isotropic Gaussian generation functions often take $\sigma$ (the standard deviation, not squared) as input.
We did this to be consistent with mvnpdf(anisotropic Gaussian) and fspecial(isotropic Gaussian) in Matlab.


fix(boom): upgraded toolset to current charts and tool releases

👏

@buehler we heard you 😁 next week we will merge this

@stebenz we should incorporate this https://grafana.com/blog/2020/10/15/were-making-prometheus-use-less-memory-and-restart-faster

@stebenz we should incorporate this https://grafana.com/blog/2020/10/15/were-making-prometheus-use-less-memory-and-restart-faster

it's already incorporated, with the toolupgrade prometheus is on version 2.20.1

@caos/orbos since this is working, we should merge this ASAP
Any objections?


Add functionality to format resulting data into CSV data format in combination with README markdown format, rather than simple ascii (34)

[X] Extract residuals to csv implemented in (#84)

This is DONE.


Fix DelegateInterface::process()

Fixes:

missing change of the argument signature due to #27
fixes misleading phpdoc, as delegates are not necessarily middlewares

I'm sorry, when is the delegate not delegating to middleware?
When there is no more middleware on the stack? That shouldn't happen if your stack is arranged properly - if that's not the case, that's a bug.
Even if it's some other component that, say, delegates to a controller, the component that delegates to the controller is still middleware in this context.
I thought this description was perfect as it was. The proposed description is unclear on the intended use or expected result - it's too abstract, even if there are edge-cases where the component you delegate to is ultimately something other than middleware, it's role in relation to middleware is still as middleware.

Even if it's some other component that, say, delegates to a controller, the component that delegates to the controller is still middleware in this context.

Yes, this is the reason. And I disagree, especially in this context: Middlewares are called Middlewares, because they are in the middle of something.
If I understood you correctly, according to your view, at least one of the following must hold:

delegates are middlewares, hence ServerMiddlewareInterface extends DelegateInterface
or, middlewares are delegates, hence DelegateInterface extends ServerMiddlewareInterface
or, they are identical, hence we don't need the DelegateInterface at all and the ServerMiddlewareInterface would look similar to this:

interface ServerMiddlewareInterface
{
    public function process(
        ServerRequestInterface $request,
        ServerMiddlewareInterface $next = null // <-- !!!
    );
}

I strongly disagree with 1. and 2., because of LSP. And, personally(!), I think 3. violates SRP, which is debatable.

Even if it's some other component that, say, delegates to a controller, the component that delegates to the controller is still middleware in this context.

Furthermore, a controller is a valid delegate.

Btw, the current FQIN is Interop\Http\Middleware\DelegateInterface – and does not contain *Server*.
Two suggestions:

Interop\Http\Middleware\ServerDelegateInterface
Interop\Http\ServerMiddleware\DelegateInterface

IMHO, 2. would be a good choice for the whole package…

Furthermore, a controller is a valid delegate – there is no need for an additional component.

@schnittstabil that completely depends on your controller definition/concept/interface - it may or may not be a valid delegate itself; it's very likely not, as developers/frameworks tend to dream up all sorts of creative controller concepts, e.g. with parameter resolution, value-binding, result abstraction, filters, there are any number of concepts and possible definitions.
More importantly, the concept of controllers is beyond the scope of this specification, so, as mentioned, even if the delegate is delegating to something other than middleware, such as a controller, the role of that component as it pertains to this specification is still as middleware.
We're not interested in what else the component being delegated to might also be, e.g. in a different domain. It's role in the context of the middleware domain is as middleware.

Personally, I think DelegateInterface::process needs to be renamed to __invoke. After implementing https://github.com/equip/dispatch I found this to be silly:
return $delegate->process($request);

It should really just be:
return $delegate($request);

But to be clear, I do not think we should change the middleware signature to callable, it should remain as is.

IMO changing the method-name to save like 8-9 keystrokes when dispatching the delegate is silly - you still won't be able to use callable which the type-hint prevents, so you still need something like this in practically every implementation, a dumb wrapper around what is most likely internally a callable anyhow.
Frankly, we've debated the pros and cons of this to death.
An interface with an ordinary method-name is a totally idiomatic thing - and doesn't cause anyone any problems, beyond typing a few extra characters. Stuffing __invoke() in an interface is pretty unorthodox.
I'm strongly suggesting we close this can of worms again, right now, please.

controller […] may or may not be a valid delegate itself
…
It's role in the context of the middleware domain is as middleware.

@mindplay-dk Sorry, I think you contradict yourself. May you please take a stand on the following question:
Do you believe that all Delegates are Middlewares?

May you please take a stand on the following question:
Do you believe that all Delegates are Middlewares?

No, I don't.
The delegate is used to manage a stack, queue, collection, whatever, of middleware, but is not itself middleware. The idea when calling it from within middleware is to see if some other middleware can produce a response.
To reiterate: a delegate may compose middleware, and is guaranteed to return a response, but is not itself middleware; it delegates to the middleware it composes.

Do you believe that all Delegates are Middlewares?

No, they are delegates to middleware.
Even if the thing being ultimately dispatched is a controller or something else, the delegate is always a middleware delegate in the context of middleware.
Controllers are not a concept within this domain. The same object can have more than one role in different domains - that's basically what interfaces are for. In the context of the middleware domain, the delegate is to middleware.
I don't know how to make this any clearer.

Do you believe that all Delegates are Middlewares?

No, delegates are not middleware. They are the interface between the middleware container and the middleware itself:
Middleware is stored in a container, which is executed by a delegate the container creates.
https://github.com/equip/dispatch/blob/master/src/Delegate.php

I'm :-1: on this overall.
While I recognize that with the removal of MiddlewareInterface we're now only dealing with server-side middleware, one of the original ideas was to create a delegate that could, potentially, mix and match client- and server-side middleware. Client-side middleware may be expected to return a promise, but that paradigm may make sense only in asynchronous workflows; I can definitely see a potential for synchronous workflows that would continue to produce a response. As such, changing the signature of DelegateInterface at this time to only accept server-side requests potentially removes this possibility.
I definitely still see the argument against using a delegate that only typehints on RequestInterface — indeed, I made those arguments myself. However, I'm also seeing that, in practice, it's a basically moot point: a server-side middleware stack will be slinging around a server-side request, and IDEs will not get confused in most cases, as the DelegateInterface is something that will be implemented in libraries, but only consumed in applications; as such, the typehint is the only salient point, and ServerRequestInterface fulfills that already. If a type mismatch does occur (e.g., client-side middleware passing a brand new non-server-side request to the delegate, which in turn dispatches server-side middleware), PHP will raise an error, and the user will know they need to write a wrapper around that specific client-side middleware, as it's mis-behaving.
tl;dr: DelegateInterface may have use cases beyond server-side requests, and the current signature both supports that, and is not contradictory with server-side middleware runners in real-world practice.

@weierophinney what about renaming process() to __invoke()?

Thank god, we all agree that they are different.

The delegate is used to manage a stack, queue, collection, whatever, of middleware
…
the delegate is always a middleware delegate in the context of middleware.
…
They [delegates] are the interface between the middleware container and the middleware itself

@weierophinney, @mindplay-dk, @shadowhand:
I believe you all have had only your very own concrete implementation in mind. Take the following example using Equip Dispatch:
use Equip\Dispatch\Stack;

$default = function (RequestInterface $request) {
    return new Response();
};

$stack = new Stack([
    new FooMiddleware(),
    // ...
], $default);

$request = ServerRequest::fromGlobals();
$response = $stack->dispatch($request);

To me, $default is the simplest delegate I can think of. Moreover, the Middlewares are in the middle of the process – and $default is at the very end and not in the middle.
tl;tr Therefore, DelegateInterface::process should not claim to call the next middleware, that would be implementation specific.
--
Btw, @mindplay-dk You started to talk about controllers – I don't know what kind of controllers you have in mind, but to me they were only one example of many.

@weierophinney what about renaming process() to __invoke()?

Sorry I forgot to answer that one earlier, @shadowhand !
I'd personally prefer the process() (or other reasonable name) method. My rationale is based on implementing http-middleware in Stratigility and Expressive, and setting them up to work interchangeably with double-pass (now considered legacy).
Our Next implementation has always been callable, but requires both a $request and $response argument. If http-middleware were to also use __invoke(), we'd need to make $response optional, and then we have a potential problem: if we do not receive a response, but the next middleware in the stack is double-pass, we will error.
By having separate methods, we were able to adapt our Next implementation to work with either style, giving us forwards compatibility with http-middleware, but backwards compatibility with existing double-pass middleware. Of course, the goal is to eventually only support http-middleware signatures, but this gives us a migration path.
Using __invoke() makes it very tempting to typehint on callable as well, instead of the interface, which, for me, is an argument for keeping a discrete method: encouraging using the typehints. This will be particularly relevant if projects follow in the footsteps we're taking, by adapting callable middleware in a decorator. Having the typehint makes determining the signature far easier, particularly when adapting multiple middleware styles.
In terms of actual usage, I do not find that using invoke is necessarily faster/easier to type than having a dedicated method. Additionally, I find mocking easier with a dedicated method.

@schnittstabil I really don't understand your argument. I think you're arguing that a DelegateInterface instance could be middleware that does not accept a delegate, and thus that the DelegateInterface argument should be nullable.
I personally do not agree. I'd prefer a single signature. If the $delegate argument is nullable, middleware that needs to use it MUST validate the value before usage. If we make it required, the final, innermost middleware can simply ignore the argument and return a response. The value to having it non-null is type-safety for all other layers of the application.
If this is not your argument, my apologies. That said, if it's not, can you please clarify?

@schnittstabil I really don't understand your argument. I think you're arguing that a DelegateInterface instance could be middleware that does not accept a delegate, and thus that the DelegateInterface argument should be nullable.

Oh, no! My https://github.com/http-interop/http-middleware/pull/29#issuecomment-260214510, was a reply to @mindplay-dk's response – it turns out that it was a misunderstanding. I fully agree with you and came to exactly the same conclusion.
The discussion started, because @mindplay-dk wanted to know:

I'm sorry, when is the delegate not delegating to middleware?

Which refers to the following change, if I'm not wrong again:
 interface DelegateInterface
 {
    /**
-     * Dispatch the next available middleware and return the response.
+     * Process an incoming server request and return a response.
     */
    public function process(…);
 }

@weierophinney okay, I can agree with that. The problem I have with process() is two-fold:

Delegates don't process anything. Their entire purpose is to blindly pass the request to the next available middleware, or return a response if the end of the stack is reached.
As per the first point, there is only one viable public method. Hence it seems preferable to write:

return $delegate($request);

I am curious about your comment about the Next implementation... are you really pursuing a plan that uses the same delegate implementation for both double-pass and single-pass?
@schnittstabil I think the correct docblock description would be:

Delegate the request to the next available middleware, or return an empty response if none is available.

Delegate the request to the next available middleware, or return an empty response if none is available.

I don't think that's generally true. Sometimes, for very, very simple applications, we don't need a stack at all, and the delegate does not have to return an empty response:
// contact.php
$middleware = new Middlewares\ContentType();
$request = ServerRequest::fromGlobals();
$response = $middleware->process($request, new class implements DelegateInterface {
    public function process(ServerRequestInterface $request)
    {
        // send an email…

        // create the response…
        $type = $request->getHeaderLine('Accept');
        $response = new Response();

        if ($type === 'text/html') {
            $response->getBody()->write('
Thanks for your message
');
        } elseif ($type === 'application/json') {
            $response->getBody()->write(json_encode(['message' => 'Thanks for your message']));
        }

        return $response;
    }
});

Of course, at some later point we may want to use more than one middleware, or routing, or whatever. But, there are many use cases out there, which are simple and will ever be such simple, e.g. some IoT applications.

@schnittstabil I think we disagree here. What you are expressing is a middleware, not a delegate. Ideally the delegate always returns an empty response that is processed by middleware, even if there is only one. (In your case, why have middleware at all?) Mostly because the delegate should use a factory to create the response, so that swapping PSR-7 implementation is possible:
$responseFactory = $container->get('ResponseFactory'); // or whatever
$default = function (RequestInterface $request) use ($responseFactory) {
    return $responseFactory->createResponse();
};
// ... etc

What you are expressing is a middleware, not a delegate. Ideally the delegate always returns an empty response that is processed by middleware, even if there is only one.

An interesting point of view – likely the reason for all those misunderstandings.

Mostly because the delegate should use a factory to create the response, so that swapping PSR-7 implementation is possible

IMO, there is no difference between injecting a factory into Middleware or a Delegate, but maybe I don't get the point.
--
If I understand you correctly, then you suggest:
$default = function (RequestInterface $request) {
    return new Response();
};

$stack = new Equip\Dispatch\Stack([
    // middleware, which implements content negotiation:
    new Middlewares\ContentType(),
    new class implements ServerMiddlewareInterface {
        public function process(ServerRequestInterface $request, DelegateInterface $delegate)
        {
            // alternative 1: create an empty response using $delegate
            $response = $delegate->process($request);
            // alternative 2: create an empty response using a response factory
            $response = $responseFactory->createResponse();
            //…
            // generate content:
            $response->getBody()->write('
Thanks for your message
')
            //…
            return $response;
        }
    }
], $default);

$response = $stack->dispatch(ServerRequest::fromGlobals());

To be honest:

Alternative 1 is totally weird, I can't imagine any real benefit over alternative 2.
Alternative 2 is totally cumbersome:

why should the very last middleware implement ServerMiddlewareInterface? $delegate is never used by the last one.
why should I create $default? If the last middleware calls $default, then it is a bug of the application.

--
Furthermore, I've never seen that before, e.g.

Django, Single Pass, the content is generated by views, not a middlewares:

def index(request):
    return HttpResponse("Hello, world. You're at the polls index.")

Laravel, Single Pass, again, the content is generated by controllers, not a middlewares:

class UserController extends Controller
{
    /**
     * Store a new user.
     *
     * @param  Request  $request
     * @return Response
     */
    public function store(Request $request)
    {
        $name = $request->name;
        //
    }
}

Slim, Double Pass, but similar, the content is not generated by middlewares:

$app->get('/hello/{name}', function ($request, $response, $args) {
    // ! this is not a middleware ! - there is no $next
    $response->write("Hello, " . $args['name']);
    return $response;
});

and so on and so forth…

The main reason I've never seen that before might be, because most frameworks don't distinguish Middlewares and Dispatcher. However, comparing the examples above: Django views and Laravel controllers implement the DelegateInterface to some extent – in my opinion, that cannot be a coincidence!

@shadowhand —

I am curious about your comment about the Next implementation... are you really pursuing a plan that uses the same delegate implementation for both double-pass and single-pass?

Yes!
We implemented and released it already in zend-stratigility 1.3:

Next
Dispatch (used by the 1.3 version to dispatch the middleware discovered in the queue; in 2.0, this class goes away)

In there, we have the legacy __invoke(), but also the http-interop process(). There's a small amount of logic duplication between them, but they dispatch the middleware based on the middleware type. We allow the two types to intermingle by storing a "response prototype" in the Next instance, so that if a non-interop middleware is delegated to from interop middleware, we have a response to pass to it. (In 2.0, that prototype gets pushed into a decorator for the legacy middleware instead, and Next becomes far simpler.)
While we could potentially do this all in __invoke(), it makes for quite a few more paths through that method, making maintenance harder, and requires we change our signature to make the second, $response argument, optional. This is not a BC break, per se, but definitely a bit more difficult to support. Having the separate method meant we could segregate the functionality, and made the transition to the proposed 2.0 version essentially just a matter of removing the __invoke() implementation and inlining the Dispatch::process logic.

@schnittstabil oh boy... I wrote "delegate" twice when I meant "default". The correct thing to do here is:
If your middleware does not terminate early, allow the delegate to return the response. If the delegate has reached the end of the stack, it will execute the $default to get an empty response. Use the stream factory to create a body and attach it to the response. (Do not use stream writing! This is buggy!)
 // omitted type hints for clarity
public function process($request, $delegate)
{
    $response = $delegate->process($request);
    $body = $this->streamFactory->createStream('
It works!
');

    return $response->withBody($body);
}

OR If your middleware does terminate early, generate a response in the middleware and return it without delegating:
public function process($request, $delegate)
{
    if (should_terminate($request)) {
        return $this->responseFactory->createResponse(400);
    }

    return $delegate->process($request);
}

I get that, in the case with $default, you're not strictly delegating to a middleware component - but I maintain that the role of even a simple function consisting of return new Response() is still acting as middleware in it's relation to the middleware component that calls it.
What else that component may be, in addition to acting as middleware in this context, is completely outside the scope of this specification - it's implementation details and personal choices in the middleware stack.
Let's stop debating and suggest alternatives to these two lines of documentation instead?
For example:
Delegates control from the current middleware to a different component.

Or:
Pass control to a different component and return the Response generated by it.

Or suggest something?
But don't try to make it so neutral-sounding that it has no meaning to anyone trying to learn about the role of the interface and method in the context of the middleware domain.
@shadowhand

Delegates don't process anything. Their entire purpose is to blindly pass the request to the next available middleware, or return a response if the end of the stack is reached.

That describes how it's implemented - the method should describe the effect of calling that method, what it does internally leads to the processing of the request, and that's all the client code should care about.

As per the first point, there is only one viable public method. Hence it seems preferable to write: return $delegate($request);

If you tried to use __invoke() for every interface containing only one public method, you'd never be able to implement more than one interface

It's not a given that the delegate implementation has only one public method, only that it's the only public method offered via this interface

Your preference ultimately is based on a desire to save 9 keystrokes.

We've had debated this subject to death already. Why are we wasting time on this again? It's a very minor detail of no substantial consequence whatsoever, so can we please use a safe, plain, ordinary one-method interface and not run the risk of blocking or conflicting with something else by reserving a magic method? 9 keystrokes really is not enough of a reason to do that.
__invoke() has no practical advantage over a regular, named method, in this context, where you're going to type-hint against the interface itself anyhow - __invoke() does not become interchangeable with callable in this context, so there really is not real practical benefit to resorting to magic here. None.

@mindplay-dk I forgot that part of the reason we named the delegate method process was to prevent a class from implementing both Middleware and Delegate interfaces, as that would be a serious mistake in interpretation. Thanks for reminding me.
Based on the feedback I am closing this PR. The current Delegate implementation is fine and modifying the accepted request type has no distinct value nor will it interfere with async middleware.

What else that component may be, in addition to acting as middleware in this context, is completely outside the scope of this specification - it's implementation details and personal choices in the middleware stack.

@mindplay-dk I fully agree on that, and never said that the specification should mention controllers or similar. But, as you said, the same object can have more than one role in different domains.
To me DelegateInterface is not an internal-only interface of the middleware PSR. Instead, in my example above, I claim $default fulfills the DelegateInterface to some extend. But, to make it explicit, let me introduce a more concrete version:
$default = new class implements DelegateInterface {
    public function process(ServerRequestInterface $request)
    {
        return new Response();
    }
};

In this example, $default should act as the default handler for end of stack (Equip Dispatch jargon), i.e. a final handler (zend-diactoros jargon).
I claim that $default fulfills the DelegateInterface contract:

it implements the interface – that's obvious.
If I call $default->process($request) it dispatches/processes an incoming server request and return a response – that should be obvious too.

Furthermore, I claim the same for Django views and Laravel controller methods as well. In these frameworks they play the role of views or controller methods respectively. But in the context of the middleware stack, they also play the role of delegates.

@shadowhand IMO, things get really messy with your suggestion, e.g. with Stratigility. To be honest, I don't like how some things are solved with Stratigility – but ok, Stratigility is not the only one allowing the following (notably expressjs allows similar).
It is a common pattern in those applications to register multiple middlewares/handlers per route:
$app    = new MiddlewarePipe();
$server = Server::createServer($app, …);

// non admin
$app->pipe('/', function ($request, DelegateInterface $delegate) {
    if ($request->getQueryParams()['name'] == 'admin') {
        return $delegate->process($request); // [1]
    }

    $response = $delegate->process($request); // [2]
    $body = $this->streamFactory->createStream('
Hi non admin!
');
    return $response->withBody($body);
});

// admin
$app->pipe('/', function ($request, DelegateInterface $delegate) {
    $response = $delegate->process($request);
    $response = $response->withHeader('secret', 'unicorns are awesome');
    $body = $this->streamFactory->createStream('
Hi admin!
');
    return $response->withBody($body);
});

$server->listen(new NoopFinalHandler());

[1] and [2] delegate to the next middleware, which is the admin one, not the NoopFinalHandler – ugh! Hence, $delegate->process($request) is not suited to to get an empty response – only $responseFactory->createResponse() leads to maintainable code.
Furthermore, I see no problem with $responseFactory, it is framework specific and does not have to implement Psr\Http\Message\ResponseFactoryInterface, e.g.:
class MyResponseFactory
{
   function createResponse()
   {
      return new NoopFinalHandler();
   }
}

@schnittstabil none of your last post made any sense to me... maybe because it is specific to Stratigility, which has never been comprehensible to me.

In summary:
$app->pipe('/', function ($request, DelegateInterface $delegate) {
        return $delegate->process($request);
});

$app->pipe('/', function ($request, DelegateInterface $delegate) {
    $response = $delegate->process($request);
    $body = $this->streamFactory->createStream('Hello World');
    return $response->withBody($body);
});

If you visit /, it will output Hello World.

Why I think type hinting against ServerRequestInterface is the right thing
@weierophinney wrote:

a server-side middleware stack will be slinging around a server-side request, and IDEs will not get confused in most cases, as the DelegateInterface is something that will be implemented in libraries, but only consumed in applications;

Despite I don't agree about the only implemented in libraries argument, the real issue is much bigger.
As a middleware-stack implementer, I need to create a DelegateInterface instance which calls the next ServerMiddlewareInterface instance, e.g. from Equip\DispatchDelegate:
class Delegate implements DelegateInterface
{
   public function process(RequestInterface $request)
   {
       //…
       return $this->middleware[$this->index]->process($request, $this->nextDelegate());
   }
}

This means, we must call ServerMiddlewareInterface::process with a RequestInterface instance in one way or another, however a ServerRequestInterface is expected.
Currently, that works nicely: The type system of PHP is too dump and does not complain about it, but relying on that is not future proof, e.g. see PHP RFC: Property type-hints. In my opinion, it would be a shame if a standard would force implementers to trick the PHP type system someday.
--
Moreover, just to be clear, we can not do:
class Delegate implements DelegateInterface
{
  public function process(ServerRequestInterface $request) {
  }
}

That throws a PHP Fatal error, already today:
Declaration of Delegate::process(Psr\Http\Message\ServerRequestInterface $request) must be compatible with
Interop\Http\Middleware\DelegateInterface::process(Psr\Http\Message\RequestInterface $request)

You'll also get the fatal error if DelegateInterface invokes a ServerMiddlewareInterface instance with only a RequestInterface. Further, your stack trace will help you know what called the delegate, and thus which middleware is improperly creating a non-server request prior to calling the delegate.
Using the looser RequestInterface on the delegate, which should typically only pass on the given request to the middleware to which it delegates, allows us to have middleware with different signatures at a later point. Restricting to ServerRequestInterface denies that possibility.

The differences between theses approaches are about where and when errors are thrown:

A future PHP version – but also a sophisticated linter – may discover type problems in middleware packages during parsing.
In contrast to runtime errors: if the middleware calls the delegate with a wrong argument, but only in some rare cases, then the consumer will encounter the problem, not the package maintainer.

Using the looser RequestInterface on the delegate, …, allows us to have middleware with different signatures at a later point. Restricting to ServerRequestInterface denies that possibility.

That can be fixed:
// Client
interface DelegateInterface
{
    public function process(RequestInterface $request);
}

interface MiddlewareInterface
{
    public function process(RequestInterface $request, DelegateInterface $delegate);
}

// Server
interface ServerDelegateInterface
{
    public function process(ServerRequestInterface $request);
}

interface ServerMiddlewareInterface
{
    public function process(ServerRequestInterface $request, ServerDelegateInterface $delegate);
}

Hooray, type-safe client and server middlewares :tada:
abstract class Middleware
{
    public function foo(ResponseInterface $response)
    {
        // client and server code
    }
}

class ClientMiddleware extends Middleware implements MiddlewareInterface
{
    public function process(RequestInterface $request, DelegateInterface $delegate)
    {
        return $this->foo($delegate->process($request));
    }
}

class ServerMiddleware extends Middleware implements ServerMiddlewareInterface
{
    public function process(ServerRequestInterface $request, ServerDelegateInterface $delegate)
    {
        return $this->foo($delegate->process($request));
    }
}

Only the modification of $requests seems to be a small drawback. But, as you say:

You'll also get the fatal error if DelegateInterface invokes a ServerMiddlewareInterface instance with only a RequestInterface.

With the interfaces above however, this can now be checked statically.

I forgot that part of the reason we named the delegate method process was to prevent a class from implementing both Middleware and Delegate interfaces

@shadowhand perhaps add this to the meta section?


Span tag is being wiped out on setContents

I allow special text to be typed into the editor area (e.g. '@client') and on blur, I replace it with a span tag with attributes and the value associated with the "Client's Name" I am working on. I call them dynamic fields since SunEditor does not appear to support this. I set the span tag with attributes "class", "data-tag" and "title" to keep track that this is a dynamic field (in case for example the client name changes in settings, I can update throughout the document quickly).
I may not be doing this correctly, but because this is a pretty big text area being edited, I wait until blur and then call getContents to get the entire area of content and then do a global replace of the @ tags with the span html. I then call setContents to reset the new HTML.
I console.log the replaced content with the span tags and it's all there, yet once I call setContents, the value from the span tags are all in the content but the span tags are completely wiped out! Gone. No tag what-so-ever. Why?
What am I not seeing that the span tag is wiped out? If I use a "em" tag or a "p" tag, it works fine and the tags and attributes remain, but not with a "span" tag. Why? Makes no sense. Hope one of the more experienced SunEditor folks can help enlighten me.

I'm having a similar issue when trying to write a span directly in code view, I type it, then switch to normal view then to code view again, all its attrs are gone and the span became a p


[release-0.44] Fix issues in up metrics and alerts based on namespace labels

Fixes https://bugzilla.redhat.com/show_bug.cgi?id=2008166
Manual cherry-picks

#6570
#6588
#6652

Signed-off-by: Erkan Erol<EMAIL_ADDRESS>Fixes issues in up metrics and alerts based on namespace labels

/retest-required

/retest-required

/retest

@rmohr May I get approval for this PR?

/lgtm
/approve
@erkanerol in general individual backports are preferred. Just FYI.


storage freezes forceing you to not be able to open some storage items (happens with UI as well)

Description
when the bug happens you eather get stuck with the wrong menu or no menu at all makeing it unberable to play the game, one time i lost my storage implant as antag because it wouldnt open
Reproduction

get 2 storage items that have a menu pop up
open one of the menus
open the other without closeing the former menu
you should not be able to open the previus menu after this

(ive reported this after 18 hours of no sleep playing ss14 so it might be the wrong way to reproduce it)
Additional context
it seems to be related to all storage items that you can hold or wear, so i asume its apart of the code thats buggin
(the menu ui bugg i talked about is also replecatable i think by)

open any menu ui, (ive seen it the most on salavge magnet so use that)

walk away from it (if that dosnt work, i usely tried closeing it well walking away when it happend)

you should see it on your screen perminintly intill you walk towords it and close it useing the X at the top left or right

super annoying and stupid bug!! death to the bugs!!!
also your lack of sleep didn't botch the reproduction method, that is the proper way to reproduce it!!!


syntax error which breaks the loader

https://github.com/walmartlabs/stylus-relative-loader/blob/d797a98bc48aa68d6b51ad11201603d1c35dfc27/index.js#L32
Can you please remove the this ?
This way, i can't use the loader, because it crashes.

It looks like a webpack-pre-4 to webpack-post-4 thing. I'm not sure the folks in this project intend to drop webpack-pre-4, so perhaps a PR along the lines of what the upstream project this is forked form would be appropriate https://github.com/shama/stylus-loader/commit/fc81e32e684dc95832d5ef0f24703265d1e132f6

@ryan-roemer Thanks for the answer. I will do this.


74: Handle persistent store directory change with v1 release

Resolves #71
To resolve the above issue, I could have either:

Changed mountPath to be what is expected by versions of localstack >= 1.0.0
Or handle backwards compatible versions.

I've decided to implement a backwards compatible fix, however if the maintainers would prefer to only handle the >= 1.0.0 path, I will remove the conditional logic and update the mountPath to just be /var/lib/localstack
Tested locally by varying the values for --set image.tag to latest, 1.2.0 and 0.14.5 - the chart deploys successfully with all values.

Thanks for those suggestions @alexrashed. I've committed the suggestions :)

Thanks for sorting that out, @alexrashed 😄


Merge all DevOps issues into a single board or filter on a board

@will-freshworks is looking for a view of the current DevOps backlog and roadmap

@will-freshworks I have added the Perfromance and Learning curators repos to the existing moodle namespace.

@will-freshworks I don't seem to have the access to create new workspaces on Zenhub. Therefore, I have added the github repos for Learning curator and Performance projects to the exiating moodle workspace. You can filter on label Devops to list all related issues for Moodle and Learning Curator. Since I am not working on the Performance project currently, and I will have to go to the Performance workspace and add labels to the closed tickets (if possible) to be able to get the the related issues filtered out, I have just added "devops" label to the epic #122 in Perfromance project so that you can see that as well in the filtered list.
https://app.zenhub.com/workspaces/moodle-60f098ab875719001bce05fb/board?labels=devops&repos=379226611,406451820,329107952


[WFLY-10351] BMT interceptor timeout reset adjustment

https://issues.jboss.org/browse/WFLY-10351
Adding correct transaction timeout handling for propagate the reset of the timeout to the WFTC and not to Narayana. Adding tests on fact that the method setTransactionTimeout() sets the timeout value for thread being active.
@dmlloyd would you be so kind and check if this follows the rationale the issue was created with and how the WFLY-10146 was treated. Thanks.

@bstansberry @dmlloyd thanks. I added the comment // See also https://issues.jboss.org/browse/WFTC-44 as proposed.


foldMapping in zio effect doesn't look good

Currently there's a hack to wrap errors in a exception, but in any case I cannot use a MonadError because in the cases that there's a map in error for example mapError or bimap, i will need two different instances one for E and one for F, and there's no mapError method in MonadError and I don't know if it's even possible.

take a look this links about bimonad and bimonaderror
https://gist.github.com/LukaJCB/4440ad2bc351f1d8e98601f247ec4c02

But If I change the foldMap method to receive a Bimonaderror or Bimonaddefer or something like this, it will only be possible to transform it to other Bimonaderror instance, and currently is only possible to have bimonaderror instances of either, eitherT and ZIO it self, and the intention of this foldMap is to run it asynchronously in a Future, so, it's ok, I'm going to left ZIO foldMap alone, by now


Make teaching events attend guidance match events

Trello card
https://trello.com/c/TnMyQbOh/2880-fix-how-to-attend-display-in-new-teaching-events
Context
Make the 'how to attend' section match the old one in events more closely.
Currenly the new and old events pages are sharing helpers, when the new supersedes the old we should move these to a single component and simplify the logic (and the big opening if statement) further.

Looks good (from what I can test in dev) @peteryates
Do you want to raise a ticket about the additional clean up work for after the split test?

I think the best time to do the cleanup is when we drop the old (or new!) events listings, then we can organise them in one place without needing to make them shareable.


Triggered Kotsadm version update 2021.10.15-2-nightly

Automated changes by the auto-kotsadm-update GitHub action

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.


Treat comma as a valid character in decimal number strings, closes #6028

Works in the Editor and in scenes.
Test scene:  comma.zip

Updated the patch to address the issues and rebased on current master.

I'm not sure about this one, do other softwares also understand it as such?

@reduz according to #6028, Blender does such thing, but this is related to i18n, so it should be editor only.
I think this should be a setting in editor to select the decimal separator and proper support different locales, without changing how GDScript works.

Yeah I guess we should do some sort of str.replace(",",".") in the few GUI
places where numeric text is entered (SpinBox and Tree?) instead
On Sat, Sep 10, 2016 at 12:28 PM, George Marques<EMAIL_ADDRESS>wrote:

@reduz https://github.com/reduz according to #6028
https://github.com/godotengine/godot/issues/6028, Blender does such
thing, but this is related to i18n, so it should be editor only.
I think this should be a setting in editor to select the decimal separator
and proper support different locales, without changing how GDScript works.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/godotengine/godot/pull/6104#issuecomment-246117849,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AF-Z20VQ0eJnn_yh_OpEUDnMqI-24rHMks5qosyQgaJpZM4JhS4w
.

Closing as per the above, don't hesitate to make a new PR implementing the conversion in the editor input fields instead of in ustring.


Search highlight and cursor block blink have same color

The search highlight color and cursor block blink color seem to be identical.
Consequence: placing the cursor on a highlighted search result makes the cursor disappear in the selection.
There is nothing in my config that alters the colors or cursor appart from the "finale" colorscheme.
I think it would be more legible to have different colors for these scopes. If that is the intended behavior though, then it is a "me-problem", and I will edit my config to change the color of the cursor manually, for example.
Thanks!

Hi,
It makes sense. I don't see this because I've got the search highlights (hlsearch) disabled.
There are 3 colours used for the accents (including some key highlights): yellow, blue and pink. Currently the search highlight is yellow and substitute highlight is blue; I guess I could shift that and make search results highlight blue and substitute highlight pink, which would leave yellow for the cursor while also making it distinct on the highlighted search results. Would that work for you?

Ah, I see.
The change in color you suggest would be amazing.


change(state): Run AwaitUtxo read requests without shared mutable chain state

Motivation
This PR runs StateService::AwaitUtxo read requests without accessing shared mutable chain state.
As a useful side-effect, this makes all StateService read requests concurrent.
Closes #5102.
Designs
See #4937 and https://docs.google.com/drawings/d/1FXpAUlenDAjl8nkftrypdAPsj0jr-Ut9gZlSP57nuyc/edit
Solution
Don't access shared mutable chain state in StateService read requests:

Re-Implement AwaitUtxo without accessing shared mutable chain state, using StateService.pending_utxos and tokio::block_in_place()

Send the whole NonFinalizedState to the ReadStateService

Related Cleanups:

Move AwaitUtxos next to the other shared writeable state requests
Rename ReadResponse::Utxos to ReadResponse::AddressUtxos
Rename an out_point variable to outpoint for consistency
Rename transparent_utxos to address_utxos

Testing
We should run a full sync on this before we merge, and make sure it is not significantly slower than the main branch.
Review
This PR is part of regular scheduled work.
Reviewer Checklist

[ ] Code implements Specs and Designs
[ ] Tests for Expected Behaviour
[ ] Tests for Errors

Follow Up Work
Actually create a separate task to commit blocks to the state.

@mergifyio update

I'm running a full sync and a checkpoint sync here:
https://github.com/ZcashFoundation/zebra/actions/runs/3013393462

Weird, this built on my machine. I'll push my latest changes and see what's up.

I'm running a full sync and a checkpoint sync here:
https://github.com/ZcashFoundation/zebra/actions/runs/3018034862

I did a full sync and an update sync locally:

both succeeded on testnet
update sync succeeded on mainnet
full sync is still going on mainnet, it seems to be about the same speed, there are no warnings

The previous full sync was about 10% slower during full verification.
I'm running a full sync again with the latest code:
https://github.com/ZcashFoundation/zebra/actions/runs/3025949651
I have some ideas to fix that, but I think they should go in a separate PR.
We might also see a significant speedup once we implement a separate task for block commits.
So I might need to temporarily increase the full sync timeout in this PR, just to make main pass while we're doing these other changes.

The previous full sync was about 10% slower during full verification.

Actually, it seems like full syncs have been failing on main for a while now, so I pushed some PRs to fix that.

I split PR #5132 out of this PR, because it seems like we've finished work on most of the state requests, so they can merge. But we're still working on the AwaitUtxos request.

I made AwaitUtxo non-blocking, that should be enough to get us started with block commit channels.

Run gcloud compute instances create-with-container "update-to-tip-5107-merge-7ae4b28"
ERROR: (gcloud.compute.instances.create-with-container) Could not fetch resource:

The resource 'projects/zealous-zebra/global/images/zebrad-cache-5143-merge-fb82d20-v25-mainnet-tip-u-013716' is not ready

https://github.com/ZcashFoundation/zebra/actions/runs/3041636484/jobs/4899242654
This will be fixed by #5044

@mergifyio update

I'm running a full sync here, but we don't need to wait for it before we merge this PR:
https://github.com/ZcashFoundation/zebra/actions/runs/3047965824


Timestamp in MSE

This PR adds the ability to use timestamp indexes in MSE. As we know, timestamp indexes are not actual indexes but syntactic sugar. When a timestamp index is created, a set of granularities have to be defined. Then when segments are created, a new column is created for each granularity. The content of each column is equal to datetrunc(GRANULARITY, originalColumn).
Then in SSE, the broker enriches queries adding possible overrides on the query. This means that for each usage of datetrunc(GRANULARITY, originalColumn), the broker suggest to transform the call to the generated column $originalColumn$GRANULARITY. Whether that suggestion is applied or not is defined by the server.
In MSE these suggested rewrites were not populated, which means that servers never applied the rewrite.
Specifically, queries like:
select AirTime from airlineStats where DATETRUNC('day', ts) > '2014-01-02 01:00:00.0' limit 10

Can now be optimized.
While creating some tests that verify this PR I've found that cases like
SELECT sum(case when datetrunc('SECOND',ArrTime) > 1 then 2 else 0 end) FROM mytable

were not optimized. Therefore this PR modifies InstancePlanMakerImplV2 to apply the rewrite in that case as well.

cc @bziobrowski

Codecov Report
Attention: Patch coverage is 82.00000% with 9 lines in your changes missing coverage. Please review.

Project coverage is 56.15%. Comparing base (59551e4) to head (71c958e).
Report is 1491 commits behind head on master.

Files with missing lines
Patch %
Lines

...pache/pinot/common/utils/request/RequestUtils.java
82.35%
0 Missing and 3 partials :warning:

...pinot/core/plan/maker/InstancePlanMakerImplV2.java
66.66%
2 Missing and 1 partial :warning:

...che/pinot/query/planner/logical/RexExpression.java
0.00%
3 Missing :warning:

:exclamation:  There is a different number of reports uploaded between BASE (59551e4) and HEAD (71c958e). Click for more details.
HEAD has 48 uploads less than BASE

Flag
BASE (59551e4)
HEAD (71c958e)

integration
7
0

integration2
3
0

temurin
12
2

java-21
7
2

skip-bytebuffers-true
3
1

skip-bytebuffers-false
7
1

unittests
5
2

java-11
5
0

unittests2
3
0

integration1
2
0

custom-integration1
2
0

Additional details and impacted files
@@             Coverage Diff              @@
##             master   #14690      +/-   ##
============================================
- Coverage     61.75%   56.15%   -5.60%
- Complexity      207      707     +500
============================================
  Files          2436     2122     -314
  Lines        133233   112393   -20840
  Branches      20636    17875    -2761
============================================
- Hits          82274    63118   -19156
+ Misses        44911    44279     -632
+ Partials       6048     4996    -1052

Flag
Coverage Δ

custom-integration1
?

integration
?

integration1
?

integration2
?

java-11
?

java-21
56.15% <82.00%> (-5.47%)
:arrow_down:

skip-bytebuffers-false
56.13% <82.00%> (-5.62%)
:arrow_down:

skip-bytebuffers-true
56.13% <82.00%> (+28.40%)
:arrow_up:

temurin
56.15% <82.00%> (-5.60%)
:arrow_down:

unittests
56.15% <82.00%> (-5.59%)
:arrow_down:

unittests1
56.15% <82.00%> (+9.26%)
:arrow_up:

unittests2
?

Flags with carried forward coverage won't be shown. Click here to find out more.

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

I think all comments have been resolved or are waiting for further comments. Yash, feel free to take a second look


THCState *state = at::globalContext().lazyInitCUDA();

Then uncomment the following code:
//extern THCState *state;
THCState *state = at::globalContext().lazyInitCUDA();

###THCState *state = at::globalContext().lazyInitCUDA();
this lines not found!
when //extern THCState *state, i got errors。
/home/rencong/CenterNet_for_1080ti/src/lib/models/networks/DCNv2/src/cuda/dcn_v2_cuda.cu(97): error: identifier "state" is undefined
/home/rencong/CenterNet_for_1080ti/src/lib/models/networks/DCNv2/src/cuda/dcn_v2_cuda.cu(273): error: identifier "state" is undefined
2 errors detected in the compilation of "/tmp/tmpxft_00003eab_00000000-6_dcn_v2_cuda.cpp1.ii".
error: command '/usr/local/cuda/bin/nvcc' failed with exit status 1

Please try deleting the line "//extern THCState *state;".This line is unused


Added integration to test repbulk

This closes #100. Still testing locally so dont need to merge just yet.

Hello @sgosline! Thanks for updating this PR. We checked the lines you've touched for PEP 8 issues, and found:

In the file mRNAData/getAllDatasets.py:

Line 7:19: E231 missing whitespace after ','

ok, test passed. merging now.


(poc) chore: implement jws

base https://github.com/hi-ogawa/vite-plugins/pull/75

Just wondering what it takes to make own jws since existing library (the ones from auth0 or https://github.com/panva/jose) feels a bit bloated (not the api but the implementation).
Also to get familiar with crypto.subtle (aka webcrypto) api.
Maybe I'll move it to https://github.com/hi-ogawa/js-utils as usual...?

Actually further simplified version is added in https://github.com/hi-ogawa/vite-plugins/pull/75/commits/73ecfdd6ee8f707b84766c7e948b854b4f9409d1, so closing this.