help request: Not able to use custom plugin with composite architecture approach

Description
Hi team,
I am facing one issue where I am trying to use a custom plugin with apisix when deployed in composite architecture mode. I followed the approach mentioned here:
https://apisix.apache.org/blog/2023/10/18/ingress-apisix/#install-apisix-ingress-controller
https://apisix.apache.org/docs/ingress-controller/composite/
and to create a custom plugin I used the approach mentioned here:
https://apisix.apache.org/docs/ingress-controller/tutorials/using-custom-plugins/
After this when I tried to deployed the following apisix route resource, its not able to get synced. I checked the ingress controller logs and found these errors:
2024-02-24T21:53:05+08:00	error	apisix/apisix_route.go:379	failed to sync ApisixRoute to apisix	{"error": "1 error occurred:\n\t* unknown plugin [custom-oauth]\n\n"}
2024-02-24T21:53:05+08:00	warn	apisix/apisix_route.go:481	sync ApisixRoute failed, will retry	{"object": {"Type":2,"Object":{"Key":"shared/bytebase-shared-test","OldObject":{"Object":{"metadata":{"name":"bytebase-shared-test","namespace":"shared","uid":"5653149f-27cc-4b12-aedc-59d81fd01d9f","resourceVersion":"9445672","generation":1,"creationTimestamp":"2024-02-23T09:52:43Z","annotations":{"kubectl.kubernetes.io/last-applied-configuration":"{\"apiVersion\":\"apisix.apache.org/v2\",\"kind\":\"ApisixRoute\",\"metadata\":{\"annotations\":{},\"name\":\"bytebase-shared-test\",\"namespace\":\"shared\"},\"spec\":{\"http\":[{\"backends\":[{\"serviceName\":\"bytebase-shared\",\"servicePort\":80,\"weight\":10}],\"match\":{\"hosts\":[\"bytebase-test.internal.saas.syfe.com\"],\"paths\":[\"/*\"]},\"name\":\"rule1\"}]}}\n"},"managedFields":[{"manager":"apisix-ingress-controller","operation":"Update","apiVersion":"apisix.apache.org/v2","time":"2024-02-23T09:52:43Z","fieldsType":"FieldsV1","fieldsV1":{"f:status":{".":{},"f:conditions":{}}},"subresource":"status"},{"manager":"kubectl-client-side-apply","operation":"Update","apiVersion":"apisix.apache.org/v2","time":"2024-02-23T09:52:43Z","fieldsType":"FieldsV1","fieldsV1":{"f:metadata":{"f:annotations":{".":{},"f:kubectl.kubernetes.io/last-applied-configuration":{}}},"f:spec":{".":{},"f:http":{}}}}]},"spec":{"http":[{"name":"rule1","match":{"paths":["/*"],"hosts":["bytebase-test.internal.saas.syfe.com"]},"backends":[{"serviceName":"bytebase-shared","servicePort":80,"weight":10}],"websocket":false,"authentication":{"enable":false,"type":"","keyAuth":{},"jwtAuth":{},"ldapAuth":{}}}]},"status":{"conditions":[{"type":"ResourcesAvailable","status":"True","observedGeneration":1,"lastTransitionTime":null,"reason":"ResourcesSynced","message":"Sync Successfully"}]}}},"GroupVersion":"apisix.apache.org/v2"},"OldObject":null,"Tombstone":null}, "error": "1 error occurred:\n\t* unknown plugin [custom-oauth]\n\n"}

To verify whether custom plugin is actually loaded by apisix, I exec into the ingress-controller pod and ran the admin api for plugins (https://apisix.apache.org/docs/apisix/admin-api/#plugin-api). I can see that the plugin was there in the response. I also got the response for the plugins/{{plugin_id}} api for my custom plugin (custom-oauth).
So I can see that the error is only coming when ingress-controller is trying to sync the apisixRoute with apisix. Somehow it's not able to find the custom plugin. The issue is not happening when I am using any built-in plugin. I really need some help out here. I will be very grateful if you can help here. Thanks in advance.
Changes I made in the composite.yaml
apisix:
     enable_control: true
     enable_reuseport: true
     extra_lua_path: /usr/local/apisix/custom_plugins/?.lua   # change 1
...
...

plugins:
    ...
    ...
    - ext-plugin-post-resp           # priority: -4000
    - custom-oauth                   # change 2

...
...

---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: ingress-apisix-composite-deployment
  namespace: ingress-apisix
spec:
  replicas: 1
  selector:
    matchLabels:
      app.kubernetes.io/name: ingress-apisix-composite-deployment
  template:
    metadata:
      labels:
        app.kubernetes.io/name: ingress-apisix-composite-deployment
    spec:
      volumes:
        - name: apisix-config-yaml-configmap
          configMap:
            name: apisix-gw-config.yaml
            defaultMode: 420
        - name: plugin-custom-oauth-config     # change 3
          configMap:
            name: custom-oauth-config
            defaultMode: 0744
    ...
    ...

    volumeMounts:
             - name: apisix-config-yaml-configmap
               mountPath: /usr/local/apisix/conf/config.yaml
               subPath: config.yaml
             - mountPath: /usr/local/apisix/custom_plugins/apisix/plugins/custom-oauth.lua  # change 4
               name: plugin-custom-oauth-config
               subPath: custom-oauth.lua

...
...

--- # Change 5
apiVersion: v1
data:
  custom-oauth.lua: |
    -- some required functionalities are provided by apisix.core
    local core = require("apisix.core")

    -- define the schema for the Plugin
    local schema = {
        type = "object",
        properties = {
            body = {
                description = "custom response to replace the Upstream response with.",
                type = "string"
            },
        },
        required = {"body"},
    }

    local plugin_name = "custom-oauth"

    local metadata_schema = {
        name = "custom-oauth",
        priority = "30000"
    }

    -- custom Plugins usually have priority between 1 and 99
    -- higher number = higher priority
    local _M = {
        version = 0.1,
        priority = 30000,
        name = plugin_name,
        schema = schema,
        metadata_schema = metadata_schema
    }

    -- verify the specification
    function _M.check_schema(conf)
        return core.schema.check(schema, conf)
    end

    -- run the Plugin in the access phase of the OpenResty lifecycle
    function _M.access(conf, ctx)
        return 200, conf.body
    end

    return _M
kind: ConfigMap
metadata:
  creationTimestamp: null
  name: custom-oauth-config
  namespace: ingress-apisix

--- # Change 6
apiVersion: apisix.apache.org/v2
kind: ApisixRoute
metadata:
  name: bytebase-shared-test
  namespace: shared
spec:
  http:
    - name: rule1
      match:
        hosts:
          - bytebase-test.internal.saas.syfe.com
        paths:
          - /*
      backends:
        - serviceName: bytebase-shared
          servicePort: 80
          weight: 10
      plugins:
        - name: "custom-oauth"
          enable: true
          config:
              body: "Hello from your custom Plugin!"

Environment

APISIX version (run apisix version): 3.2.2
Operating system (run uname -a):     18:28:59 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux

OpenResty / Nginx version (run openresty -V or nginx -V): nginx version: openresty/<IP_ADDRESS>
 built by gcc 9.3.1 20200408 (Red Hat 9.3.1-2) (GCC)
 built with OpenSSL 1.1.1s  1 Nov 2022

etcd version, if relevant (run curl http://<IP_ADDRESS>:9090/v1/server_info):{"etcdserver":"3.5.0","etcdcluster":"3.5.0"}

(Its the version I got by hitting curl http://<IP_ADDRESS>:12379/version as its a mock etcd service)
APISIX Dashboard version, if relevant: not using
Plugin runner version, for issues related to plugin runners: not using
LuaRocks version, for installation issues (run luarocks --version): not using

@shantanu10 Thanks for reporting. I am checking this one out.

@shantanu10 So your plugin is successfully loaded by APISIX and also it's logic is being executed properly right? So functionally you're all good but you're just getting this error in the ingress controller? Am I right?

@shantanu10 Can you also provide some preceeding and trailing info/debug.. logs from this sync error in ingress controller?

@shantanu10 Hi! I was having a similar issue when working with the 'standalone' (composite deployment) of the ingress-controller.
We found out that this is due to the way the schemas (configuration validation) are loaded by the ingress-controller. Here is an approximate snapshot of the trail to follow (if interested):

Standalone Config Condition
Loading the controller (standalone)
Loading of schemas
In Memory Validation of schema (standalone)

Long story short, as a temporary fix what I did was create another mounted file for the apisix-schema.json from a configmap that contains the schemas (of all plugins). To do so, you need to:

Create a ConfigMap with all schemas

You can obtain all the schemas by calling an endpoint of the apisix container (even the schema of the custom plugins you created) from the composite deployment. To do so, you can port-forward on the deployment:
kubectl port-forward deployment/ingress-apisix-composte-deployment -n ingress-apisix 9090:9090
Then call the endpoint and save the result in a file:
curl http://localhost:9090/v1/schema > /tmp/schema.json
(for a bit of clarity on the result I would recommend | jq before saving it to the file)
Finally, apply the ConfigMap:
kubectl create configmap plugin-schema-json -n ingress-apisix --from-file=apisix-schema.json=/tmp/schema.json

Modify the composite deployment

For the sake of brevity I added # [...] to represent skipped sections.
apiVersion: apps/v1
kind: Deployment
metadata:
  name: ingress-apisix-composite-deployment
  namespace: ingress-apisix
spec:
  replicas: 1
  selector:
    matchLabels:
      app.kubernetes.io/name: ingress-apisix-composite-deployment
  template:
    metadata:
      labels:
        app.kubernetes.io/name: ingress-apisix-composite-deployment
    spec:
      volumes:
        - name: apisix-config-yaml-configmap
          configMap:
            name: apisix-gw-config.yaml
       - name: plugin-schema-json
         configMap:
           name: plugin-schema-json
      containers:
        - livenessProbe:
            tcpSocket:
              port: 8080
            # [...]
          # [...]
          name: ingress-apisix
          image: apache/apisix-ingress-controller:1.7.0
          volumeMounts:
            - mountPath: /ingress-apisix/conf/apisix-schema.json
              name: plugin-schema-json
              subPath: apisix-schema.json
# [...]

Hope it helps! Looking forward to having a better solution coming from contributors 😸. I would propose using the ApiSix api in the standalone mode and not a static file to load all the schemas, the solution I provided which creates a ConfigMap containing the result of the call to ApiSix is a placeholder as in composite deployment the apisix-ingress-controller could call the api on localhost:9090 without any issue. (can be reproduced by shell into the ingress-controller container and running the following apk add curl && curl http://localhost:9090/v1/schema)

Thanks @lucmichea . This approach worked out!
@Revolyssup We can close this issue. Thanks a lot.

Glad I could help!
@Revolyssup if you could provide some feedback on the solution I provided long term, I would love to discuss further! I can open another thread / a draft MR to cover this.

Hi @holdeneoneal
Yes, the schema.json file that you will obtain will be really large and so it is more difficult to apply it to the cluster.
From my experience, in general, the limiting factor to apply the configmap is the annotations containing the versioning of what you want to apply (kubectl.kubernetes.io/last-applied-configuration). This happens when you use kubectl apply -f <myfile>.yaml. That is why I decided in my previous answer to use kubectl create configmap ... as an alternative.
I usually use Helm for versioning and creating a chart containing the schema.json in a ConfigMap is doable.
If you are experiencing other issues concerning the size of the file I would be happy to take a look as I would be learning another limitation. Although, it would be quite out of subject for this thread.
On another note, I plan on trying to do a PR containing the full integration of custom-plugins in the standalone mode once I have a bit of time. As I didn't receive any feedback here.

I'm facing the same issue. I will try workaround mentioned above, but it would be awesome if this can be fixed. Most interesting part is that plugin works perfectly fine in standalone mode...

i have the same problem,use helm chat install with this command :
helm upgrade apisix .   --set service.type=NodePort   --set ingress-controller.enabled=true   --create-namespace   --namespace ingress-apisix   --set ingress-controller.config.apisix.serviceNamespace=ingress-apisix   --set ingress-controller.config.apisix.adminAPIVersion=v3   --set ingress-controller.config.kubernetes.enableGatewayAPI=true   --set dashboard.enabled=true   --set ingress-controller.config.etcdserver.enabled=true
but when i unuse  --set ingress-controller.config.etcdserver.enabled=true ,it is ok .
helm upgrade apisix .   --set service.type=NodePort   --set ingress-controller.enabled=true   --create-namespace   --namespace ingress-apisix   --set ingress-controller.config.apisix.serviceNamespace=ingress-apisix   --set ingress-controller.config.apisix.adminAPIVersion=v3   --set ingress-controller.config.kubernetes.enableGatewayAPI=true   --set dashboard.enabled=true
config example is https://apisix.apache.org/docs/ingress-controller/tutorials/using-custom-plugins/.
when i use admin api add custom-plugins ,is ok
`
loony@FC006001PC01:~$ curl -i http://<IP_ADDRESS>:9180/apisix/admin/routes/1  -H "X-API-KEY: edd1c9f034335f136f87ad84b625c8f1" -X PUT -d '

{
"uri": "/",
"plugins": {
"custom-response": {
"body": "Hello from your custom Plugin!"
}
},
"upstream": {
"type": "roundrobin",
"nodes": {
"httpbin": 1
}
}
}'
HTTP/1.1 201 Created
Date: Mon, 09 Sep 2024 06:52:44 GMT
Content-Type: application/json
Transfer-Encoding: chunked
Connection: keep-alive
Server: APISIX/3.9.0
Access-Control-Allow-Origin: *
Access-Control-Allow-Credentials: true
Access-Control-Expose-Headers: *
Access-Control-Max-Age: 3600
X-API-VERSION: v3

{"value":{"plugins":{"custom-response":{"body":"Hello from your custom Plugin!"}},"uri":"/","id":"1","status":1,"upstream":{"type":"roundrobin","pass_host":"pass","nodes":{"httpbin":1},"scheme":"http","hash_on":"vars"},"priority":0,"update_time":1725864764,"create_time":1725864764},"key":"/apisix/routes/1"}
loony@FC006001PC01:~$ curl <IP_ADDRESS>
Hello from your custom Plugin!l
 but ingress error
2024-09-09T15:11:03+08:00	error	apisix/apisix_route.go:380	failed to sync ApisixRoute to apisix	{"error": "1 error occurred:\n\t* unknown plugin [custom-response]\n\n"}
2024-09-09T15:11:03+08:00	warn	apisix/apisix_route.go:482	sync ApisixRoute failed, will retry	{"object": {"Type":1,"Object":{"Key":"default/api-route","OldObject":null,"GroupVersion":"apisix.apache.org/v2"},"OldObject":null,"Tombstone":null}, "error": "1 error occurred:\n\t* unknown plugin [custom-response]\n\n"}
`

I have added logic to initialize without loading the schema from the file conf/apisix-schema.json, similar to the normal mode. Instead, the schema structure is fetched from the APISIX admin interface during initialization. This way, the custom plugin schemas can be retrieved directly, allowing the use of custom plugins without the need to manually maintain the structure in conf/apisix-schema.json.


[release-1.9] operator only prunes the resources from enabled components.

This is an automated cherry-pick of #30949

cc @morvencao can we get your consent for this PR?

@googlebot I consent.


Feat/worksheet generator

Description
Introduces implementations of the worksheet generator & syllabus generator tools.
Ticket: N/A
Type of change

[x] New feature (non-breaking change which adds functionality)

Tests
Syllabus Generator - https://jam.dev/c/9ae42285-5a62-4551-9c58-200c0419a394
Worksheet Generator - https://jam.dev/c/e89a133a-cc34-4830-9200-ad14dff98d15

@yunusj Test videos have been added to the PR Description.


DB Direct Certificates Management

Concepts
This implements an API and rake interface to manage user certificates for DB Direct (a.k.a. CARTO pg-proxy connections).
Conections to DB Direct are identified by a CARTO username and an API Key is used for authorization, but a SSL certificate is also required to authenticate the user.
Each certificate issued has a unique-per-user name. The name will be defined by the user through a UI; Provisionally automatic names can be generated with the user name and a suffix.
Each certificate has a unique id (UUID) assigned by CARTO. This is different from the AWS ARN which is used to identify the certificate in AWS Private CA services.
Certificates can be optionally associated to a set of authorized IPs, so that access is limited to those IPs. Initially we'll handle this manually.
We keep the following metadata about each created certificate:

id: internally assigned UUID
user_id: user identified by the certificate (owner)
name: name assigned by user to this certificate
arn: identification of the certificate in the Private CA
expiration: date of expiration
ips: authorized user IPs

When a certificate is revoked its metadata is deleted and its arn is appended to a CRL.
Its name can be reused for a new certificate of the same user.
API
All endpoints correspond to certificates of a particular user which is  identified by authentication (either through API key or session login). When using api keys the master key is needed (we'd need to introduce some certificate-management grant to allow non-master keys).
List user certificates
Note that revoked certificates are not listed here;
Endpoint: GET /api/v4/dbdirect/certificates
200 Response (JSON)
[
  {
    "id":"xxx",
    "name":"xxx",
    "expiration":"YYYY-MM-DD"
  }
]

Get certificate metadata
Endpoint: GET /api/v4/dbdirect/certificates/:id
200 Response (JSON)
[
  {
    "id":"xxx",
    "name":"xxx",
    "expiration":"YYYY-MM-DD",
    "ips":"...",
  }
]

The arn is omitted here, as the only use of it we make is for revocation, handled internally by the model class.
The ips is included so we have an easy way to query a certificate's IPs for manually configuring firewalls.

Create a new certificate for a user:
Endpoint: POST api/v4/dbdirect/certificates
Payload: (JSON)
{
  "name":"friendly name for the certificate",
  "pass":"optional passphrase to encrypt private key",
  "ips":"optional list of ips allowed to use the key",
  "validity":365
}

200 Response: (JSON)
{
  "id":"internal id",
  "client_key": "...private key for the client",
  "client_crt": "...certificate for the client",
  "server_ca": "...ca chain to validate server"
}

Name must be unique for the user.
If password is blank the private key is not encrypted.
Validity is the number of days before certificate expiration; it cannot exceed the maximum of 365 days.
The list of authorized ips is stored as a comma-separated list, with optional slash notation for masks, e.g. <IP_ADDRESS>,<IP_ADDRESS>/24 would allow IPv4 addresses <IP_ADDRESS> and the range 224.117.12.*.

Revoke certificate
To revoke a certificate it is identified by the internal id:
Endpoint: DELETE api/v4/dbdirect/certificates/:id
This can be used also to remove expired certificates and reuse its name.
Tasks

[x] DB Migration
[x] Certificate Manager Logic
[ ] Certificate Manager unit tests
[x] Certificate Model
[ ] Certificate Model unit tests
[x] rake interface
[ ] controller/routes
[ ] controller/routes tests
[ ] end-to-end tests

Rake interface:
Generate Certificate
rake carto:dbdirect:generate_certificate[USERNAME,CERTNAME,PASSWORD,IPS,VALIDITY]

name, password, ips  and validity are optional; for example omit password and ips like this:
rake carto:dbdirect:generate_certificate[jgoizueta,qgiscarto,,,365]

Revoke Certificate
rake carto:dbdirect:revoke_certificate[ID]

The internal id must be used to revoke a certificate.

API changes
1. IP handling
The ips should be stored independently of the certificates. So we'll take them out of the dbdirect_certificates metadata table and out of the API endpoints defined above.
In principle we expect ips to be defined per organization, but I propose to store them linked to users: dbdirect_ips(id, user_id, ips) and link them to the organization's owner. That way we can accommodate ips for individual (non-org) users if needed. The API could provide access to the IPs given either the organization or a user account (for organizations it would return the ips linked to the owner; for users would look first at the user, then at their organization's administator).
Tentative API: these endpoints would be added to manage the IPs

GET /api/vN/dbdirect/ips/ get IPs for the authenticated user (if the user has no directly linked ips, then those of the owner of their organization are returned).
POST /api/vN/dbdirect/ips/ define the ips for the user's organization
DELETE /api/vN/dbdirect/ips delete ips information for the user's organization

2. authentication
Initially this was added under the  'v4' namespace following the convention of api key-only authentication por public APIs, but since is foremost and API to be used by the UI (should it be public if we provide the UI from the start?) it should allow for session login authentication for convenience. I guess this means also moving it from 'v4' (to 'v1'?) to follow the contention.

UPDATE: this is the final form of the API & rake tasks with IPs decoupled from certificates.
Concepts
This implements a private API and rake interface to manage user certificates and ips for DB Direct (a.k.a. CARTO pg-proxy connections).
Conections to DB Direct are identified by a CARTO username and an API Key is used for authorization, but a SSL certificate is also required to authenticate the user.
Each certificate issued has a unique-per-user name. The name will be defined by the user through a UI; Provisionally automatic names can be generated with the user name and a suffix.
Each certificate has a unique id (UUID) assigned by CARTO. This is different from the AWS ARN which is used to identify the certificate in AWS Private CA services.
Users can also define authorized IPs from which connection will be allowed. IPs can be specified per organization,
though internally we associate them to the organization owner. Initially we'll handle IP filtering manually.
We keep the following metadata about each created certificate:

id: internally assigned UUID
user_id: user identified by the certificate (owner)
name: name assigned by user to this certificate
arn: identification of the certificate in the Private CA
expiration: date of expiration

When a certificate is revoked its metadata is deleted and its arn is appended to a CRL.
Its name can be reused for a new certificate of the same user.
API
All endpoints correspond to certificates of a particular user which is identified by authentication (either through API key or session login). When using api keys the master key is needed (we'd need to introduce some certificate-management grant to allow non-master keys).
List user certificates
Note that revoked certificates are not listed here;
Endpoint: GET /api/v1/dbdirect/certificates
200 Response (JSON)
[
  {
    "id":"xxx",
    "name":"xxx",
    "expiration":"YYYY-MM-DD"
  }
]

Get certificate metadata
Endpoint: GET /api/v1/dbdirect/certificates/:id
200 Response (JSON)
[
  {
    "id":"xxx",
    "name":"xxx",
    "expiration":"YYYY-MM-DD"
  }
]

The arn is omitted here, as the only use of it we make is for revocation, handled internally by the model class.

Create a new certificate for a user:
Endpoint: POST api/v1/dbdirect/certificates
Payload: (JSON)
{
  "name":"friendly name for the certificate",
  "pass":"optional passphrase to encrypt private key",
  "validity":365,
  "server_ca":true
}

200 Response: (JSON)
{
  "id":"internal id",
  "name":"name of the certificate",
  "client_key": "...private key for the client",
  "client_crt": "...certificate for the client",
  "server_ca": "...ca chain to validate server"
}

Name must be unique for the user. If it is not provided we use the user account name. If it is not unique a numeric suffix is appended automatically. (so the actual name may differ from the user request and that's why the response includes the name).
If password is blank the private key is not encrypted.
Validity is the number of days before certificate expiration; it cannot exceed the maximum of 365 days, which is the default.
server_ca is a boolean flag to indicate if the server_ca should also be included in the response.

Revoke certificate
To revoke a certificate it is identified by the internal id:
Endpoint: DELETE api/v1/dbdirect/certificates/:id
This can be used also to remove expired certificates and reuse their names.
Get IPs
Gets the allowed IPS for the user's organization.
Endpoint: GET api/v1/dbdirect/ips
200 result:
{
  "ips":"..."
}

The list of authorized ips is stored as a comma-separated list, with optional slash notation for masks, e.g. <IP_ADDRESS>,<IP_ADDRESS>/24 would allow IPv4 addresses <IP_ADDRESS> and the range 224.117.12.*.

Set IPS
Defines the allowed IPS for the user's organization.
Endpoint: POST api/v1/dbdirect/ips
Payload: (JSON)
{
  "ips":"..."
}

Response (201):
{
  "ips":"...new ips"
}

Deletes IPS
Removes the allowed IPS for the user's organization.
Endpoint: DELETES api/v1/dbdirect/ips
Response (201):
{
  "ips":"...deleted ips"
}

Nete: this is equivalent to POST with the payload {"ips":null}
Rake interface:
Generate Certificate
rake carto:dbdirect:generate_certificate[USERNAME,CERTNAME,PASSWORD,IPS,VALIDITY]

name, password, ips  and validity are optional; for example omit password and ips like this:
rake carto:dbdirect:generate_certificate[jgoizueta,qgiscarto,,,365]

Revoke Certificate
rake carto:dbdirect:revoke_certificate[ID]

The internal id must be used to revoke a certificate.
List Organization IPS:
$ bundle exec rake carto:dbdirect:get_organization_ips[orgname]

Set Organization IPS:
$ bundle exec rake carto:dbdirect:set_organization_ips[orgname,<IP_ADDRESS>]

Example
Note that the certificate name has been changed from mycert to mycert_1 because the user already had an active certificate named mycert.
$ bundle exec rake carto:dbdirect:generate_certificate[cdb,mycert,xyz,,300]

Certificate mycert_1 generated for cdb
  id: c0f51417-b886-41ac-a4ab-7970a672ef1f
  arn: arn:aws:acm-pca:us-east-1:585752111050:certificate-authority/4e2d5569-cfa3-42d4-8305-96f187fda9fa/certificate/2e6b206046c195939357ee6f7c415af5
client_key written to ./cdb_mycert_1.key
client_crt written to ./cdb_mycert_1.crt
server_ca written to ./server_ca.crt

$ bundle exec rake carto:dbdirect:revoke_certificate[c0f51417-b886-41ac-a4ab-7970a672ef1f]

About to revoke certificate mycert_1 for user cdb. Are you sure? (y/n)
y
Revoking certificate mycert_1 for user cdb
  ARN: arn:aws:acm-pca:us-east-1:585752111050:certificate-authority/4e2d5569-cfa3-42d4-8305-96f187fda9fa/certificate/2e6b206046c195939357ee6f7c415af5
  Expiration was 2021-01-17 00:00:00 UTC
  IPs was
DESTROYED!!

I'm working on some modifications to the API (sorry @gonzaloriestra I'll keep them in a separate PR to avoid confusing you)

Return [] rather than nil for missing IP configuration
Optionally return the cert/key in a zipped filed including README instructions
Adding tests for handling IPs per organization

And there's a clarification that should be noted:

IP configuration for organizations will be shared by all members (stored for the owner only).
Certificates can be used for individual org. members as long as they have the feature flag. (we cannot share certificates for all members because they bear the username which is checked by pgproxy)


mspush example segfaults

Transferring from #12

Unrelated but, when I run make runall I get a segfault on the mspop test.

This doesn't occur using make mspop.run.
Any idea what could be causing this?

I have been doing some research and the culprit seems to be mspush.
Doing further investigation and looking for a fix rn!

https://github.com/Khhs167/memstack/blob/master/src/memstack.c#L39-L43

Issue resolved in https://github.com/Khhs167/memstack/commit/25d95506c8bb0b9db490185555be0c8da51d9352

You've named the test mspop not mspush and it still segfaults because of the null pointer mentioned above.

Maybe a check should be added to see if storage->last is NULL and if so just set new_node to storage->last?

I did just that over here
https://github.com/Khhs167/memstack/blob/e6e0adf34a4ac0e606a04a8a9e3da81aea4ec13b/src/memstack.c#L177

Even after pull it still segfaults on my machine. Perhaps it's because new_node->previous = storage->last? This means after an mspush storage->last->previous will be NULL?

I'll take a better look in a sec I'm currently debugging from the loo lmao

        // TODO: Check if this needs to be done elsewhere
        if(storage->first != NULL) {
        	storage->last->next = new_node;
                new_node->previous = storage->last; // <-- Added this line
        	storage->last = new_node;

        } else {
        	storage->first = new_node;
        	storage->last = storage->first;
        }

This seemed to fix it for me @Khhs167!

Do test it on your own machines to be sure :P

Works for me.
We really should get these examples converted into tests lol

Yeah haha


Final Review for chapter 4

Adding the changes that came from the final review during Chapter 4 meeting. During the call and the next two weeks, the changes were included using this docfor chapter intro and this doc for activity table
Contributors in this PR:

Alice Sowerby
Cornelius Schumacher
Gergely Csatari
Ana Jiménez
Ulises Gascon

These people are already acknowledged in the OSPO Book contributors section.
Thank you!

@anajsana @CsatariGergely do you need anything from me / can I help in any way?

Hi @anajsana @todogroup/book-reviewers , sorry for the delay in getting to review this. I have changed my notification settings so that hopefully I get notified when I am tagged :(
I think this chapter needs a full copy edit and I can't get a the GH interface to let me do that in this PR. That could be my lack of experience.
How would I go about getting the file from the branch to edit it?

Hi @anajsana @todogroup/book-reviewers , sorry for the delay in getting to review this. I have changed my notification settings so that hopefully I get notified when I am tagged :(
I think this chapter needs a full copy edit and I can't get a the GH interface to let me do that in this PR. That could be my lack of experience.
I will get a copy of the file from the branch to edit it and send back.

@anajsana I have edited a copy of the file locally, do you want me to create a PR?

Hi @anajsana @todogroup/book-reviewers , sorry for the delay in getting to review this. I have changed my notification settings so that hopefully I get notified when I am tagged :(

I think this chapter needs a full copy edit and I can't get a the GH interface to let me do that in this PR. That could be my lack of experience.

I will get a copy of the file from the branch to edit it and send back.

@anajsana I have edited a copy of the file locally, do you want me to create a PR?

Thank you @alice-sowerby ! If you could add the copy edit changes to this PR instead of creating a new one, it will be awesome. Just let me know if you need help!

@anajsana I will see if I can figure out how to do it, and let you know if I hit any problems - thank you!

@alice-sowerby created a new PR with these changes + copy edits. See: https://github.com/todogroup/ospology/pull/503
Tag this as duplicated and Closing with no merge.


[Tweak] Default to Traitor instead of Extended when possible

About the PR

This sets the fallback mode to be dependent on player count, while still allowing them be to overridden by an admin.
Media

[x] I have added screenshots/videos to this PR showcasing its changes ingame, or this PR does not require an ingame showcase

Changelog

:cl:

tweak: The game will now fall back to Traitor if there are more than 5 people in the game.

imo ideal solution is to keep rerolling until there are no more gamemodes left
so if not enough for zombie, try nukie then try traitor then try extended

Considering that this change is primarily for Sala, I don't think it would be best to have super dangerous events all the time. Lowpop zombies and nukies are notorious for being super unfair anyways.

It has been changed to use an array instead.

This should be ready for review and merge.

Okay apparently cvars dont support collections so this wouldnt work sadly

Ah, what would be the optimal solution then?

Still probably not the best solution, but it should be easy to switch over if arrays get supported.

This PR is ready for review.

It should be ready for a merge now.

Well woops

Are there any more issues with this PR?


Use isinstance check to detect strings

Using isinstance(filter, string_types) will detect strings much more reliably than not hasattr(filter, 'run').

Removed the comments as suggested

Merged in d97d1f4b8e22dd46cf7262f20a798979fc4dc719 thanks!


How to build & run this?

???

I don't provide any specific project files so this project can be compiled with any IDE. Therefore you have to create your own project and import all the files into your IDE of choice. Also I am using a few libraries, which are located in the external, so you have to also add them in your project settings.
I use Eclipse, so here is how you can set it up with Eclipse:

Create a new Project:
New -> Project -> Java Project -> (call the project whatever you want) -> Finish.
Import the repository:
Import -> File System -> Browse -> (select the downloaded repository folder) -> Select All -> Browse Folder -> (select the previously created project) -> Finish.
Set up the external libraries:
Properties -> Java Build Path -> Add External Jars -> (select all files inside external) -> Apply

This should be all :D


Loosing Appdata when activating Jailbreak

Issue: When activating the yalu Jailbreak via the yalu102b7 app on an iPhoneSE (10.2), it may be possible for Apps (eg Health & Whatsapp, probably every other app too) to loose some of the newest app data. For example the Health app looses the latest (manually added) data about my weight; WhatsApp can loose new messages. I think it is an issue with yalu102 itself and NOT with any tweak.
Description:
There are many ways this issue occurred to me. That's the reason why I want to post it here.

WhatsApp: I write a message, then reboot my via reboot command in terminal -> This new message is gone in both non-jailbroken and jailbroken mode. This also occurs when writing a message and then hard-rebooting the phone.

WhatsApp: Booting the phone (it got an message while it was shut down). It displays the notification from iOS. Without opening Whatsapp, I go to yalu and activate the jailbreak. In jb-mode, the notification is still there, but if I open Whatsapp, the message is not displayed (neither will it show up later on). If I open Whatsapp first in nonjb-mode, the message will be recived, then when I go to yalu, it stays visible.

Health: I add an entry in non-jailbroken mode, then go to yalu and activate the jailbreak. The data may be gone in both non-jb and jb-mode. Sometimes, after activating the jailbreak, the Health app does not display ANY data (just Substrate installed in this case). Respringing fixes this.

All these issues do not occur every time, but just sometimes. This is the reason why it's hard for me to find out the actual reason for this behavior. My guess is that it has something to do how yalu mounts and unmounts the user-data partition (could be wrong tho).
I hope someone is able to reproduce my issue, which is why I tried to discribe it as accurate as possible. Sadly I was not able to find any crashlogs using CrashReporter.
I read the issue posting guidelines & I hope I did not made any mistake. Thank you :)

This seems to be because these apps do not save data as they go but only when exiting them, I believe. I suggest to not do anything in non-jailbroken mode except run Yalu. If you really wanna use non-jb mode, before jailbreaking do a clean reboot.

Alright, I will try this. If I get this issue another time while
following your advice, I'll report back!
Thank you! :)

Issue never repeated for me since the last report. Just instantly jailbreak when the device booted and you are good to go, like kpwn suggested. Thanks again for you work.


Advice on how to dynamically switch theme between dark and light?

So that when user selects an app preference for dark, all scenes render with dark theme, without user having to re-start app?
Is making theme a state the way this should be done?
My goal is to implement a demo using Google Material light and dark themes.
https://material.google.com/style/color.html#color-text-background-colors
Thank you for sharing your work.

@esutton Hi, thanks for trying react-themable.
Yes, create a state to make the app react to theme change.
Please let me know if this example works for you. If so, I'll update the README:
index.ios.js
import React, { Component } from 'react';
import { AppRegistry } from 'react-native';

import App from './src/App';

AppRegistry.registerComponent('app', () => App);

./src/App
import React, { Component } from 'react';
import { AppRegistry, StyleSheet, Text, TouchableOpacity, View } from 'react-native';
import ThemeManager, { themable } from 'react-themable';
import MainPage from './pages/MainPage';

ThemeManager.config({ StyleSheet });
ThemeManager.addVariables('dark', { backgroundColor: '#303030', color: '#FFFFFF' });
ThemeManager.addVariables('light', { backgroundColor: '#FAFAFA', color: '#000000' });

// this makes the view support the 'theme' prop and make it available to the children context
const ThemableView = themable(View);

class App extends Component {
  constructor(props, context) {
    super(...arguments);

    this.state = { theme: context.theme || 'dark' };
  }

  setTheme(theme) {
    this.setState({ theme });
  }

  render() {
    return (
      <ThemableView theme={this.state.theme} style={{flex: 1}}>
        <MainPage setTheme={this.setTheme.bind(this) }/>
      </ThemableView>
    );
  }
}

export default themable(App);

./pages/MainPage
import React, { Component } from 'react';
import { AppRegistry, Text, TouchableOpacity, View } from 'react-native';
import ThemeManager, { themable } from 'react-themable';

class MainPage extends Component {
  render() {
    const styles = themeManager.getStyles(this.context.theme);

    return (
      <View style={styles.page}>
        <TouchableOpacity onPress={() => this.props.setTheme(themeManager.theme === 'dark' ? 'light' : 'dark') }>
          <Text style={styles.text}>Toggle Theme ({themeManager.theme}) </Text>
        </TouchableOpacity>
      </View>
    );
  }
}

const themeManager = new ThemeManager();
themeManager.create({
  page: {
    flex: 1,
    paddingTop: 22,
    justifyContent: 'center',
    alignItems: 'center',
    backgroundColor: '$backgroundColor',
  },
  text: {
    fontSize: 22,
    textAlign: 'center',
    justifyContent: 'center',
    alignItems: 'center',
    color: '$color',
  },
});

export default themable(MainPage);

@brunolemos No sorry.
I did something similar with app state and redux

@esutton okay, could you share these code parts? I'd like to see your approach to re-render after a theme change :)

I'll improve the API to make it simples and require less boilerplate code, but I'm closing the issue as the above example currently solves the problem.


fix(github): add build step before publishing release

Fixes #13

Summary

[x] Install dependencies from lockfile in CI/CD to ensure consistency when publishing; we should only be modifying lock files in development imo.
[x] Add build step before publishing

@lambrohan, you beat me to it with https://github.com/lambrohan/nestjs-meilisearch/commit/25268c92d2925cf7c2e469f2392f0f73a253c620. :)

I recommend we still incorporate installing dependencies from lockfile. I was about to repurpose this PR for that in case you liked the idea.
      - run: pnpm install --frozen-lockfile

I recommend we still incorporate installing dependencies from lockfile. I was about to repurpose this PR for that in case you liked the idea.
      - run: pnpm install --frozen-lockfile

FYI – I created https://github.com/lambrohan/nestjs-meilisearch/pull/16 in case you like the idea, @lambrohan.

merged


Render no graphs message correctly

Coverage increased (+0.04%) to 71.805% when pulling 552c65dacaf15121d809e08e07bbfcf493aed4ec on eatonphil:fix-no-graphs-render into 4ba21f858bfac921997bcbb95c62273cbc13041e on linode:develop.


How can I get OpenVPN to use my PiHole container as the DNS server?

I have a PiHole container providing DNS for my network.  It provides some static DNS entries as well as ad-blocking.
When I connect via OpenVPN, how can I get OpenVPN to only use PiHole for DNS?  Here is the docker-compose I use for PiHole
  pihole:
    container_name: pihole
    domainname: docker
    hostname: pihole
    image: pihole/pihole:4.2.1
    ports:
      - 53:53/tcp
      - 53:53/udp
      - 1969:80
      - 8183:443
    restart: unless-stopped
    cap_add:
      - NET_ADMIN
    volumes:
      - ${USERDIR}/docker/pihole/pihole:/etc/pihole
      - ${USERDIR}/docker/pihole/dnsmasq.d:/etc/dnsmasq.d
    extra_hosts:
      - foo:<IP_ADDRESS>
      - bar:<IP_ADDRESS>
      - fubar:<IP_ADDRESS>
      - foobar:<IP_ADDRESS>
    environment:
      - ServerIP=${SERVER_IP}
      - PROXY_LOCATION=pihole
      - VIRTUAL_HOST=pihole.${DOMAINNAME}
      - VIRTUAL_PORT=80
      - TZ=${TZ}
      - WEBPASSWORD=${PIHOLE_PASSWORD}
      - DNS1=<IP_ADDRESS>
      - DNS2=<IP_ADDRESS>

Alternatively, how can I manually have OpenVPN just point to two ip addresses?

Hi, have a look on this repository docker-openvpn-pihole.
I prepare a openvpn-install script, this set the static dns ip from pihole container into your openvpn server configuration.

Here's an excerpt from a well tested config
PIHOLE_IP=<IP_ADDRESS>
docker run --rm \
  -v /some/dir/openvpn:/etc/openvpn \
  kylemanna/openvpn ovpn_genconfig \
  -u udp://${VPN_IP} \
  -n ${PIHOLE_IP} \

Add a fixed IP address to pihole config
pihole:
  image: pihole/pihole
  networks:
    private:
      ipv4_address: ${PIHOLE_IP}

@sam2kb
What is the -n option for docker run?  I'm trying to find the equivalent for docker-compose
Here is mine
  openvpn:
    cap_add:
     - NET_ADMIN
    image: kylemanna/openvpn
    container_name: openvpn
    ports:
     - "1194:1194/udp"
    restart: always
    volumes:
     - ${USERDIR}/docker/openvpn-data/conf:/etc/openvpn

Also, I don't have a "private" network defined, so I'm not sure what to do.
Here is what I do have defined in my docker-compose:
networks:
  traefik_proxy:
    external:
      name: traefik_proxy
  default:
    driver: bridge

And if I use default I get the following:

ERROR: for pihole  Cannot start service pihole: Invalid address <IP_ADDRESS>: It does not belong to any of this network's subnets
ERROR: Encountered errors while bringing up the project.

With -n you can set the DNS Server for your OpenVPN Server
https://github.com/kylemanna/docker-openvpn/blob/master/bin/ovpn_genconfig

The IP of my docker server that is already running PiHole is <IP_ADDRESS>.  I modified the call for ovpn_genconfig to as follows:
PIHOLE_IP="<IP_ADDRESS>"
docker run -v $OVPN_DATA:/etc/openvpn --log-driver=none --rm kylemanna/openvpn ovpn_genconfig -u udp://vpn.${VPN_CLIENT_NAME} -n ${PIHOLE_IP}

Anytime I try to use https://github.com/mr-bolle/docker-openvpn-pihole, nothing seems to work.   I continually get the following error:

ERROR: for vpn_openvpn  user specified IP address is supported only when connecting to networks with user configured subnet

If you use your sub-network you have to adjust the openvpn IP, it is necessary that both container can speak together.
docker-compose.yml
openvpn:
networks:
vpn-network:
ipv4_address: <IP_ADDRESS>

pihole:
networks:
vpn-network:
ipv4_address: <IP_ADDRESS>

networks:
vpn-network:
external: true

To create this new sub-network
docker network create --driver=bridge --subnet=<IP_ADDRESS>/24 --gateway=<IP_ADDRESS> vpn-network

Figured it out.  I changed my docker compose per below.  This lets openvpn see pihole.  The default network is necessary to allow pihole to be accessible as it was before on the network.
    pihole:
    networks:
      pihole_sub:
        ipv4_address: <IP_ADDRESS>
      default:

    openvpn:
    networks:
      pihole_sub:

  pihole_sub:
    driver: bridge
    ipam:
      driver: default
      config:
        - subnet: <IP_ADDRESS>/16

So start your docker compose stack, then populate the ip and client name as follows:
PIHOLE_IP=$(docker inspect --format '{{ .NetworkSettings.Networks.docker_pihole_sub.IPAddress }}' $(docker ps -aqf "name=pihole"))
VPN_CLIENT_NAME="example.com"

Initialize your docker volume to use your static IP for your pihole_sub network
docker run -v ${USERDIR}/docker/openvpn:/etc/openvpn --log-driver=none --rm kylemanna/openvpn ovpn_genconfig -u udp://vpn.${VPN_CLIENT_NAME} -n ${PIHOLE_IP}

And then generate your OpenVPN server stuff
docker run -v ${USERDIR}/docker/openvpn:/etc/openvpn --log-driver=none --rm -it kylemanna/openvpn ovpn_initpki

At this point restart or rebuild the OpenVPN container.  Now you can generate and retrieve client ovpn files:
#Generate a client certificate without a passphrase
docker run -v ${USERDIR}/docker/openvpn:/etc/openvpn --log-driver=none --rm -it kylemanna/openvpn easyrsa build-client-full ${VPN_CLIENT_NAME} nopass

#Retrieve the client configuration with embedded certificates
docker run -v ${USERDIR}/docker/openvpn:/etc/openvpn --log-driver=none --rm kylemanna/openvpn ovpn_getclient ${VPN_CLIENT_NAME} > ${VPN_CLIENT_NAME}.ovpn

If for some reason you need to change the static IP for PiHole, you just need to put these values in ovpn_env.sh and openvpn.conf and restart the openvpn container.    They will have access to network resources, use PiHole ad blocking, and will have DNS routing to entries defined in PiHole’s “extra hosts” section.


Add collection to populatedb

I want to merge this change because...
I want to add few random named collections to data generated by populatedb command.
Pull Request Checklist

[ ] Privileged views and APIs are guarded by proper permission checks.
[ ] All visible strings are translated with proper context.
[ ] All data-formatting is locale-aware (dates, numbers, and so on).
[ ] Database queries are optimized and the number of queries is constant.
[ ] The changes are tested.
[ ] The code is documented (docstrings, project documentation).
[ ] Python code quality checks pass: pycodestyle, pydocstyle, pylint.
[ ] JavaScript code quality checks pass: eslint.

Codecov Report

Merging #1740 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master    #1740   +/-   ##
=======================================
  Coverage   83.15%   83.15%
=======================================
  Files         142      142
  Lines        6095     6095
  Branches      661      661
=======================================
  Hits         5068     5068
  Misses        857      857
  Partials      170      170

Continue to review full report at Codecov.

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


Argon2 support

Right now only support for scrypt is implemented. Is Argon2 support in scope of this project?
I have an implementation ready that is based on https://crates.io/crates/argon2, I was wondering what I should PR against, master or 0.6?

Sure, feel free to PR against master (I will be merging them soon anyway)! scrypt support is gated behind a feature, and it seems like argon2 support should also be behind a feature as well.


Extend PRISM DID Method to include network reference

Proposed feature
The current PRISM DID method does not include a reference to the underlying VDR on which the DID was published. This was a reasonable approach in the past but will cause issues going forward when PRISM will be expanded to other chains. The proposal is to publish a new version of the PRISM spec (1.1 or 2.0?) to accommodate this change. The new PRISM DID would then look like this: did:prism:cardano:preprod:123.
Feature description
Why is the current specification an issue?
Creating a PRISM DID is independent of the VDR. This means a DID, once created in memory, can be published on multiple networks and later updated independently on each VDR. Currently, this situation is mostly unproblematic, since the Cardano mainnet can be treated as the source of truth in case the same DID does exist on different networks at once. With the outlook to make PRISM agnostic to the VDR, this will cause a problem. As it stands today, we might be facing this challenge earlier than expected as Midnight is already available for testing purposes.
An important point to highlight here is that having the same DID on multiple networks is not only an issue of confusion but could also pose a major security concern, since an node-indepentent resolver cannot determine the single source of truth.
Naming Options
While most other DID methods handle the network reference with just a single string delimited by a colon, e.g., did:prism:preprod, this might not be sufficient for our use-case when expanding to other chains. To keep the DID as simple as possible, one could imagine a naming convention to keep the name short, e.g., did:prism:cp (for Cardano-preprod) or "mm" (for Midnight mainnet).
The more understandable alternative would be to use the full name, e.g., did:prism:midnight:mainnet. This would also be aligned with what Indy is currently doing, e.g., did:indy:idunion:test.
Implications
The change would affect nearly every component (SDKs, agent, node) and therefore requires a coordinated approach. A possibility would be to support both versions of the spec for some time and then remove support for the old spec after all components completed the migrations.
While most changes are pretty light, there might be a potential issue with a change required to the protobuf definition and therefore the node. I haven’t looked into that in detail, so this has to be evaluated by someone. One option would be not to do the change in the node itself and work around that for now, which seems to be feasible at first glance.
On the other hand, this change might open the chance for a larger rework of the PRISM spec, in light of a potential Midnight implementation and other possible additions (e.g. "controller", "AlsoKnownAs")
Anything else?
The main reason I’m raising this issue/feature request now is that I believe this change should rather be done sooner than later. The current user base is still very small, and the people noticing this change apart from this group can be counted on one hand. This will change rather quickly: At first, through new projects coming from Catalyst, and later with Lace. I would argue that this has to be completed before the first version of Lace with identity features ("Identity Center") will get into the hands of any (test) users. Doing this change to the PRISM spec at a later point in time might cause much greater headaches than doing it now.
This feature request moved over from here

@patlo-iog @EzequielPostan @lohanspies to review the business value for this request and then decide implementation steps.

As far as I remember from the previous discussions about this. We decided that:

If the DID doesn't have a prefix it would be on the Cardano's mainnet.
did:prism:mainnet:... wouldn't exist because of backward compatibility with what is now in the specs.
In the future, if we would like to have other networks like Cardano's testnet the proposed would be to look like did:prism:testnet:...

I also have other security concerns. Make it impossible* to have similar DIDs that only the differences on the network.
For example IMO: did:prism:HASH1 and did:prism:testnet:HASH1 should be impossible. The HASH is calculated based on the first block (AtalaOperation for the DID) written to the network. So I would propose that all other networks (other than the mainnet) MUST have a reference to the network in the initial 'AtalaOperation'. This will make the DID completely different even if they are using the same keys.

First of all, thank you for creating an issue! :)
Second, my apologies for the delay, I was away.
Now, responding to the comments.

Creating a PRISM DID is independent of the VDR. This means a DID, once created in memory, can be published on multiple networks and later updated independently on each VDR.

If we look at the spec, the very first sentences in the abstract of the PRISM DID method spec says:

The prism DID method defines data models and protocol rules to create, manage, and resolve Decentralized Identifiers (DIDs). The protocol is defined on top of the Cardano blockchain as its verifiable data registry, where DID's information is stored.

meaning that a DID corresponding to the did:prism DID method, is by definition on the Cardano mainnet network.

[...] Currently, this situation is mostly unproblematic, since the Cardano mainnet can be treated as the source of truth in case the same DID does exist on different networks at once.

It is true that anyone can take the raw protobuf operations and post them somewhere else, but that doesn't create a (published/short-form) DID according to the did:prism DID method. Valid update/deactivate operations of the said DID method are required to be published on Cardano mainnet.
It is not recommended for any user to create a valid (signed) Create/Update/Deactivate operation if it is not intended to be posted and processed. So, it is even less recommended to share such an operation publicly.

[...] since an node-indepentent resolver cannot determine the single source of truth.

I am not following what a "node independent resolver" refers to in this context.
Note that the method name (i.e. the "prism" in "did:prism") is precisely what indicates that the DID to resolve is following the PRISM DID method spec, and as a consequence the needed data (operations) are on Cardano mainnet.
Now, taking the general idea of multi-network DID methods. From an architectural point of view, the more underlying chains you add to a DID method, the more costly is to run it. If we extend PRISM DIDs to be publishable in say, testnet, pre-prod, and mainnet, then a PRISM node would either need to follow (i.e. sync) all those chains to be able to resolve any DID of the DID method; or follow a subset of the chains and not be able to resolve DIDs from the chains it does not follow. It also would bring issues of "replay attacks" that you (and @FabioPinheiro) are referring to (i.e. posting valid operations from one VDR on-another).

With the outlook to make PRISM agnostic to the VDR, this will cause a problem.

Maybe I can clarify something here. PRISM, the system, is not the same as did:prism the DID method. Any system can rely on multiple DID methods (which may rely in different chains). There is no need to extend an underlying method to support other chain. For example, any agent could use simultaneously did:prism and did:ion DIDs (from Cardano and Bitcoin respectively) without the need to change any of did:prism nor did:ion methods. It is just a matter of the said agent to resolve each DID with the corresponding DID resolver and to post operations in accordance to each DID method spec. There are specifications and code on a universal resolver and a "universal registrar" to manage DIDs from multiple DID methods in uniform ways.
In short, supporting different chains/VDRs does not necessarily require a change in the DID method. In the context of Midnight, applications could just use did:prism as is, or other DID method of the convenience to each specific app, or even develop a custom DID method if the app sees need.
We are, of course, open to talk about extending the current PRISM DID method, but I am not sure if your use case reflects a real need.
Please feel free to add any clarification and/or point out anything I may be missing.
Once again, thank you for opening the issue!

Thank you for the detailed answer @EzequielPostan
I believe the central issue here seems not to be a technical one, but a different understanding of what PRISM can mean, and the business decisions that have been made or ought to be made in the future. Allow me to explain: PRISM can mean multiple things: the brand, the DID-method specification, and the overall codebase. Aligning all three under the term “PRISM” has been coherent in the past, and your answer is a reflection of that:
Yes, did:prism is just referring to the mainnet, and yes, the spec only mentions the mainnet. Under the assumption that this will also be the case for the future, the change isn’t necessary at all – I agree. If someone wants to use another VDR, just use another DID method.
But things got stirred up a bit: Part of the codebase is going open-source (Indy Identus?) and Midnight is coming along. These pose challenges to the coherency, and this issue here is trying to be a partial solution to this.
The solution I propose here is to keep the PRISM branding (because it is somewhat established by now) and therefore the DID-method name did:prism. From a purely technical perspective, I would agree that it would make sense to just use another DID method for Midnight and other VDRs, to keep the spec clean and the method-namespace clear of any additions. But my fear is that using another DID method for Midnight or any other VDR, but keeping the PRISM brand for parts of the codebase, might cause more confusion than we already have.
Changing the spec to allow for different VDRs/networks and making the necessary changes in the related codebases now is a relatively low price to pay, in light of the alternatives. This is especially true because the PRISM spec is, apart from the wording, from a technical perspective quite independent of the VDR. And to get to your point:

From an architectural standpoint, the more underlying chains you add to a DID method, the more costly it is to run it.

I wouldn’t really agree with that if we add the namespaces as suggested. We can have different node implementations for different VDRs or networks in general which don't need to know anything about each other: they would simply reject any request which isn’t targeted at their specific namespace. E.g., we have a PRISM Scala node which just handles did:prism:cardano:mainnet operations, another instance of the same node which handles did:prism:cardano:preprod operations, and a third node which might be written in Rust which handles all did:prism:midnight:mainnet operations.

In the context of Midnight, applications could just use did:prism as is
Wouldn't this exactly cause the architectural issue you are describing? We would need to have a single node keeping up with both networks?

Getting back to the main point: While I believe we can all find common ground on the technical or even architectural implementation, the core of the issue is a business decision on how to handle the PRISM brand and how the relationship between the PRISM brand, the spec, the public codebase (Identus?), and the closed-source products should look going forward. Maybe it would even be a consideration to introduce did:identus as the future spec?

Once again, apologies for the delay on my part
I will first comment on the technical side.

I wouldn’t really agree with that if we add the namespaces as suggested. We can have different node implementations for different VDRs or networks in general which don't need to know anything about each other

the thing is that, even if you have namespaces like did:prism:network1:... and did:prism:network2:..., both DIDs would still belong to the same DID method, namely did:prism. This is important to note, as if you have multiple chains, the guarantees each chain offers may be different. Different chains have different indexing costs, throughput, latency, fees, settlement time, rollback guarantees, data availability guarantees, and so on. As a consequence, the DIDs "hosted" under each chain will end up having different properties too.
Now, I raise the above because the technical goal behind having a DID method is to guarantee properties about the DIDs it supports. Making the multi-chain method makes the general properties (the ones applied to all the DIDs in the DID method) weaker.
On your question of the architectural issue:

Wouldn't this exactly cause the architectural issue you are describing? We would need to have a single node keeping up with both networks.

Correct, the issue of supporting N DID methods is, in structure, the same as supporting multiple networks under a single method. However, the SSI space already structured the universal resolver as a solution for the former. For interoperability, the system will eventually need to use more DID methods, which most likely will use the universal resolver. Re-creating this issue at a DID method level does not seem to pose many technical advantages over using the already adopted solution in the space.
Now, on branding and naming. I can understand that there may be challenges on keeping things clean and coherent in this area. However, I still incline myself to believe that this issue should be tackled on a branding side, and not a spec side.
Please let me know if I can add anything else to this conversation.
I hope my answer helped here.
And, once again. Thank you for the time to post your comments.

@EzequielPostan Thank you for your detailed response, and now I must apologize for my delayed reply. While I certainly agree with some points you've raised, I'd like to offer a different perspective.
In your argument, you closely associate the DID method with its underlying VDR. I am not convinced that this association is necessary, nor is it intended by the DID-core spec itself. Rather than defining the properties of the VDR, the DID-core spec (as well as the PRISM spec) focuses on the feature set provided (i.e., the data model, representation, and available operations). The spec does not detail the assumptions one might have about the properties of the VDR.

Different chains have different indexing costs, throughput, latency, fees, settlement time, rollback guarantees, data availability guarantees, and so on.

Indeed, different chains have different properties. However, I don't see a direct link between the DID method itself and the properties of the VDR. It's reasonable to have different expectations for different networks, as is already the case with other chains. For instance, did:indy:indicio and did:indy:sovrin both refer to mainnet networks with production data but have different VDR properties, costs, governance structures, and even feature sets (e.g., Sovrin does not support arbitrary DID-document data). Thus, shifting assumptions from the method to the network level is not unprecedented and offers considerable flexibility depending on one's requirements. For example, one could even envision a did:prism:iog network, which is a permissioned network similar to Sovrin, removing the need for Trust-Registries for certain use cases. Moreover, the expectations one might have of the underlying VDR are not part of the spec – and of course they shouldn’t be. That said, the spec defines the feature set independent of the VDR. And having a common feature set that spans multiple VDRs can be a very useful approach.

the SSI space already structured the universal resolver as a solution for [this]

I don’t think so. The universal resolver/registrar doesn’t support a unified feature set. In many cases, it's simply not possible to take the same DID and anchor it on a different VDR. Taking the Indy network as an example again: You can't take a random DID-Document written on Indy (e.g., indy:indicio, indy:bcovrin, indy:idunion) and write the same information as a PRISM DID because the PRISM specification doesn't capture properties like controlledBy or AlsoKnownAs. The same is true in reverse; for instance, you can't represent any PRISM-DID on the indy:sovrin network. My point is, while the universal resolver/registrar offer interoperability to a certain degree, they don't provide feature parity, even if it might seem so at first glance. They offer a unified interface, but not the possibility to establish a unified feature set for DID-methods.
While I'm not advocating for extending PRISM across all available VDRs, I see a benefit in extending it to specific chains (e.g., Midnight) where we may have an interest in, rather than duplicating the specification.

I still incline myself to believe that this issue should be tackled on a branding side, and not a spec side.

I believe the strategic vision for PRISM should be the major factor here. In case IOG/Atala decides to maintain the PRISM brand and offers products that are VDR agnostic, it would also make sense to have a DID method with the same name that is likewise agnostic, providing the same feature set seamlessly across multiple VDRs. This approach still leaves room for the universal resolver/registrar approach for those chains where IOG/Atala has less vested interest.
I'm playing a bit of devil's advocate here, as I believe both arguments on handling different networks have their merits. In my opinion the deciding factor isn’t purely technical but rather depends on the direction IOG/Atala wishes to take product-wise.
Aside from the discussion on a VDR agnostic PRISM method, there's still the matter of the necessity for a preprod/mainnet namespace. While I’m divided on the VDR topic, I’m strongly in favor of adding the namespace for at least the preprod network, to be more explicit, avoid confusion and close the door to potential security issues.


CS.countries is giving undefined method 'exists?' for File:Class error

I have followed the following steps to install city-state:

Added city-state in gem file.
Run bundle install.

Then I tried to get the list of countries in rails console by:
CS.countries

This issue occurs because I had installed 0.1.0 version in which exists? method has been used, and now this method has been depreciated.
To resolve this issue make you have installed 1.1.0 version. You can lock the gem version by adding the below line in your gem file:
gem "city-state", "1.1.0"

Good catch. Thanks, @anmol-kumar0815.
I restricted the version 0.x series to Ruby 2 only (@release 0.1.1)
This guarantees that users using Ruby 3 and higher always use the latest 1.x series, even when not explicitly defining the version on Gemfile.


Rename core.applications to just applications and configure core.applications ID.

[x] Replace references to core.applications with config('streams.core.applications_id')
[x] Check for published applications definition and use that otherwise register the shipped version.

https://github.com/laravel-streams/streams-core/commit/69439a6ec6364328994641c1ccb0f0f95f0206ec


Router Query Engine Streaming

Question Validation

[X] I have searched both the documentation and discord for an answer.

Question
Is there a way to use streaming with the router query engine? And if not, would it be possible to make a feature request for it?

@yuvansharma yea it is possible, you can do something like this:
from llama_index.response_synthesizers import TreeSummarize

summarizer = TreeSummarize(service_context=service_context, streaming=True, use_async=False)

query_engine = RouterQueryEngine.from_defaults(...., summarizer=summarizer)

@yuvansharma yea it is possible, you can do something like this:
from llama_index.response_synthesizers import TreeSummarize

summarizer = TreeSummarize(service_context=service_context, streaming=True, use_async=False)

query_engine = RouterQueryEngine.from_defaults(...., summarizer=summarizer)

@logan-markewich
This workaround not working in the latest release


[tvOS] Focus not working on tvOS

Describe the bug
I created a new Renative app using command rnv new. I've chosen the template renative-template-hello-world. My rnv version is 0.34. When I'm running the sample application on tvOS, its focus is not working. For focus, do i need to setup something additional?
Please help me with this.

@himanshuttn please update to latest rnv, 34 is quite old. In this latest version the template has also been renamed to @rnv/template-starter


$searchChannel and $searchChannelCount

$searchChannel[channel_name;seperator(optional)]
message.guild.channels.cache.filter(x => x.name.includes("channel_name")).map(x => x).join(", ")

$searchChannelCount
message.guild.channels.cache.filter(x => x.name.includes("channel_name")).map(x => x).lenght

As I said on Issue 139. Use as a channel.

Referenced

$searchChannel[channel_name;seperator(optional)]
message.guild.channels.cache.filter(x => x.name.includes("channel_name")).map(x => x).join(", ")

$searchChannelCount
message.guild.channels.cache.filter(x => x.name.includes("channel_name")).map(x => x).lenght

As I said on Issue 139. Use as a channel.

no need to open a new issue

$searchChannel[channel_name;seperator(optional)]
message.guild.channels.cache.filter(x => x.name.includes("channel_name")).map(x => x).join(", ")

$searchChannelCount
message.guild.channels.cache.filter(x => x.name.includes("channel_name")).map(x => x).lenght

As I said on Issue 139. Use as a channel.

no need to open a new issue

Oh k do I close?


scrollMonitor hijacked with malicious code!

Months ago I switched from sakabako to stutrek, github's redirect worked for a long time but has now been hijacked and contains malicious code. Please update the repository to stutrek/scrollMonitor from sakabako/scrollMonitor.
stutrek/scrollMonitor/issues/54

it seems already done ?

ok, done. please notice it means clients need to run "bower cache clean" to get new url

Thank you!


Custom page size options parsed incorrectly in CentOS

Environment information
OS Version: CentOS 7.5.1804
Firefox Version: 63.0.3
CUPS Version: 1.6.3
Steps to reproduce:

Add [FileDevice Yes] in cups-files.conf file.
*the Path of cups-files.conf:
/etc/cups/cups-files.conf
Input [localhost：631] on Firefox 63.0.3 on CentOS 7.5.1804 and press Enter.
Select [Administration] tab, and click [Add Printer].
Select [AppSocket/HP JetDirect], and click [Continue]
Input [file:/tmp/test.prn] in Connection, and click [Continue]
Input any in [Name], and click [Continue]
Click [Choose File], import the Ricoh's ppd (Ricoh SP 8400DN, http://www.openprinting.org/printer/Ricoh/Ricoh-SP_8400DN).
Click [Add Printer].
Ctrl + P, select [Page Setup] in [Printer] dialog.
Set [Manage Custom Sizes] in [Paper Size].
Set Width: 20inch, Height: 50inch, then select the custom page size in [Paper Size]
Click [Print] button.
Open the test.prn (step 5)
Check the command of custom page size

Actual results:
The following command of custom page size is outputted:
%%BeginFeature： *CustomPageSize True
595.280029296875
841.890014648438
0
0
1
pop pop pop
<< /PageSize [ 5 -2 roll ] /ImagingBBox null >>
/Policies <</PageSize 2 /MediaType 2>>
/DeferredMediaSelection true
>> setpagedevice
%%EndFeature
Expected results:
According to PPD, the range of Width is 3.5 ~ 12inch, and the range of Height is 5.8 ~ 23.6inch.
Because the custom page size [Width: 20inch, Height: 50inch] is out of the range, the following command of default size (Letter) should be outputted:
%%BeginFeature： *PageSize Letter
<< /PageSize [ 612 792 ] /ImagingBBox null >> setpagedevice
false setedgetoedge
%%EndFeature
Additional informations
We verified the Brother's driver (Brother MFC-7840N, http://www.openprinting.org/printer/Brother/Brother-MFC-7840N), and found the same problem.

We'll need to see the debug CUPS error_log to see what the application (you don't specify which) is sending. Run "cupsctl --debug-logging" to enable debug logging and then do your steps to print. Then attach the /var/log/cups/error_log file.

Thank you very much for your reply.
I am so sorry that I did not described the application clearly which has the problem. This problem occurs on multiple applications (such as gedit, Firefox, etc.).
According to the method you suggested, we got the error_log file and attached it.
error_log.zip
For this error_log file, there is a brief description as follows:

Job No. 47 is printed by the application [Firefox].
Job No. 48 is printed by the application [gedit].


Intercept Line

I also suggest to create a front end :nerd_face:

Thanks for the contributions and good idea! Thanks @PedroCisnerosSantana!


modeldeploymentname is __Empty

Package Name: azure-monitor-query
Package Version: 1.4.0
Operating System: Docker Container (mcr.microsoft.com/devcontainers/python:1-3.11-bookworm) on Windows 10
Python Version: 3.11.9

Describe the bug
The modeldeploymentname is empty for certain deployed models. Namely DALLE3.Standard.Low and Whisper

To Reproduce
Query the metrics of the specified models:
ids = ["your/id"]
response = await self.metrics_clients[location].query_resources(
                resource_ids=ids,
                metric_namespace="Microsoft.CognitiveServices/accounts",
                metric_names=[
                    "TokenTransaction",
                ],
                filter="ModelDeploymentName eq '*' and FeatureName eq '*'",
                timespan=(start_time, end_time),
                granularity=timedelta(days=1),
                aggregations=[MetricAggregationType.TOTAL],
            )

Expected behavior
It should contain the model name as specified during the deployment, instead of empty.
Additional context
I can provide the exact resource id via PN.

@xiangyan99
I do not own `azure-monitor-query, please reassign.

Hey @DanielHabenicht. The azure-monitor-query SDK only outputs what the monitor metrics API returns, so it's likely a service-side issue. If you were to view the OpenAI metrics in the Azure Portal, does it show the same? I'm not sure what's up, but it seems like some of the dimensions aren't being populated/leveraged for the TokenTransaction metric. Couldn't find much online regarding the issue (only really this question for something similar for Cosmos metrics).
You'd probably get better eyes on this by opening a question on the Microsoft Q&A website or opening a support request (can do this by going to the "Help + support" option in the left-hand menu of your OpenAI resource in the Azure Portal).

In the Azure Portal the TokenTransaction Metric is not available :/

I will ask the support directly and update this issue accordinly.

Based on these docs TokenTransaction corresponds to Processed Inference Tokens. After that, can apply splitting on ModelName and ModelDeploymentName

Based on these docs TokenTransaction corresponds to Processed Inference Tokens. After that, can apply splitting on ModelName and ModelDeploymentName

Yes, somehow I must have overlooked that.
It shows up in the Azure Portal as well:


sbt assembly error

[error] Could not run test TensorFlowNetSpec: java.util.NoSuchElementException: key not found: SPARKNET_HOME
...
...
...
[error] Could not run test CaffeNetSpec: java.util.NoSuchElementException: key not found: SPARKNET_HOME
[info] Run completed in 9 seconds, 564 milliseconds.
[info] Total number of tests run: 6
[info] Suites: completed 4, aborted 0
[info] Tests: succeeded 6, failed 0, canceled 0, ignored 1, pending 0
[info] All tests passed.
[error] Error during tests:
[error] 	TensorFlowNetSpec
[error] 	CaffeNetSpec
16/04/22 10:37:22 INFO RemoteActorRefProvider$RemotingTerminator: Remoting shut down.
[error] (test:test) sbt.TestsFailedException: Tests unsuccessful
[error] Total time: 133 s, completed 2016-4-22 10:37:22
I got the errors shown above when running sbt assembly . and I have set the variable
SPARKNET_HOME in the ~/.bashrc . I don't know why this happened .
Any help would be greatly appreciated . Thanks

If you already set SPARKNET_HOME in the ~/.bashrc, can you try running source ~/.bashrc before compiling?
Or try running export SPARKNET_HOME=/path/to/SparkNet with the appropriate path?

Yes ,  I do run source ~/.bashrc
and I verify that by
echo $SPARKNET_HOME
It works well.

Strange. One simple workaround would be to just hardcode the correct value for val sparkNetHome = ... in the relevant tests and apps.

Thanks , It works . But another problem appears ,
[info] - should be fast *** FAILED ***
[info]   org.scalatest.exceptions.TestFailedException was thrown. (PreprocessorSpec.scala:146)
I check the 146 line of PreprocessorSpec.scala is
assert(totalTime <= 0.2)
I try recomplie and things work out after comment  assert(totalTime <= 0.2)
I am not sure if there are some latent problems?

Yeah, that line was meant to indicate that certain operations should be relatively fast, but the actual speed will depend on other factors and that line can fail even if there are no errors.

Thanks, robert. It really helps


Subscribe to store mutations OR Watch store

I didn't find anything related to Subscribing to mutations or to Watching a store module state in the NuxtJS documentation.
Any idea how to do that from the component ?
In that example : nothing is happening when subscribing to a mutation that is inside a store module called test.js. Same when trying with watch.

<script>

import { mapState } from 'vuex';

export default {

  computed: mapState(['test']),

  created() {
    this.unsubscribe = this.$store.test.subscribe((mutation, state) => {
      if (mutation.type === 'updateStatus') {
        console.log(`Updating to ${state.status}`);
      }
    });
  },

  beforeDestroy() {
    this.unsubscribe();
  },

};
</script>

If I understood you correctly this feature is already supported since nuxt just exposes Vuex.
There are however a few problems with your code which result in your example not working like expected.
Without seeing how you setup your Vuex store I'm assuming you have created a Vuex module by creating a file called test.js.
This will create a namespaced module. As such the mutation type you want check for is namespaced as well. Again, assuming your module is test the mutation type is test/updateStatus.
Additionally Vuex subscriptions are always global. As such the subscribe code should be
created() {
    this.unsubscribe = this.$store.subscribe((mutation, state) => {
      if (mutation.type === 'test/updateStatus') {
        console.log(`Updating to ${state.status}`);
      }
    });
},


[FIXED JENKINS-28860] Do not rely on relative links

JENKINS-28860

Thank you for a pull request! Please check this document for how the Jenkins project handles pull requests


Hit testing fix and support for horizontal wheel scroll

-hit testing fix for items not in visible part handling mouse events
-support for horizontal wheel scroll

hit testing fix for items not in visible part handling mouse events

Could you explain more about this? Is there an issue files, or a unit test failure that I can look at?

support of horizontal wheel :
At my laptop mouse pad I can make horizontal scroll on any application (explorer, chrome etc.).
In avalonia if we have a horizontal content with scroll viewer the same mouse pad action are not making the content to scroll left/right - this PR is making that possible.

2.Hit testing problem fixed
In vertical listbox with scroll without virtualization with 100 items, but the listbox is restricted by it's bounds, so it shows only 10 and you can scroll up and down, let's say that the visible items are from 10-20.
It was possible to click on item 0-10 that are not visible in the visible part of the listbox content.
So other  controls outside the listbox were unable to process the mouse events because of that.
There are no issues about those, but I've noticed it and tryied to fix them.

support of horizontal wheel

Yes, this should be supported.

Hit testing problem fixed

I still don't understand what the problem is here, sorry. Would it be possible to write a unit test that demonstrates it? Or even a video that shows what's happening.
Anyway, the two fixes should be placed in separate PRs as it's hard to review like this, and if one isn't quite right it will prevent the other from getting merged.

@grokys There was only few lines of code so i tough it could be  faster to be in single PR.
I'll make 2 PR's with both issues separated


Fix Examples to support configuration with no authentication

Fixes #15.

Hey @nickzana!
Thx for the contribution. I would be honest that I didn't put that much effort to cover all the cases in examples. But the updated example indeed covers them

No problem! I appreciate your work regardless. I need it for a project that I'm working on, and my transmission configuration doesn't use BasicAuth, so I thought I would improve the examples to support that.


Different panning on desktop than mobile

I was wondering if it would be possible to to have two different ways to navigate?
On desktop - I would like to click and move my mouse to the right to pan but be able to hold it and the panorama pans around to the right continuously without having to move my mouse again.
On mobile/tablet - This would be fine just the way it is, drag your finger on the panorama from left to right and the panorama pans right.
This would be similar to how krpano works which is quite good for user experience. I know Google maps works with the click and move on desktop but I find the krpano way better.
Also, I just wanted to say I love what you're doing. keep up the good work.

This is something I considered more seriously a few years ago but eventually decided against. I originally implemented the click and drag method as that is my preference, as I use the arrow keys when I want more continuous navigation. In the panorama community everyone has a preference as for which navigation method is better. However, I think the current click and drag method is more intuitive to the general public due to the proliferation of touch screen devices. I'm not entirely against having the krpano-like navigation as an option, but I don't think I'll ever add it myself as I would like to keep the user experience consistent across devices and websites using Pannellum.


Schema Compare failed to apply when creating a new empty schema with a "DOMAIN\User"

Azure Data Studio Version: 1.39.1
OS Version: Windows 10 (21H2)

Steps to Reproduce:

Create a database project of your database.
Create a new schema with a pattern "DOMAIN\User", like "Contoso\Lucas", directly, without touching the database project.
Update the database project with Schema Compare.

When creating a new project is not the problem, the problem is when applying the new created schema, through schema compare. First I don't like the usage of a pattern "DOMAIN\User" as a schema, but I was dealing with an legacy database, so that happened. Secondly, when was trying to apply the error message was "Could not find part of path \Domain\User\Schemas\Domain\User.sql". The folder "\Domain\User\Schemas" was there, but I imagine the character "\" on the schema was the cause of the error.

Does this issue occur when all extensions are disabled?: Not applied (since Schema Compare is a built-in extension)

When creating a project from db in SSDT for a db with a schema in this format, it creates the file name as domain_user.sql. We need to update the DacFx to do something similar for ADS sql projects.

This is fixed in DacFx so that slashes and backslashes get replaced with an underscore in the file name. This will be brought into ADS the next time DacFx gets updated before the next release.


Crash in VisualStateManager.GoToState when animations are disabled in Windows

Describe the bug
When animations are disabled in Windows settings the call to VisualStateManager.GoToState crashes in certain conditions.
The minimal repro solution:
https://github.com/BaZzz01010101/ReproAnimationCrash
Steps to reproduce the bug

Disable animations in Windows Settings >> Ease of Access >> Display >> Simplify and personalize Windows >> Show animations in Windows
Checkout the minimal repro solution from https://github.com/BaZzz01010101/ReproAnimationCrash
Build and run the solution in debug mode
Click the checkbox in the app 3 times to switch visual states

Expected behavior
The red circle in center should appear, disappear and then appear again according to visual states transitions programmed in the app but without animation according to Windows settings.
Instead the application is crashing on the 3rd switch of the checkbox.
When animations are enabled in Windows the application is not crashing but the animation is not started on the 1st state switch as expected. The circle just appeared without fade-in-out animation. On the 3rd state switch it start animating.
Screenshots

NuGet package version
WinUI 3 - Windows App SDK 1.3.2: 1.3.230602002
Windows version
No response
Additional context
No response

but the animation is not started on the 1st state switch as expected. The circle just appeared without fade-in-out animation. On the 3rd state switch it start animating.

This is because you're not in any state the first time you call it, so the state transition doesn't work. You should set the current state in both OnApplyTemplate and on the control Loaded to be safe, so there is a default state and a state to transition from.
You also have an infinite repeating VisualTransition which I would wager is "Unsupported" behaviour - that's not a transition if it never finishes. The infinite repeating animation should be the state storyboard itself (as the state is... flashing)

You also have an infinite repeating VisualTransition which I would wager is "Unsupported" behaviour - that's not a transition if it never finishes.
I can't agree with this. The transition itself is not infinite, it has the start value, the end value and the duration. The repeating is infinite and this is absolutely valid use case overwise why we even have RepeatBehavior="Forever" option.

In any case this is quite wrong behavior that call is crashing when animations turned off in windows but works like expected when it's not.

To be a transition it actually needs to end. You're actively breaking VisualStateManager with infinite transitions - you'll see that CurrentStateChanged will never fire when going to the Animation state because the state change never finishes as you transition never finishes. Your actual "state" is a flashing animation - that transition might be the first flash but the actual state is flashing.
<VisualStateGroup x:Name="CommonStates">
                        <VisualState x:Name="Normal">
                            <VisualState.Setters>
                                <Setter Target="AnimatedContent.Opacity" Value="0" />
                            </VisualState.Setters>
                        </VisualState>
                        <VisualState x:Name="Animate">
                            <Storyboard>
                                <DoubleAnimation
                                    AutoReverse="True"
                                    RepeatBehavior="Forever"
                                    Storyboard.TargetName="AnimatedContent"
                                    Storyboard.TargetProperty="Opacity"
                                    From="0.0"
                                    To="1.0"
                                    Duration="0:0:1" />
                            </Storyboard>
                        </VisualState>

                        <VisualStateGroup.Transitions>
                            <VisualTransition From="Normal" To="Animate">
                                <Storyboard>
                                    <DoubleAnimation
                                    Storyboard.TargetName="AnimatedContent"
                                    Storyboard.TargetProperty="Opacity"
                                    To="0.0"
                                    Duration="0:0:1" />
                                </Storyboard>
                            </VisualTransition>
                            <VisualTransition From="Animate" To="Normal">
                                <Storyboard>
                                    <DoubleAnimation
                                        Storyboard.TargetName="AnimatedContent"
                                        Storyboard.TargetProperty="Opacity"
                                        From="1.0"
                                        To="0.0"
                                        Duration="0:0:1" />
                                </Storyboard>
                            </VisualTransition>
                        </VisualStateGroup.Transitions>
                    </VisualStateGroup>

Using a VisualStateGroup like this with the infinite animation in the state itself allows the VSM to behave properly.
Presumably when animations are disabled it's trying to calculate the final value value of the transition and can't as there isn't one. (VSM runs down different code paths for Windows animation's being disabled and having transitions explicitly disabled)


When spin watch terminates spin up, allow it to delete its temp dir

Fixes #1698.
A previous crack at this in #1711 ran aground on sychronising the spin build and spin up processes when spin up was terminating asynchronously.  I couldn't get the watch state to remain in sync with what watchexec thought it was doing, resulting in either missed file changes or missed restarts.
This is, I'm afraid, a more dramatic rework, and therefore carries a higher risk - the more so because, unlike the original implementation, it does not abstract notifications or defunctionalise process control, and so it way less amenable to unit testing.  I'm not sure how to address that - I'd welcome ideas.  On the plus side, the individual components at work here are rather more simple-minded, so hopefully less in need of unit testing once the inevitable initial bugs have been shaken out.
The change in strategy is twofold:

Instead of a single watchexec watching all interesting files, and patching up "what command is watchexec running" depending on what files have changed, this now uses two separate watchexecs, one watching artifact files, one watching build files.
These watchexecs do not manage processes themselves. Instead, they send notifications to two processor tasks, the buildifier and uppificator.  (Okay, yes.  I should probably change the names.)  These spawn and restart processes according to the notifications they receive, and coordinate so that changes triggered by a build do not start spin up until the build is complete.

This means that the processor tasks are much less dependent on state than the previous implementation - they are pretty much simple loops going round and round waiting for the change notifications they're interested in and starting or restarting a child process.  (The only piece of state that needs to be passed between notifications is "don't clear the screen because build just did".)
This has so far been tested only on a small Rust application.  Next step is to try it on something like the docs site, where the build process makes much more far-reaching changes to the artifacts.  It should also adopt some of the "stupid operating system does what" patches from the previous implementation!
In the meantime I'm putting this out for folks to kick the tyres and yell at the design/implementation.  @calebschoepp needless to say, I would particularly value your experience and insight on the practicalities as well as the design!

Well there's a bug where the docs site makes it go into an infinite loop so we're off to a flying start.

@itowlson I'll take a look at this when I get a chance, but I won't have time today. Thanks for diving so deep on spin watch.

@calebschoepp I think this addresses everything.  I have left the commit history intact for now so you can see changes since first review if that's useful; if approved, I'll squash before merging (well if I remember anyway).

@calebschoepp I implemented your fix for the Mac source notification issue.  It Works On My Machine(s) TM, but if you have time to test it on yours, that would greatly increase my confidence.  Thanks!

@calebschoepp I implemented your fix for the Mac source notification issue. It Works On My Machine(s) TM, but if you have time to test it on yours, that would greatly increase my confidence. Thanks!

I built latest on this branch and we no longer get the infinite looping behaviour. I'm seeing one infinite loop bug persist though. I sent you a video of it in Slack.


Require a specific version of tilequeue

This should not be merged through the github UI.
2.8.0 will not run with the latest master of tilequeue. Specifying an exact version avoids this. Because of #119, I am not specifying pypi as a source, because the same issue exists for tilequeue.
This should be merged to a branch for v2.8.x and be part of a v2.8.1 release

I pushed over a 2.1.1 release and published it to pypi as well.


Update tabler icons to v2.1.2

Thanks @sebastianpopp, I'll get this looked at when I'm done with work later on!

Replaced by #20.


Kubectl download instruction  does not work correctly

Curl command download fail in home dir instead of /usr/local/bin

#10


nginx module: fix reload on config change

Motivation for this change
The current configuration makes no sense, it requests reloading based on a store path. This change allows reloading when /etc/nginx/nginx.conf changes, which might be useful for testing changes.
Alternatively, the trigger could be removed.
Things done

Built on platform(s)

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

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

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

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

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

[ ] Fits CONTRIBUTING.md.

You need to review for restartTriggers works. And by "review" I guess I mean dig really deep into a convoluted perl script that almost no one in this community understand...
restartTriggers doesn't do anything directly. The point of restartTriggers is to introduce a volatile line of text into the service unit. From there our activation script will notice that the old service and the new service aren't identical (because that one line has changed) and then restart the service.
This means your change will prevent the service from restarting when the value becomes static (/etc/nginx/...).
What is the issue you're running into?

Oh :facepalm:
I was under the impression that RestartTriggers was a systemd feature, watching those paths. It would have been better to name them NixOSRestartTriggers...
Thanks for explaining


RefExp build fails due to missing processed_dir flag

RefExp processing step in README.md fails with missing FLAG.processed_dir error.
I was able to work around the error by providing a default value of 'processed` in the following source file.
https://github.com/google-research/pix2struct/blob/08eb4ca7cf5f5bfac2e49f92b719f7262d15d0ff/pix2struct/preprocessing/convert_refexp.py#L40

Thanks! This has been fixed in 37413e3.