Support regex for ServiceRole spec.rules.paths

(This is used to request new product features, please visit https://discuss.istio.io for questions on using Istio)
Describe the feature request
Support regex paths for ServiceRole spec.rules.paths, similar to how the Policy supports regex for spec.peers.jwt.trigger_rules.excluded_paths
Describe alternatives you've considered
Paths currently support wildcard patching for suffix, prefix or exact match, but not a mix of these. I tried using wildcard at beginning and end but this did not work. Without regex support, I have had to define several variations for allowing access to the swagger-ui.html. For example, I have added the following:
apiVersion: rbac.istio.io/v1alpha1
kind: ServiceRole
metadata:
  name: view-swagger
  namespace: dp
spec:
  rules:
  - services: ["*"]
    paths:
    - "*/swagger-ui.html"
    - "*/api-docs"
    - "*/swagger-resources"
    - "*/swagger-resources/configuration/ui"
    - "*/swagger-resources/configuration/security"
    - "*/springfox-swagger-ui/fonts/open-sans-v15-latin-regular.woff2"
    - "*/springfox-swagger-ui/fonts/open-sans-v15-latin-700.woff2"
    - "*/springfox-swagger-ui/fonts/source-code-pro-v7-latin-300.woff2"
    - "*/springfox-swagger-ui/fonts/titillium-web-v6-latin-700.woff2"
    - "*/springfox-swagger-ui/springfox.js?v=2.9.2"
    - "*/springfox-swagger-ui/swagger-ui-bundle.js?v=2.9.2"
    - "*/springfox-swagger-ui/swagger-ui-standalone-preset.js?v=2.9.2"
    - "*/springfox-swagger-ui/springfox.css?v=2.9.2"
    - "*/springfox-swagger-ui/swagger-ui.css?v=2.9.2"
    - "*/springfox-swagger-ui/favicon-32x32.png?v=2.9.2"
    - "*/springfox-swagger-ui/favicon-16x16.png?v=2.9.2"

I would like to simplify this with a regex, such as:
apiVersion: rbac.istio.io/v1alpha1
kind: ServiceRole
metadata:
  name: view-swagger
  namespace: dp
spec:
  rules:
  - services: ["*"]
    regex_paths:
    - \/.*swagger.*
    - \/.*api-docs

Affected product area (please put an X in all that apply)
[ ] Configuration Infrastructure
[ ] Docs
[ ] Installation
[ ] Networking
[ ] Performance and Scalability
[ ] Policies and Telemetry
[X] Security
[ ] Test and Release
[ ] User Experience
[ ] Developer Infrastructure
Additional context

Instead of introducing a new key (regex_paths) I think it would be nice to add some consistency to the apis and use StringMatch like in VirtualService and Gateway.
ie:
paths:
- exact: /v1
- regex: "\/.*/docs\/.*"
- prefix: /v2

This feature will be very useful to define the authz policy, without this feature the only way that I can image is to use the Mixer Policy with OPA (it is powerful but seems not a recommend way), so I suggest AuthorizationPolicy to support another header matcher mode (istio/pilot/pkg/security/authz/model/matcher/header.go):

/exact: for exact string mach
*/suffix: for suffix string match
prefix/*: for prefix string match
*: for non-empty string match
|^/regex/.*$|: for regex string match

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: httpbin-1
  namespace: foo

spec:
  selector:
    matchLabels:
      app: httpbin
      version: v1
  rules:
    - from:
        - source:
            principals: ["principal", "principal-prefix-*", "*-suffix-principal", "*"]
            requestPrincipals: ["requestPrincipals", "requestPrincipals-prefix-*", "*-suffix-requestPrincipals", "*"]
            namespaces: ["ns", "ns-prefix-*", "*-ns-suffix", "*"]
            ipBlocks: ["<IP_ADDRESS>", "<IP_ADDRESS>/16"]
      to:
        - operation:
            methods: ["method", "method-prefix-*", "*-suffix-method", "*"]
            hosts: ["exact.com", "*.suffix.com", "prefix.*", "*"]
            ports: ["80", "90"]
            paths: ["/exact", "/prefix/*", "*/suffix", "*", "|^/regex/.*$|"]

This becomes important in Istio 1.5 now that the alpha Authentication Policy is being replaced with the Request Authentication and Peer Authentication. There is no other way to exclude paths then to use an Authorization Policy which does not allow regex.

Hmm indeed this seems a feature regression... I confirmed we don't have regex in the beta API (both req/authz). @yangminzhu you must know more on this. We do not include regex in the authz api is that for a specific reason or due to our negligence?

yes, we dropped the regex support in the beta RequestAuthentication and didn't add it in the AuthorizationPolicy as we're not sure how many users will actually need the regex and what's the API should be.

Instead of introducing a new key (regex_paths) I think it would be nice to add some consistency to the apis and use StringMatch like in VirtualService and Gateway.
ie:

paths:

exact: /v1
regex: "/./docs/."
prefix: /v2

@jpatters thanks for the suggestion, we ever considered this a little bit but @liminw has some concerns that this will make the policy quite redudant.

/exact: for exact string mach
/suffix: for suffix string match
prefix/: for prefix string match
: for non-empty string match
|^/regex/.$|: for regex string match

@edgel this seems a more easier and incremental way to support the regex, but we need to think about the detail syntax.
@diemtvu @liminw It looks like many users are actually wanting the regex match in authZ policy, could you share some thoughts here, maybe we could support it like this: paths: ["/exact", "/prefix*", "*-suffix", "*", "regex(...)"]?

We usually don't make a feature request as a P0. Previsouly this was an experimental feature and we don't expect users to use it in production.

+1
Knative on Istio have to use triggerRules.excludedPaths.{exact,prefix} for authentication policy as knative service gets health checking and metrics collection from external(knative system pods). So this feature is really necessary.
Cloud Run's solution also suggested it here for now.

use triggerRules.excludedPaths.{exact,prefix} for authentication policy

new authorization policy has not_paths since 1.5.

We usually don't make a feature request as a P0. Previsouly this was an experimental feature and we don't expect users to use it in production.

@myidpt
What is the recommended solution for the following REST pattern of sub-resources?
Suppose I build a CRUD REST service for Countries. Each country has a sub-resource City. Following REST convention, I believe this means paths like
/countries
/countries/{country id}
/countries/{country id}/cities
/countries/{country id}/cities/{city id}
I have a rule to ALLOW requests to /countries/MyCountry* if request.auth.claims["countries"] contains "MyCountry".
Some users who are authorized for /countries/{any country} are NOT authorized to POST cities (they are read-only users). My natural thought is to create a rule to DENY POST for /countries/*/cities/* when request.auth.claims["readonly"] is true.
But without regex support I cannot see how to enable what I assumed was a very common situation for REST services.
I am not an expert REST developer but I had thought this was an extremely common pattern--can you help me understand why this pattern is uncommon (what are the better patterns for subresources?), or what led to the conclusion that users would not use this regex support for this purpose in production?

I am not an expert REST developer but I had thought this was an extremely common pattern--can you help me understand why this pattern is uncommon (what are the better patterns for subresources?), or what led to the conclusion that users would not use this regex support for this purpose in production?

@lgarrett-isp
Can't speak for everyone, but it's definitely the same issue for us. We've followed what we believe is the correct REST convention, and find ourselves unable to express this within the policy. We're trying to replace our custom Envoy-based sidecar with a full Istio implementation, but the lack of this support means we'll likely end up with some kind of hybrid, which is unfortunate. We definitely need this for Production use-cases.

Yep, we have run head-first into the same; we are moving away from Istio for our REST services until it has more support for basic REST conventions.

@yangminzhu is this solved by https://github.com/istio/istio/issues/27984?

@yangminzhu is this solved by #27984?

yes, but we're evaluating if glob matching would be good enough for most use cases.

@wereeder  @jpatters  @edgel  @nak3  @lgarrett-isp  @DanSalt @ajit-hybris  @aguromano @ajitchahal  @mcieplak @rolandkool
I'm wondering would the glob matching good enough for your use cases? It looks like most examples (e.g. \/.*swagger.* or /countries/*/cities/*) posted here can be supported by glob matching.  I feel there should be some use cases that requires the full regex but not sure detail examples, do you have any examples for this? Or you think the glob matching is indeed good enough? Thanks

@yangminzhu  For My header is be like x-auth-request-groups : 'CN=EMSUDEMY,OU=Groups,O=cco.xxx.com, CN=all-xxxx-people,OU=xxxx Groups,O=cco.xxxx.com, CN=xxxxxxxxx,OU=xxxx Groups,O=cco.xxxx.com'
now I would like match all-xxxx-people.
Glob matching should be fine for my usecase.

there seems a discussion about this in the community concerning about the security risk @yangminzhu do you have any updates for this regex supporting?

there seems a discussion about this in the community concerning about the security risk @yangminzhu do you have any updates for this regex supporting?

Is there any update for this issue? Will you support glob matching?

Is there any update for this issue? Will you support glob matching?

+1

+1

Hey guys, I'm running Istio 1.9.0.
I tried to implement the countries/cities example:

Allow POST to /v1/countries/{countries_id}
Deny POST to /v1/countries/{countries_id}/cities/{city_id}

  action: ALLOW
  rules:
      to:
        - operation:
            methods:
              - POST
            paths:
              - /v1/countries/*
            notPaths:
              - /v1/countries/*/cities/*

I can not make the example work as expected. I could find this:
curl -X POST http://iam.consumer--account/v1/countries/baz/cities/foo: the request hits my service (NOT the behavior I was expecting)
curl -X POST http://iam.consumer--account/v1/countries/*/cities/foo: the request is blocked by Envoy. It seems the "wildcard" is only accepted at the end.
IMHO The issue should remain open... It is not possible to implement "REST" policy in this way :(

Hey guys, I'm running Istio 1.9.0.
I tried to implement the countries/cities example:

Allow POST to /v1/countries/{countries_id}
Deny POST to /v1/countries/{countries_id}/cities/{city_id}

  action: ALLOW
  rules:
      to:
        - operation:
            methods:
              - POST
            paths:
              - /v1/countries/*
            notPaths:
              - /v1/countries/*/cities/*

I can not make the example work as expected. I could find this:
curl -X POST http://iam.consumer--account/v1/countries/baz/cities/foo: the request hits my service (NOT the behavior I was expecting)
curl -X POST http://iam.consumer--account/v1/countries/*/cities/foo: the request is blocked by Envoy. It seems the "wildcard" is only accepted at the end.
IMHO The issue should remain open... It is not possible to implement "REST" policy in this way :(
Is it possible to allow writing a condition like safe_regex of envoy?

Actually it is possible to write regex based path matching in envoy. We can write regex path matching as below in envoy:

Under the hood Istio uses almost the same configuration, all wildcard matchings uses regex under the hood: https://github.com/istio/istio/blob/master/pilot/pkg/security/authz/matcher/string.go#L29
It is very simple to support regex in AuthorizationPolicy. We can specify path matching regex as a field of custom resource or we can give path with prefix like "regex: /some/path/*/".
I can create a pr for that if Istio maintainers consider to support it.

I've run into this problem while migrating from Istio on GKE (1.4.10) to 1.9.1.  In my case, the application required JWT auth on /v1beta1/forms/* except for a few "custom methods", e.g. /v1beta1/forms/*:submit.
In this case, /v1beta1/forms/*:submit is a subset of /v1beta1/forms/*, so glob matching isn't ideal.  Personally I like to be explicit and I think regex is needed for that.
I like the proposal raised by @edgel as it doesn't require changing the API like using StringMatch would.
With regards to the format of the string, some thoughts:

I assume something as suggested like |regex| or regex: regex would be very unlikely to break existing rules.
Because wildcards can currently only be used at the start or end of strings, * could possibly be used to signify a matcher mode, give room for extensibility and not cause backwards compatibility problems. For example: r* prefix for regex (r*^/my/.*/regex$) or g* prefix for glob (g*/my/*/glob).

+1 bump
It would be good if we implement regex!

Could this be reopened? I still see the value of this feature and would like to use it. Thanks!

reopened the issue for more discussions and also unassigned myself as I'm not actively working on this.

@yangminzhu Hi, I am volunteer to implement this feature, we really need it on production, can you assign it to me? Also we can work with volunteers who wants to be pair.

@mstrYoda sorry for the late reply, just assigned the issue to you, thanks for helping on this!

Hello,
We are currently blocked by this issue as we have the need to match header values using regex.
@mstrYoda Is there any progress on this? Is there any way we can help solving this issue?
Also there seems to be another issue regarding the same subject [#25021], which one is the main issue that tracks the progress? Maybe we can close one of them as duplicate (cc @yangminzhu).
Thanks

@johnbuluba Thank you for reaching me, I will create a pr for this soon, we heavily need this in production too :)

@mstrYoda thanks for the help.  Just want to let you know we tried to solve this before but there are some difficulties that we do not have good solutions, you might need to think about these (or write a short proposal) before sending the actual PR:

it's hard to support this without changing the API, technically we could introduce special syntax to represent the regex in the existing field but we want to avoid that as it is not backward compatible and generally a bad user experience in reusing the same field for different purposes.

some general concern about the regex's security and usability, most users probably only need wildcard matching.

@mstrYoda thanks for the help. Just want to let you know we tried to solve this before but there are some difficulties that we do not have good solutions, you might need to think about these (or write a short proposal) before sending the actual PR:

it's hard to support this without changing the API, technically we could introduce special syntax to represent the regex in the existing field but we want to avoid that as it is not backward compatible and generally a bad user experience in reusing the same field for different purposes.
some general concern about the regex's security and usability, most users probably only need wildcard matching.

Hi @yangminzhu actually I just thinking to support it with same field by "regex:" prefix but like I said, it might bad user experience. I agree with u, probably supporting only wildcard matching is what actually needed here (to support child resource paths for restful apis).

Please add wildcard matching within the string, to augment the existing support for prefix/suffix matching. We just need to be able to handle routes like /order/*/details. I know there are a lot of requests for regular expressions, which would be nice, but please don't let that stop us from having basic wildcard support to Authorization Policy Rules.

@johnbuluba @magoon @ognjen-it Hi guys I've made the development for wildcard matching. I am going to build Istio locally and test the functionality and create the pr 🙏

To share our use-case (on AuthorizationPolicy conditions)
We're using oauth2-proxy with external authentication, which provides a comma-separated list of groups in the X-Auth-Request-Groups header
With only prefix & suffix matching, we can't specify a condition of "I need a user to have this group", and we need this.
Regex matching (as provided for in istio/api#2173) would solve this for us :)

I'd be happy to avoid regex, if istio could support a way of matching elements of comma-separated headers (RFC2616)
Though I would note (for our case at least), this is a header that is guaranteed to be present by the authenticating proxy, so it's from a trusted source. (And the input data is from our own SSO system, which is also trusted). So this isn't a value controllable by an attacker.

Any input this issue. Is there a way to handle regex for path variable manipulation.
Please advise

Also have a use case for wanting regex/wildcards inside path definitions:
/path/to/something/<id>
/path/to/something/<id>/sub/thing
/path/to/something/<id>/sensitive/thing

Which can be mitigated right now by using notPaths with a suffix, but it's quite messy and unintuitive, and runs the risk of blocking access to paths that accidentally match with the notPaths suffix rule.
As for implementation desire: Just full-blown regex would be nice as it'd mean it's not another pseudo-regex specification that I need to learn as a developer.

Is the regex matching support via https://github.com/istio/api/pull/2173 still under consideration? This would have really helped us too!

Anyone can make comment on my last question on that review?

/remove-lifecycle stale

Can we please have support for path parameter rewrites in istio? The fix to support this has been available for so long and all that's needed is a merge.

:-(

It's been 3 years with no progress... and the last comment from istio was: "Regex matching a complex seems ripe for a bypass."
:,(

It looks like lots of users need that functionality (also we need that in production too), so why not move forward on my pr: https://github.com/istio/istio/pull/35641/ ?
Is there any Istio Security team member here? If anyone knows, can mention them here?

@mstrYoda we also need this, and I can contribute, I had another PR for solving this, though that is only API change, i'm still pending istiod changes.
I can help you making a document to express the use case and changes necessary, also attendingo to a security meeting to help push this.

@mstrYoda we also need this, and I can contribute, I had another PR for solving this, though that is only API change, i'm still pending istiod changes.
I can help you making a document to express the use case and changes necessary, also attendingo to a security meeting to help push this.

Of course that will be nice to collaborate 🙏

I would encourage us to look into whether regex specifically is needed, or blog/pattern matching. Regex has a huge surface area. If all of the use cases are for APIs like /customer/{id}/blah, then something matching that form may make more sense

I would encourage us to look into whether regex specifically is needed, or blog/pattern matching. Regex has a huge surface area. If all of the use cases are for APIs like /customer/{id}/blah, then something matching that form may make more sense

The use case that is most needed is as described above... If something other than "regex" for matching makes more sense, than I'm sure that would make everyone here very happy.

I also need support for /customer/{id}/blah and may be unable to use AuthorizationPolicy if this is not supported.

I think most use cases should be covered by patterns /customer/{id}/blah but since we allow regex in virtual service routing, it makes sense to provide the same type of matching in AuthorizationPolicy.

I'm guessing something less heavy than regexes will do the trick for most people here.  The /customer/{id}/blah suggestion would be adequate in my own case.  This issue seems like a big one that is worth prioritizing, as routes with ids in the middle are pretty common.  I'm now looking at a case where something like POST /tenants/{id}/application_forms/guest needs to be allowed through without authorization.  Not sure what I'm going to do here.

I think a suitable workaround in my case is to modify the external authorization service to return "authorized" for routes matching the path with the embedded id.

Last comments from this ticket and closed https://github.com/istio/istio/issues/25021 are about having a strong community demand
=> has there been any update on this ?

This is not implemented due to lack of demand, but due to a tentative decision to avoid regex in authz where possible due to security, complexity, and performance concerns. @aryan16 has been writing up a design for an alternative using globbing (eg /customer/{id}/blah) and should attach the design doc here once its ready.

Note that this doesn't just come up with path processing, but also when matching on things like the XFCC header and want to check for some element out of the middle (say, a SAN) while not having to change your auth policy every time the cert rotates. We don't need full regex for that either, but we at least need unanchored matches (i.e. *foo*) and not a solution that only works for paths.

+1

+1

This is not implemented due to lack of demand, but due to a tentative decision to avoid regex in authz where possible due to security, complexity, and performance concerns. @aryan16 has been writing up a design for an alternative using globbing (eg /customer/{id}/blah) and should attach the design doc here once its ready.

We are facing the same issue, glob style matching would do the trick. Would love to see this implemented. Was there any progress on the globbing-based design?

@aryan16 is there any update regarding design documentation for the glob style matching in the AuthorizationPolicy?
Seems like that is a highly demanding feature.

@howardjohn and/or @aryan16 any word on that design that was mentioned back in March? The lack of unanchored matches essentially makes XFCC support useless in Authorization Policies. Would a PR adding support for matches "contains" matches (i.e. *FOO*) be acceptable in the mean time if I were to write one?

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1. We'd really appreciate this feature

Here's the user case:
we have such URLs:

/user/{:id}/hobby
/user/{:id}/profile
...
we want most of the requests should be Authzed except for  /user/{:id}/hobby. Without regexp, we cannot achieve this goal! The only way is to implement this logic in authz pod, but I don't like that anyway. because if you do that, all the functions in AuthzPolicy.rule can be done in authz pod as well.

+1

Without some form of dynamic matching this feature is usable in only the simplest of cases (for all the reasons given above)

+1

@aryan16 @howardjohn Hey. We are migrating from our in-house service-mesh to Istio. And I have some data for you. We have around 1,800 services of which almost 1,200 use the equivalent of AuthorizationPolicy.
From 1,200 services over 300 use regexps. Our service-mesh only supports regexps for path matching, and at this moment there is over 1,600 such rules.
I analyzed all usage of regexps, but of course this are only estimations, because it would take a lot of work to fully analyze all policies.
200 can be migrated to exact match. I don't know why people use regexp match at all :upside_down_face:.
100 can be easily migrated to prefix match.
Another 400 maybe can be migrated to prefix match. This group mostly uses constructs like /some/path/[^/]+ or /some/path/[^/]+/[^/]. But to be sure, I would have to perform full analyze of all policies for each service separately.
Next 900 I will call "restful API". They contain some kind of identifier inside of path, so it looks like /some/path/[^/]+/rest/of/the/path. Sometimes it has more than one identifier in path /some/[^/]+/path/[^/]/again.
Lastly there are a few which can be migrated to suffixMatch.
Additionally, in all the above groups some users restrict characters to some subset e.g. UUID characters or digits. But for me, it is over-engineering, and it could simplify to [^/]+.
Last but not least, when you think that you know how to use regexps and even your teammate can't spot a mistake
/some/path*
/some/path/{orderId}/again
/some/path/[^.].+

In summary, I think for our use case it would be enough to support glob matching. The best implementation for us would be, if /some/*/path would match to /some/identifier/path, but not to /some/super/long/path, so it would behave similar to current [^/]+. It would easily cover "restful API" cases and rest which can not migrate to prefix match.
I hope this helps you make your decision. If you give the green light, we can implement it. Because it's a waste of our and your time if it never gets merged

I am 100% on board with a glob based implementation. The user facing implementation would be either /path/{something}/bar (where 'something' has no meaning other than documentation to the user) or /path/*/bar. In either case, these would not match /path/a/b/bar (only a single fragment would be matched).
The gap is a safe way to do this. I have opened https://github.com/envoyproxy/envoy/issues/30724 to this end. This might not require envoy changes if the regex approach is deemed secure.
If we can resolve the Envoy issue I think this is very likely to move forward. I cannot speak for the whole community but I believe ^ will address any open concerns based on passed conversations

Can you use an extension to categorize your API calls and emit API attribute that is then consumed by RBAC? I think that was the intention behind https://github.com/istio-ecosystem/wasm-extensions/tree/master/extensions/attributegen since multiples regexes during matching is generally problematic.

Can you use an extension to categorize your API calls and emit API attribute that is then consumed by RBAC? I think that was the intention behind https://github.com/istio-ecosystem/wasm-extensions/tree/master/extensions/attributegen since multiples regexes during matching is generally problematic.

attributegen is relying on regex which, IMO, has the same problems that need to be addressed by https://github.com/envoyproxy/envoy/issues/30724.
Either way, I think its important we solve this as a first class API without hoops. This is the top 2 demanded open issue (by thumbs up) and has been a constant request.

There's no need to use regex, you can port https://www.envoyproxy.io/docs/envoy/latest/api-v3/extensions/path/match/uri_template/v3/uri_template_match.proto#extensions-path-match-uri-template-v3-uritemplatematchconfig to wasm, or just expose a "path classifier" filter from that. The important thing is that URL wildcards are not standardized, so we should not be dictating it in our APIs. It requires some extensibility.

Can we just expose https://www.envoyproxy.io/docs/envoy/latest/api-v3/extensions/path/match/uri_template/v3/uri_template_match.proto#extensions-path-match-uri-template-v3-uritemplatematchconfig as a matcher in RBAC? That would, IMO, perfectly solve the issue

I think that option looks great; in my org have multiple teams using Cloud Endpoints for auth who are reluctant to move to Istio AuthorizationPolicy because they have rules using those "REST-style" paths that can't be expressed with the current prefix/suffix matching.

Hello!
Is there something we can do to move this forward? Kind regards

Can we just expose https://www.envoyproxy.io/docs/envoy/latest/api-v3/extensions/path/match/uri_template/v3/uri_template_match.proto#extensions-path-match-uri-template-v3-uritemplatematchconfig as a matcher in RBAC? That would, IMO, perfectly solve the issue

Hi @howardjohn it looks like the exact solution. How would you think to proceed, as a bacward compatible with the existing CRDs? Or creating a new version that takes type in new field?
I would like to work on this one as we still need it a lot in production 🙏

Can we just expose https://www.envoyproxy.io/docs/envoy/latest/api-v3/extensions/path/match/uri_template/v3/uri_template_match.proto#extensions-path-match-uri-template-v3-uritemplatematchconfig as a matcher in RBAC? That would, IMO, perfectly solve the issue

Hi @howardjohn it looks like the exact solution. How would you think to proceed, as a bacward compatible with the existing CRDs? Or creating a new version that takes type in new field?
I would like to work on this one as we still need it a lot in production 🙏

I would imagine the same field just allows some new syntax. not sure if that is a/*/b or a/{segment}/b, etc though

Can we just expose https://www.envoyproxy.io/docs/envoy/latest/api-v3/extensions/path/match/uri_template/v3/uri_template_match.proto#extensions-path-match-uri-template-v3-uritemplatematchconfig as a matcher in RBAC? That would, IMO, perfectly solve the issue

Hi @howardjohn it looks like the exact solution. How would you think to proceed, as a bacward compatible with the existing CRDs? Or creating a new version that takes type in new field?

I would like to work on this one as we still need it a lot in production 🙏

I would imagine the same field just allows some new syntax. not sure if that is a/*/b or a/{segment}/b, etc though

So wdyt about if I modify this pr to use UriTemplateMatchConfig (instead of regex matcher) according to Envoy doc that you sent?
Pr: https://github.com/istio/istio/pull/35641

Not sure if this fits here, but regex Matching for Headers is also something I would appreciate. If more souphisticated rule matchig is allowed in AuthorizationPolicies this might help. Maybe the Api of the VirtualService could be reused? (Exact, Prefix, Regex).

is there support for "#" in the paths? I have made a couple of tests, but it does not seem to work. Any help?

is there support for "#" in the paths? I have made a couple of tests, but it does not seem to work. Any help?

Please do not comment irrelevant comments on busy issues like this; use https://github.com/istio/istio/discussions
# should not be a part of any requests that get to Envoy, per HTTP spec. These are a client side feature of URL only. So authz policy against # does not make sense. https://datatracker.ietf.org/doc/html/rfc3986#section-3.5

this is supported upstream now:
https://github.com/envoyproxy/envoy/pull/31447

Seems like we can expect it to be released in Envoy 1.30. Any idea what the target release date is for that? I'm not sure istio/api#2173 is the right API though given that upstream Envoy just added a new matcher

According to schedule planned release date of Envoy 1.30 is 16/04/2024 - Envoy Major release schedule

Well that link's going in my bookmarks :) Thanks! I think that means that Istio 1.22 can very easily include this feature. Either me or someone on my team can tackle this if @mstrYoda is ok with it? I see they're currently assigned to the issue

Well that link's going in my bookmarks :) Thanks! I think that means that Istio 1.22 can very easily include this feature. Either me or someone on my team can tackle this if @mstrYoda is ok with it? I see they're currently assigned to the issue

It is okay to me, also I would like to contribute too if there is a chance for it 👍

Hi @mstrYoda! I am excited to takle this work together! Here are my thoughts for a solution and how we can pair.
Let's leave the paths and notPaths fields in the AuthorizationPolicy resource as is for backwards compatibility. We can create new fields called pathTemplates and notPathTemplates that can be an array of paths based on uri template matching rules supported by envoy. The user can set one of paths or pathTemplates but not both. If the user wishes to set notPathTemplates they must not set paths or pathTemplates and vise versa.  The pathTemplates fields could look something like this:
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: httpbin
  namespace: foo
spec:
  action: ALLOW
  rules:
  - from:
    - source:
        principals: ["cluster.local/ns/default/sa/sleep"]
    - source:
        namespaces: ["test"]
    to:
    - operation:
        methods: ["GET"]
        pathTemplates: ["/info/*/{file}", "/info/v2/*/{file}]
    - operation:
        methods: ["POST"]
        pathTemplates: ["/data/**"]
    when:
    - key: request.auth.claims[iss]
      values: ["https://accounts.google.com"]

/info/** would match /info/foo/bar.txt or info/v2/foo/bar.txt
/data/{file} would match /data/foo/bar/test
Would you be interested in taking on the api changes? I can work on the control plane changes. Let me know your thoughts!

/data/{file} would match /data/foo/bar/test

Just checking this is a typo? :) {name} matches "one path segment up to the next path separator" according to the uri template doc.
I suppose it'd be more effort to only partially support the uri template syntax (i.e. not the named variables) than just passing it straight through to the Envoy config, but as a user I'm wondering if there'd be any value in the named variables beyond it being a kind of documentation: might the captured values get exposed somewhere for (say) use in access logs, or an EnvoyFilter, in a when condition? (If not now, perhaps in future.) And would there be any performance penalty for that over the non-capturing matchers?

Hi @mstrYoda! I am excited to takle this work together! Here are my thoughts for a solution and how we can pair.
Let's leave the paths and notPaths fields in the AuthorizationPolicy resource as is for backwards compatibility. We can create new fields called pathTemplates and notPathTemplates that can be an array of paths based on uri template matching rules supported by envoy. The user can set one of paths or pathTemplates but not both. If the user wishes to set notPathTemplates they must not set paths or pathTemplates and vise versa. The pathTemplates fields could look something like this:
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: httpbin
  namespace: foo
spec:
  action: ALLOW
  rules:
  - from:
    - source:
        principals: ["cluster.local/ns/default/sa/sleep"]
    - source:
        namespaces: ["test"]
    to:
    - operation:
        methods: ["GET"]
        pathTemplates: ["/info/*/{file}", "/info/v2/*/{file}]
    - operation:
        methods: ["POST"]
        pathTemplates: ["/data/**"]
    when:
    - key: request.auth.claims[iss]
      values: ["https://accounts.google.com"]

/info/** would match /info/foo/bar.txt or info/v2/foo/bar.txt /data/{file} would match /data/foo/bar/test
Would you be interested in taking on the api changes? I can work on the control plane changes. Let me know your thoughts!

Hi @jaellio 👋  Thanks for the collaboration. I have the same questions with the @michaelbannister 🤔
I did not work on API side before but I have some idea and experience on the control plane side. Can we pair/collaborate on both? I can make the changes on the API side and would love to see developments on the control plane too.

I am a bit worried about having multiple ways to represent path, especially when its also in 'when'. It can be pretty complex to have 4 (with 'not' variants) rules for the same thing.
I also don't think we need to support the full syntax of Envoy's URI template. The URI template is the implementation detail of our API; we should define the API we want and map it onto the URI template. Specifically, I don't see a strong need to support {name} and *. We should support only one. {} are not valid in URLs, while * is, so in theory that may be more backwards compatible. That also is more future proof if we ever want to make assertions based on the extracted values (I don't think this is supported in Envoy, but its why its in the Envoy API I assume).

/data/{file} would match /data/foo/bar/test

Just checking this is a typo? :) {name} matches "one path segment up to the next path separator" according to the uri template doc.
I suppose it'd be more effort to only partially support the uri template syntax (i.e. not the named variables) than just passing it straight through to the Envoy config, but as a user I'm wondering if there'd be any value in the named variables beyond it being a kind of documentation: might the captured values get exposed somewhere for (say) use in access logs, or an EnvoyFilter, in a when condition? (If not now, perhaps in future.) And would there be any performance penalty for that over the non-capturing matchers?

@michaelbannister Yes, apologies for the typo! I forgot to update the comment :) It should be /data/{file} would match /data/test
I think for now it would make sense to not support named variables. I had originally assumed that you could reference the variable later on in the template or as an environment variable. Primarily, the variable seems to be a source of documentation (and confusion). We could revisit adding support for named variables later on based on user feedback and increased functionality support (either by Istio or envoy). For now, we can interpret any paths containing { as invalid.

I am a bit worried about having multiple ways to represent path, especially when its also in 'when'. It can be pretty complex to have 4 (with 'not' variants) rules for the same thing.

Are paths and notPaths supported values for the the when conditional?
If we opted to support URI template matching for the existing paths and notPaths fields we would need to interpret * as a templating type and as a valid character in the path. Need to think more on this, but I could see this causing some issues.

@howardjohn Are paths and notPaths supported values for the when conditional?

Ah I guess not, my bad.
I agree * could be a valid value today so that is tricky (although, its a very weird URL). {} are explicitly not valid URL charecters so no one can legitimately have those which may be a good motivation to use them; it also is consistent if we later decide to have {name}

If we only support {} for templating we can use the existing paths and notPaths fields.
If we don't want to incorporate named variables (regardless of whether or not we do anything with them) we could support the following templating and map them to envoy's supported uri templating:

{} or {*} : Matching one path segment up to the next path separator: /.
{**} : Matching zero or more path segments. NOTE: It isn't clear from the envoy uri templating documentation if {**} must be the last operator

Alternatively, if we are interested in incorporating a named variable (but not doing anything with the variable at this time) we could support the same templating with { as described in the uri templating documentation.

We will also support the existing * functionality:

* : Matching zero or many path segments.

Isn't this "Match any character"? Its not "path aware", just equivalent to .* regex. While a {} is more like \/.+?\/ (probably that is not a robust regex, just an example that is close).

I find the named variables introduce unnecessary confusion and would opt for the former option. We can add support for named variables later if necessary.

+1. I would, similarly, not support {*} or {**}. Just {}.

Isn't this "Match any character"? Its not "path aware", just equivalent to .* regex. While a {} is more like /.+?/ (probably that is not a robust regex, just an example that is close).

I think in the UriTemplate context, * becomes path aware (which is one reason why I'm more in favor of @jaellio's original [not]pathTemplate approach).

+1. I would, similarly, not support {*} or {**}. Just {}.

I think the OP's original example would require something like {*}/springfox-swagger-ui/{**}

I would agree * is not path aware currently for Istio.
Depending on how you are defining {} I don't think it supports a complex enough set of use cases.

I think adding new fields (pathTemplates and notPathTemplates) to support more complex templating is simpler if we want to address the asks of the OP: there are less backwards combability concerns, it's more extensible, it'd easier for users to distinguish between new vs old functionality, and it doesn't feel like we are boxing ourselves into limited templating capabilities. I think our templating support should be scoped, but by choice, not by design or backwards compatibility limitations.

If we aren't in favor of adding new fields, I think we should add support for the following. I don't think {} alone covers enough use cases.

{} or {*} : Matching one path segment up to the next path separator: /.
{**} : Matching zero or more path segments. This must be the last operator.

If the path contains { or } then we will interpret translate the path as a uri template rather than as a string match.

This sounds reasonable to me. It'd be good if the corresponding Istio docs were clearer than the UriTemplate docs, though:

* : Matches a single path component, up to the next path separator: /

but then this example:

/videos/*/*/*.m4s would match videos/123414/hls/1080p5000_00001.m4s

which suggests that the . of the file extension can be a boundary of a * as well – but I suspect /videos/*/*/* would also match that same path so maybe it's flexible?
Would we want to explicitly disallow any use of { or } which doesn't match one of those specific patterns? e.g. /orders/{id} should fail validation

This sounds reasonable to me. It'd be good if the corresponding Istio docs were clearer than the UriTemplate docs, though:

* : Matches a single path component, up to the next path separator: /

but then this example:

/videos/*/*/*.m4s would match videos/123414/hls/1080p5000_00001.m4s

which suggests that the . of the file extension can be a boundary of a * as well – but I suspect /videos/*/*/* would also match that same path so maybe it's flexible?

Totally agree. This could be a lot more clear - I'll can verify this by updating the unit tests I think. I already make some updates to verify if {**} had to be the last operator. https://github.com/envoyproxy/envoy/pull/33104

Another thought: Would we want to explicitly disallow any use of { or } which doesn't match one of those specific patterns? e.g. /orders/{id} should fail validation

I think that explicitly disallowing alternative use cases might be better than an undefined outcome even if we document it as unsupported functionality.  I am not sure how complicated the conditional/regex would be, but I think it makes sense to only allow {*} and {**}. If we chose to add support for named variables in the future, we could remove the restriction on our side.
Regarding the impact of explicitly disallowing the use of { if it doesn't match a supported pattern: Previously, if a user provided a path with { or any other combination of brackets the path would technically be invalid but wouldn't result in an error. The path would instead result in no matches since { is not a valid character in a path. By explicitly disallowing unsupported patterns containing { the user will now see an error. I am not sure if this would result in the AuthorizationPolicy not being applied, but this could unintentionally cause authorization policies to not be applied if they contain unsupported paths. Not sure if this is a realistic scenario or how many users this might impact, just wanted to call it out.

Added a comment on the PR - not against adding matches, but only if we understand:

if HttpRoute can be extended to do the same
what are the security implications - if routes and authorizations are not aligned ( the API is supposed to work as a 'vendor extension' when using HttpRoute / Gateway )
backward compatibility risk - now that everything is v1, I don't think we can play games or start moving to v2.

Closing in favor of creating a new issue to track broader adoption and integration of URI templating.


Frontend: Temporarily force decl skipping with -experimental-lazy-typecheck

Until a swiftc with https://github.com/apple/swift-driver/pull/1465 is available widely, enable -experimental-skip-non-exportable-decls whenever -experimental-lazy-typecheck is specified.
Resolves rdar://117020908

@swift-ci please smoke test


OnChanged with Length

onChanged: (val) {
if (val != null && val.length == 4){
_focusAadhar1.unfocus();
FocusScope.of(context).requestFocus(_focusAadhar2);
}
}
the above code is working as expected when the value is entered for first time, however when a user need to modify/alter the data and if backspace(Delete) character key is pressed i/o deleting the character it jumps to next column.
Expected Behaviour: if backspace is pressed it must remove the character i/o firing the unfocus code.

Hi @NiranjanShah,
Unless I haven't understood your question, your expected behavior doesn't seem to match with the code written.
Because if you already have 4 characters and backspace is pressed, the if condition wouldn't hold any longer, thus unfocus wouldn't fire.

Unfortunately the if condition is firing….
Will record a video for better understanding….

On 31-Aug-2020, at 4:23 PM, Danvick Miller<EMAIL_ADDRESS>wrote:
Hi @NiranjanShah https://github.com/NiranjanShah,
Unless I haven't understood your question, your expected behavior doesn't seem to match with the code written.
Because if you already have 4 characters and backspace is pressed, the if condition wouldn't hold any longer, thus unfocus wouldn't fire.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub https://github.com/danvick/flutter_form_builder/issues/437#issuecomment-683707525, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACHCLQRE4R4JISCDZACWX5TSDN6LBANCNFSM4QMRN3GA.

The issue is resolved, testing process was wrong, no code change required


Improve support for lambdas

Something I might want to work on a bit once my exams are over. Raising an issue so y'all can provide some feedback, if you'd like (or tell me this is a terrible idea :wink: ).
Lambdas be Buggy
Currently, support for lambdas is buggy, and a great deal of programs I write which use lambdas will crash when type-checking. What's more, there are a couple of places we attempt to convert definitions to lambdas for localised use (but the code for doing this is duplicated and inconsistent).
First: Better lambdas
The first thing I propose to do, is to greatly improve the type-checking for lambdas---they are such a useful construct (and fundamental!), that writing programs without full support for them feels somewhat clunky.
Second: ... More lambdas?
The second thing I am wondering about, is whether we want to move to using lambdas more---we already have some (somewhat disparate) methods of wrangling our multi-parameter functions to lambda-form, so might it make sense to utilise these more when e.g., type checking. The underlying theory doesn't have multi-parameter lambdas (AFAIK), so it might make sense to convert to a lambda-form to bring some easier reasoning from the theory?
I know this might be a bit odd with e.g., line/column numbers (but hopefully we can preserve these anyway), but perhaps it might make sense to take e.g.,
foo : Int -> Int -> Int
foo x y = x + y

And instead of checking each equation individually, type-check the lambda-form:
(\(x : Int) => \(y : Int) => x + y) : Int -> (Int -> Int)

We can then focus more on how case/abs constructs are type-checked, rather than separately dealing with equation pattern matching (would be handled in 'case'), and functions would generally be type-checked as abs.
Could we rewrite in Happy?
Just a thought, might we even be able to perform this rewriting in Happy, whilst parsing? So in this manner, we don't need to have additional [Equation]s for Defs, but instead perhaps a Def is just a named, typed expression?
E.g.,
foo : Int
foo = 7

bar : forall {a : Type} . a -> a
bar x = x

Might be along the lines of...
foo = (7 : Int)

bar = (\(x : a) => x) : forall {a : Type} . a -> a

EOR
Ramble over, for now. Let me know if you have any thoughts.

I believe we are using equations for top level because (in the general case) doing case is complicated w.r.t. specialisation induced by GADTs. I believe we only allow a grade to be specialised by a GADT pattern match in top-level equations.
I believe Idris tries to solve this by rewriting all cases to top-level definitions (as of Edwin's last visit a few months ago).

PS: I am not happy (hehe) about your suggestion to do any rewriting in the parser! We should work towards parsing into a concrete syntax tree which reflects exactly the structure of the source file (ideally even maintaining comments and whitespace).
I am imagining a pipeline that goes something like this:
Text
|
| parse
v
CST
|
| rewrite
v
AST
|
| check
v
Elaborated AST

Hmm, yes, I agree with the rewriting in the parser—with the rewriting to the AST afterwards :)


New invite - Create invite button dead

Describe the bug
I cannot create a new invite, "Create invite" button in Add new modal (User Administration -> Invites -> Add new) doesn't work. It does nothing in all of my browsers: Firefox (v118.0.2), Chrome (118.0.5993.70), Edge (118.0.2088.46).
Reproduction

Run docker postgres-docker samuel19982/podfetch:postgres
BASIC_AUTH=true, USERNAME=aaa, PASSWORD=bbb
log in as aaa/bbb
User Administration -> Invites -> Add new
Modal opens up
Button is dead

System Info
Host:
- docker image samuel19982/podfetch:postgres
- Raspberry pi 3B
- Operating System: Debian GNU/Linux 11 (bullseye)
- Kernel: Linux 6.1.21-v8+
- Architecture: arm64

Client:
- Firefox (v118.0.2), Chrome (118.0.5993.70), Edge (118.0.2088.46)

Used Package Manager
n/a
Validations

[X] Follow our Code of Conduct
[X] Read the Contributing Guide.
[X] Check that there isn't already an issue that reports the same bug to avoid creating a duplicate.
[X] Check that this is a concrete bug. For Q&A, please open a GitHub Discussion instead.
[X] The provided reproduction is a minimal reproducible of the bug.

This is also fixed now.


Further nav-bar tightening in the vertical axis

Based on feedback I think we need to further tighten the nav bar vertically. I propose:

shrink the Boost logo further so the logo text has the same em-height as the nav text items
further reduce the empty space above and below the nav text (i.e. bring the horizontal rule up more, and re-align the items above it)
Increase the size of the avatar so the bottom reaches the horizontal rule and the top is only a couple of pixels away from the top of the page
Trim the right end of the horizontal rule to fall short of the Join / Avatar, so that the avatar has room. Like this:

And I am not sure how it will turn out but I would like to experiment with doing the same thing on the left side but with the logo image instead of the avatar:

Also if it is not computationally expensive can we try putting a 4 to 8 pixel fade under the horizontal rule? When the site is scrolled I would like the contents to fade out in opacity as it goes under the nav bar.

I tightened this up but have to create a fade still


Is there any way to encrypt a ciphertext using seal?

As the titile says.
Thanks for your time in advance!

I suggest you to start from native/examples/1_bfv_basics.cpp

Thanks!


CouchDB requests disconnecting

On some requests for a view, the connection keeps being disconnected with the following log:
2015-08-05 06:43:20 DEBUG [webapi-akka.actor.default-dispatcher-13] c.i.c.c.Client - Making a request Request(GET,http://[ip]:5984/[db]/_design/users/_view/[view]
2015-08-05 06:43:20 DEBUG [webapi-akka.actor.default-dispatcher-13] o.h.b.p.Stage - Beginning request: Request(GET,http://[ip]:5984/[db]/_design/users/_view/[view]
2015-08-05 06:43:20 DEBUG [Thread-18] o.h.b.p.Stage - Stage org.http4s.blaze.channel.nio2.ByteBufferHead sending inbound command: Disconnected
2015-08-05 06:43:20 DEBUG [Thread-18] o.h.b.p.Stage - Stage org.http4s.client.blaze.Http1ClientStage sending outbound command: Disconnect
2015-08-05 06:43:20 DEBUG [Thread-18] o.h.b.p.Stage - closeWithError(EOF)
2015-08-05 06:43:20 DEBUG [Thread-18] o.h.b.p.Stage - org.http4s.client.blaze.Http1ClientStage shutting down at Wed Aug 05 06:43:20 UTC 2015
2015-08-05 06:43:20 DEBUG [Thread-18] o.h.b.p.Stage - closeWithError(EOF)
2015-08-05 06:43:20 DEBUG [pool-1-thread-1] o.h.b.p.Stage - Beginning request: Request(GET,http://[ip]:5984/[db]/_design/users/_view/[view]
2015-08-05 06:43:20 DEBUG [Thread-18] o.h.b.p.Stage - Stage org.http4s.blaze.channel.nio2.ByteBufferHead sending inbound command: Disconnected
2015-08-05 06:43:20 DEBUG [Thread-18] o.h.b.p.Stage - Stage org.http4s.client.blaze.Http1ClientStage sending outbound command: Disconnect
2015-08-05 06:43:20 DEBUG [Thread-18] o.h.b.p.Stage - closeWithError(EOF)
2015-08-05 06:43:20 DEBUG [Thread-18] o.h.b.p.Stage - org.http4s.client.blaze.Http1ClientStage shutting down at Wed Aug 05 06:43:20 UTC 2015
2015-08-05 06:43:20 DEBUG [Thread-18] o.h.b.p.Stage - closeWithError(EOF)

The error seems to be the same as the following issue reported at the underlying http library: https://github.com/http4s/http4s/issues/349 (look at the "client log").
Any idea why this is going wrong in this library as well?

In your case it doesn't seem to be caused by a timeout, as in the linked issue. Does it always happen on a particular request? Would you be able to provide a simple example to reproduce this?

No it seems to be happening with various requests. However, it's hard to reproduce since it's very irregular (sometimes it just works, sometimes it times out).
Also, it might be relevant to say that they're requests to a Cloudant database

This is the (relevant) Scala code used for requesting views:
private lazy val couch = CouchDb(dbHost, dbPort, https = false, dbUser, dbPassword)

val db = {
  log.info(s"Using database $dbName @ $dbHost:$dbPort")
  couch.db(dbName, typeMapping)
}

protected def getView(designName: String, viewName: String) = {
  val view = db.query.view[String, A](designName, viewName).get
  val couchKeyVals = view.query
  val result = couchKeyVals.map(_.rows.map(kv => withId(kv.id, kv.value)).toList)
  result.toScalaFuture
}

@bryce-anderson sorry for disturbing, but do you have any ideas on why this problem might appear? Thanks!

Sorry for the slow reply. I can't find anything specific in those log messages. They look like a case of 'the server simply hung up'. Are there log events from the other side? I guessing like they would be buried but may be useful.
My only guess is that perhaps it has to do with using the http4s PooledClient (used here). I don't know if its possible to switch that in this case but it might be worth trying.

@beloglazov have you been able to reproduce this issue? I was not able to (running repeated concurrent requests to Cloudant and couch)

@bryce-anderson thanks a lot for taking a look!
@ermyas sorry, I haven't had a chance to try it, but I believe you :)
@offerijns do you still have this issue? Have you tried doing what @bryce-anderson suggested? Could it have been just a temporary issue of Cloudant? We could also try updating to http4s 0.8.4 and swapping the http4s client to SimpleHttp1Client as a test.

I think this is a http4s bug after all. See https://github.com/http4s/http4s/commit/8d8c66e446ec26d4c5e8a38e8388938eea1cc72b. Basically, when the client was receiving a response with the length defined by EOF, there was a race between shutting down the stage and checking that the connection shut down normally. I'm not 100% sure its your bug, but it could be. At any rate, that commit is in v0.9.3 and v0.8.6, both of on their way to central.

Sorry for the late reply, I was out of the country for a little while.
The bug you're explaining does sound like the same one I'm reporting! I'll wait for the fix to be released and try it out then—and let you know whether it works. Thanks for looking into this!

@offerijns #10 is now merged, could you please check if it fixes this issue?


AWS SSH Timeout

After running yarn sync -c config/main.json the build boots up everything in AWS. I am able to ssh into the box for a short period, but then I get an ssh timeout error when I try again. The yarn task also fails with a timeout with this as the last log message:
TASK [Wait for nodes to become reachable] **************************************
Here is my config/main.json
{
  "project": "kusama",
  "polkadotBinary": {
    "url": "https://github.com/paritytech/polkadot/releases/download/v0.8.30/polkadot",
    "checksum": "sha256:9dddd2ede827865c6e81684a138b0f282319e07f717c166b92834699f43274cd"
  },
  "nodeExporter": {
    "enabled": true,
    "binary": {
      "url": "https://github.com/prometheus/node_exporter/releases/download/v1.0.1/node_exporter-1.0.1.linux-amd64.tar.gz",
      "checksum": "sha256:3369b76cd2b0ba678b6d618deab320e565c3d93ccb5c2a0d5db51a53857768ae"
    }
  },
  "polkadotRestart": {
    "enabled": true,
    "minute": "50",
    "hour": "4,12,20"
  },
  "chain": "kusama",
  "polkadotNetworkId": "ksmcc3",
  "state": {
    "project": "kusama"
  },
"validators": {
    "telemetryUrl": "wss://telemetry-backend.w3f.community/submit",
    "additionalFlags": "--unsafe-pruning --pruning 1000 --execution=native",
    "dbSnapshot": {
      "url": "https://ksm-rocksdb.polkashots.io/kusama-7595617.RocksDb.7z",
      "checksum": "sha256:6159d3e3790f00455cd3dcc9c8238e7af07762d1a0d9956d9f407d5d22db0784"
    },
    "loggingFilter": "sync=trace,afg=trace,babe=debug",
    "nodes": [
      {
        "provider": "aws",
        "machineType": "t2.large",
        "count": 1,
        "location": "us-east-1",
        "zone": "us-east-1a",
        "projectId": "kusama-315119",
        "nodeName": "node-man",
        "sshUser": "admin",
        "image": "ami-09e67e426f25ce0d7"
      }
    ]
}

yarn clean will update the tfstate in Gcloud, but it does not tear down the infra in AWS.
Has anyone come across this? Is there something wrong with my config?

Ok, figured it out. The two ssh keys MUST be added to ssh-add. Ansible requires this. I will add a PR with a clear note in the README


renamed test methods for mqueue and added mq_unlink

another function added for posix message queues.
the rest will follow soon.

Currently a strange error with the nightly build:
Compiling nix-test v0.0.1 (file:///Users/travis/build/carllerche/nix-rust)
Build failed, waiting for other jobs to finish...
error: internal compiler error: unexpected panic
note: the compiler unexpectedly panicked. this is a bug.
note: we would appreciate a bug report: https://github.com/rust-lang/rust/blob/master/CONTRIBUTING.md#bug-reports
note: run with RUST_BACKTRACE=1 for a backtrace
thread 'rustc' panicked at 'assertion failed: (left == right) (left: '&', right: ']')', ../src/librustc/metadata/tydecode.rs:567
Could not compile rand.
To learn more, run the command again with --verbose.
The command "curl -sSL https://raw.githubusercontent.com/carllerche/travis-rust-matrix/master/test | RUST_TEST_THREADS=1 bash" exited with 1.
4.00s$ cargo doc --no-deps
Compiling libc v0.1.8
Compiling bitflags v0.1.1
Compiling nix v0.3.9 (file:///Users/travis/build/carllerche/nix-rust)
The command "cargo doc --no-deps" exited with 0.
it says "this is a bug."
strange. maybe temporary

Has anybody seen similar errors? I cannot reproduce this. Sometimes it builds, sometimes the compiler seems to crash but it doesn't seem to be related to the mq code.

There have been some intermittent failures. I haven't done much work trying to track them down. I will try to look into it a bit tonight.

It looks like both rand and rust-nightly are slightly out of data. Maybe this is fixed with the latest versions.
On the other hand it says that it's a compiler bug. No activity on the ticket I opened so far.

I'm trying a rebuild.

Looks like the build passes now.

Thanks! Merged: bd265fd8f47142e565294258abb95223f195e96d

Thanks for merging. Will be adding the missing functions soon.


Tests log OSErrors on Windows

The AppVeyor builds for Python 3 log errors like:
OSError: [WinError 10038] An operation was attempted on something that is not a socket

... however, the tests pass. I haven't investigated at all, it's probably just an issue in the test cleanup sequence, but it merits further study.

Hi, Has the problem been resolved? Find in mockupdb_init_.py in bind_domain_socket function on 1740 line.
sock = socket.socket(socket.AF_UNIX)
Does this mean not to use the package for windows?
When I do server.stop(), recieve error:
OSError: [WinError 10038] An operation was attempted on something that is not a socket
Windows 10, python 3.8, mockupdb 1.7.0

To my knowledge the problem has not been resolved.
Do you get a traceback when you see that error? Does your program crash? Or is it written to stderr without a traceback and your program exits normally?

This is written to stderr with no trace and your program exits normally.

Here's an example:
$ python setup.py test -s tests.test_mockupdb.TestMockupDB.test_default_wire_version
running test
WARNING: Testing via this command is deprecated and will be removed in a future version. Users looking for a generic test entry point
 independent of test runner are encouraged to use tox.
running egg_info
writing mockupdb.egg-info\PKG-INFO
writing dependency_links to mockupdb.egg-info\dependency_links.txt
writing requirements to mockupdb.egg-info\requires.txt
writing top-level names to mockupdb.egg-info\top_level.txt
reading manifest file 'mockupdb.egg-info\SOURCES.txt'
reading manifest template 'MANIFEST.in'
warning: no previously-included files matching '__pycache__' found under directory '*'
writing manifest file 'mockupdb.egg-info\SOURCES.txt'
running build_ext
test_default_wire_version (tests.test_mockupdb.TestMockupDB) ... Exception in thread Thread-1:
Traceback (most recent call last):
  File "C:\python\Python36\Lib\threading.py", line 916, in _bootstrap_inner
    self.run()
  File "C:\python\Python36\Lib\threading.py", line 864, in run
    self._target(*self._args, **self._kwargs)
  File "c:\cygwin\home\administrator\mongo-mockup-db\mockupdb\__init__.py", line 1647, in _accept_loop
    client, client_addr = self._listening_sock.accept()
  File "C:\python\Python36\Lib\socket.py", line 205, in accept
    fd, addr = self._accept()
OSError: [WinError 10038] An operation was attempted on something that is not a socket

ok

----------------------------------------------------------------------
Ran 1 test in 0.016s

OK


Allow explicit summation ranges

∑_(k=1)^m x_k

where
x ∈ ℝ^m

Doesn't currently compile. Should it?
The message is also not helpful Compile error!
If I change it to implicit summation ranges
∑_k x_k

where
x ∈ ℝ^m

then it works.
Do we support explicit summation ranges? If not, I think we should. For example, I don't believe we have anyway to write something like (without convoluted sparse matrix constructions):
(∑_(j=1)^5 x_j ) / (∑_(k=6)^m x_k )

where
x ∈ ℝ^m

If we want to support this, then I think a good enhancement proposal would include something about optionally generating runtime asserts for bounds checking.

∑_(j=1)^5 is not added, this works (LaTex output is incorrect)
(∑_(j for j >=1 and j <=5) x_j ) / (∑_(k for k==6) x_k )
where
x ∈ ℝ^m

Ah, good point. That's not too bad. I guess it wouldn't hurt to add ∑_(j=1)^5 even if it was just a shorthand which expanded to that for now.


lookupSymbol fails to find library when .dll extension is explicitly given

Consider the following code:
import Std.Foreign

def main:
    lookupSymbol "libmongoc-1.0.dll" "mongoc_init"

I have libmongoc-1.0.dll present under PATH.
It fails with the following output:
Running main...
Luna encountered runtime error: Native library libmongoc-1.0.dll could not be loaded. Details:

loading "liblibmongoc-1.0.dll.dll" failed with: LoadLibrary: invalid argument (Nie można odnaleźć określonego modułu.)
loading "libmongoc-1.0.dll.dll" failed with: LoadLibrary: invalid argument (Nie można odnaleźć określonego modułu.)
loading "native_libs\windows\liblibmongoc-1.0.dll.dll" failed with: LoadLibrary: invalid argument (Nie można odnaleźć określonego modułu.)
loading "native_libs\windows\libmongoc-1.0.dll.dll" failed with: LoadLibrary: invalid argument (Nie można odnaleźć określonego modułu.)

It seems that .dll extension is appended even if explicitly specified and the library cannot be found. If I remove the extension and look just for libmongoc-1.0 everything is fine.
The issue isn't serious but it surprised me, as I expected function to have similar behavior as WinAPI's LoadLibrary (that is conventionally called with full filename).

@mwu-tow does it work with the new Luna build?

Yes, I just confirmed that issue is fixed. Thanks!


core: use qualname in beta message

lgtm, would add to deprecated

Was added to deprecated in #20578 also


A "don't move" option (Guard?)

An option to ask the mercenary to "Guard" his spot and stay right there and never walk.
(Because with the "Wait" action, they still move around...)

Or the option to "Guard" an object, and always go back to it.

Hello, thanks for opening the issue. It's actually a bug that they do that because they're supposed to stay completely in place while waiting and always return to the exact spot they're waiting at. I'll have it fixed at some point

So the "Wait" action is supposed to have them stay completely in place? Cool!
I hope the bug won't be difficult to fix.

Just adding my own interest in getting this resolved. Its one of the very few complaints I have


Added support for spec files to eslint-config-jest-enzyme to match Jest.

Here is my pull request to support eslint checking .spec.js in both normal project folders & the tests folder. This matches issue #232 that I submitted.

Thanks @Jamamuuga !


v1.0.17: 'Stream error on track' loggings

Hi
I see these errors in my log which don't seem to impact playback (casting to a CC group continues fine):
Logger: music_assistant.mass.stream
Source: /usr/local/lib/python3.9/site-packages/music_assistant/controllers/stream.py:501
First occurred: 10:21:48 (21 occurrences)
Last logged: 10:47:13

Stream error on track 2a2dcc16-8baf-4b3a-ae99-c9373fee95db
Stream error on track 0736e58c-c6c9-4795-8571-347ebd6573d7
Stream error on track 07c36d42-93fc-44fb-88ad-bbdacd2716d2
Stream error on track 070b33e5-af22-456e-92da-18ae117a88ea
Stream error on track 9b3b0b5e-ed5e-4063-a6c7-1b405ad97ad9

That is correct. It means the queue streamer skipped a track it was not available or network hiccup etc.
Reminder to myself: Make this error a bit more friendly and hide it to debug

Have a look at your spotify playlist you was playing, good chance there are some tracks in there not available.

This error happens if the queue streamer was not able to fetch the audio stream in time or did not get a response in time from the music provider. As this is all realtime (PCM) audio streaming this might happen if there's a small hiccup etc. I did not implement any retries yet so that can be improved. At the moment it just skips over the track and picks the next one.
So this error can happen if the track is not available due to network issue or its not available on the provider at all.
The ID is indeed an internal ID. The error is now logged just for me as indication how often this happens.
You're saying it happened 142 times in 60 tracks so that feels a bit too much.
When I'm going to implement the seeking I need to make adjustments to this part of the code (the actual chunk retrieval of provider) and I will make this more robust. I assume you did not notice any audio hiccups ?

No the music plays fine, and according the 4+ hours playing, no noticeable amount of tracks where skipped (playlist is 4.40h in total)

Hi
I just verified these two tracks that where mentioned in de detailed HA log :
sox FAIL formats: can't open input file `spotify://track/4WE6YQ6kyf4VWUjrb5cBs0': No such file or directory
2022-05-12 14:48:01 ERROR (MainThread) [music_assistant.mass.stream] Stream error on track ca6667fa-bd7b-406c-9122-644d48864c49
sox FAIL formats: can't open input file `spotify://track/4ssBaxCHGQHRhzJmqNa2Yw': No such file or directory
2022-05-12 14:50:53 ERROR (MainThread) [music_assistant.mass.stream] Stream error on track 9b66bd52-99fb-4556-9717-43eb908438f3

Looked them up as these URLs in my browser
https://open.spotify.com/track/4WE6YQ6kyf4VWUjrb5cBs0
https://open.spotify.com/track/4ssBaxCHGQHRhzJmqNa2Yw

They both exist and play. So the errors are not related to missing tracks as such, but a failure to look them up. This doesn't seem to effect playback (no interruptions today, casting to the CC group).
These loggings quickly count up by the way (over 3000 in the last 8 hours).

Hi Marcel
Today I'm running the same playlist using the next version 1.0.18. In this version I didn't see these errors yet.
Yesterday I was van to a group, now to one CC device.
Something that you changed or continue testing with a group?
Eric

So I dived into the code a bit more which logs this error and this happens if the decoder receives an empty chunk of audio, either due to a network error (packet loss) or it simply was slow in filling the buffer.
Is your network plagued by some network hiccups or nothing at all? Do you have a fast internet connection?
Anyways I will adjust this message to debug loglevel because it isn't exactly an error but more a notification but I still like to know why it happens so often on your setup. I can see the warning being logged too on my family setup (which is playing music all day long) but just a couple of times a day which is perfectly fine.

As for the second issue with the wrong track inserted in the queue. That one is resolved in 1.1

Is your network plagued by some network hiccups or nothing at all? Do you have a fast internet connection?

I guess not, one CC even has a wired connection using an USB to ethernet device, the other CC's are really near an AP to ensure good connections. Casting normally doesn't give any hiccups. My internet connection is also fast (500mb fiber)

Anyways I will adjust this message to debug loglevel because it isn't exactly an error but more a notification but I still like to know why it happens so often on your setup.
I'm currently running log settings at warning level. So I can do a test run today with debug level for MA 👍 . I will give you the logfile via discord then (to much tokes/keys inside :-)

Best Eric

Debug logging is enabled and I will cast for a while

OK, just have a look please if the error is still logged very often. It is very normal that it is logged once in a while and the code can handle that just fine. Be warned that music_assistant logs pretty fanatic at debug level :-)

I know, so I only configured your part and debug level:
logger:
  default: warning
  logs:
    custom_components.mass: debug
    music_assistant: debug

Attached the logging of 45 minutes casting music to my CC group. It really runs fine. I didn't notice any relevant errors 👍
home-assistant (2).log
This issue seems fully solved as well :-)

Looks fine indeed. Thanks for your help testing!


[Azure Monitor Query] Test cases for querying logs

Logs query
Client test

[ ] Every request should include user-agent header in the expected format
[ ] Test distributed tracing instrumentation
[ ] Test support for different cloud environments*

Single query

[ ] Test a single query - happy case
[ ] Test a single query with partial success (returns 200 response but response body has tables + error)
[ ] Test a single query that returns an error (non-200 response)
[ ] Test all column data types are handled
[ ] Test mapping a table row into a strongly typed model
[ ] Test query for specific time ranges

[ ] Start and end datetime range (2021-06-08/2021-06-09)
[ ] Start datetime and end duration (2021-06-09/PT3H)
[ ] Start duration and end datetime (PT3H/2021-06-09)
[ ] Duration (PT12H)
[ ] No time range (query full dataset)

[ ] Test query that returns statistics
[ ] Test query that returns visualization data
[ ] Test query that requires > 3m to run and set server timeout value to 10 m
[ ] Test query that uses additional workspaces

[ ] Azure resource id
[ ] Workspace name
[ ] Workspace id
[ ] Fully qualified resource id

Batch query

[ ] Test a batch request - happy case
[ ] Test a batch request with error (server returns non-200 response)
[ ] Test a batch request with partial success (some queries in batch fail)
[ ] Test a batch request with individual queries returning partial success (single query in a batch has status 200 with error in the result)
[ ] Test a batch request which contains a query that requires > 3m to run and set the server timeout value to 10 m for that query
[ ] Test a batch request that returns statistics (for some or all queries in the batch)
[ ] Test a batch request that returns visualization data (for some or all queries in the batch)
[ ] Test a batch request that uses different workspaces for different queries in the batch
[ ] Test a batch request that uses additional workspaces for a query in the batch
[ ] Test a batch request that has n queries (n > 200) in a batch (service supports up to 200 requests in 30-second window) to validate server returning 429 response for n - 200 queries and successful response for first 200 queries.

Test a single query with partial success (returns 200 response but response body has tables + error)

What's the expected user experience?

Test query that returns visualization data

How do we plan to expose the visualization data?

What's the expected user experience?

@pakrym The result will contain a non-null tables property and error property when this happens. The user should ideally check for both to ensure there are no errors.
However, most users would check the error field and assume the query failed (if they check errors first) or assume that the query succeeded if the tables field had results even though it was only a partial success. So, we should clearly document and provide samples to check for both fields.
We could additionally include an enum to indicate the result status - {ERROR, SUCCESS, PARTIAL_SUCCESS} to make this obvious and the user can check this first to know how to process the result.
Thoughts?

Thoughts?

Sounds good on exposing error. I've also exposed a HasFailed property to differentiate between full failure and partial one.


Q and E to move Camera up or down

Added Q and E to move Camera up or down

I'll be re-implementing a character controller for the demo, this would function more like Minecraft and have collisions

Good idea!


请问这个项目跟原先的felixonmars/fcitx5-pinyin-zhwiki还有关联吗？

代码看上去完全不一样，是重写了吗

Closing as resolved. Feel free to re-open for further questions.


Keyboard access?

My final one for now, sorry:-)  Is there a chance we might use the keyboard for typing at some point? I do think the capitals are brilliant.

Both the on-screen and the hardware keyboard of Windows (set to Modern Greek) work fine for me.

Φοργετ what I said!! I never realized the choice of keyboard would make a difference. Works fine with polytonic on Mac as well.


set up public role + metadata

This PR sets up a public role via the HASURA_GRAPHQL_UNAUTHORIZED_ROLE=public env variable. More info here
Problem is that we still need to add this public role on the Hasura interface:

Turns out that we can actually export metadata from a current Hasura instance and re-apply them during the docker-compose workflow, so that we don't need anymore to manually track the benchmark table nor add the public role.
First step was to init the hasura-server project with the hasura-cli:
# https://hasura.io/docs/latest/graphql/core/migrations/migrations-setup.html#step-1-install-the-hasura-cli
hasura init hasura-server --endpoint http://localhost:8080/

Then export the metadata:
hasura metadata export --endpoint http://localhost:8080/ --admin-secret "my_secret"

Then use a specific hasura docker image hasura/graphql-engine:v1.3.3.cli-migrations-v2 and mount a hasura-metadata folder from the locally exported metadata folder. More info here

Setting this up on autumn now, will report back and merge :crossed_fingers:

I like this a lot better. As I've never worked with Hasura before, it took quite a while to figure out that I had to manually track them in first place! Good work


Re-use existing shared instances.

Currently it is possible to share Service Instances:

https://help.sap.com/docs/btp/sap-business-technology-platform/cloud-foundry-environment
https://help.sap.com/docs/btp/btp-cli-command-reference/btp-share-services-instance
https://docs.cloudfoundry.org/devguide/services/sharing-instances.html

The SAP BTP Service Operator already support creation of shared instances via .spec.shared: true property. However for migration purposes it would be highly valuable to be able to create a binding for an existing shared instance (not managed by the operator itself).
The ServiceBinding spec could be extended with a property like .spec.sharedInstanceName or similar, which would tap into an existing shared service instance and create a binding for it.

i'm not sure i understand the scenario, but in general it is not possible to create a binding to an instance located in another platform, the instance and binding must be in the same platform, in Kubernetes cluster the operator=platform, if i understand your use case you already have a shared instance somewhere, create an instance of this shared in the cluster and create it a binding.

resolving since there is no activity


Implement alizer support for devfile port detection

Which area/kind this issue is related to?
/area alizer
Issue Description
This issue part of EPIC #1154 and is focusing on the implementation of devfile port detection function. This task has several steps we should follow:

Expand the functionality of utils.GetLocations() to detect locations for devfiles too. The function will follow the some prioritization rules:

First look into the root level and then we will look one level down, exactly like the dockerfile case.
The devfile naming follows specific naming prioritization -> devfile.yaml > .devfile.yaml > devfile.yml > .devfile.yml

Implementation of enricher.GetPortsFromDevfile, similar to enricher.GetPortsFromDockerfile.

Implementation of utils.ReadPortsFromDevfile, similar to utils.ReadPortsFromDockerfile. This function will be looking for any defined ports inside the devfile, using the Devfile library. The function will return either inner loop, or outerloop ports (or both), based on what flag the user passes in.

Require user to specify inner loop vs. outerloop ports (or both) when retrieving the ports

Acceptance Criteria

[ ] The GetPortsFromDevfile is implemented and able to detect ports inside a devfile.y(a)ml.
[ ] Specific prioritization will be followed for the naming of the devfiles.
[ ] Test cases are created.
[ ] Flags to specify inner loop, outerloop or both types of ports
[ ] Alizer to use Devfile library to parse devfiles

Moving to refinement for Nov 17th - @thepetk to open separate issue under epic for investigating devfile library changes that may be needed.

Moving to refinement for Nov 17th - @thepetk to open separate issue under epic for investigating devfile library changes that may be needed.

@johnmcollier I've created item: https://github.com/devfile/api/issues/1338

I've added a comment related to this issue here: https://github.com/devfile/api/issues/1338#issuecomment-1863069214


Do not add empty user text on chat memory

close https://github.com/spring-projects/spring-ai/issues/1601
someone did not want add empty user text on chat memory
so, I fix chat advisor to not add message when user text is empty

Thanks for submitting this PR! This shouldn't be needed anymore since we introduced null-safety for ChatClient and Advisor APIs, and removed the default empty user text. The user message is now required and it will never be null or empty in the context of an Advisor.

Thanks for submitting this PR! This shouldn't be needed anymore since we introduced null-safety for ChatClient and Advisor APIs, and removed the default empty user text. The user message is now required and it will never be null or empty in the context of an Advisor.

Oh, I see. I'm also curious about other possible solutions—would it be possible to check the commit history to see how it was implemented? Thanks for your kind response!

Yes, of course! Most changes are in this PR: https://github.com/spring-projects/spring-ai/pull/1651

@DHKIM-0511 we have an open discussion about making the logic of identifying a user message more flexible, while still ensuring internal consistency. If you have some use cases or ideas related to that, feel free to share them in https://github.com/spring-projects/spring-ai/issues/1665 Thanks!

Looking at the PR, I realized I missed a few lines of code. I understand now that the feature is no longer needed. I’ll also consider the issue you mentioned. Thanks!


Github Awards API

Add a public API to access Github Awards data :

User detail
World ranking
Country ranking
City ranking

Are you building it or do you want me to do it?

Pull request are most welcome ! Thanks for offering your help.

Hi @vdaubry are you still thinking about adding this, or are you wanting for the project to have support first?
Best of luck though. I keep my fingers crossed. :)

Hi @nunogoncalves ! Yes we should merge the PR, the last thing to do is lowercase the redis keys.
I hope to finish this before new year so we can release the API for 2016 ;)
Regarding the need for a sponsor : the project received great support for the community, that's awesome !! i think i'll have some great news about that soon.

@nunogoncalves Good news : Redis keys are now all lowercase.
I'll be able to merge the API PR soon now !

Great! :)
No dia domingo, 27 de dezembro de 2015, vincent daubry <
<EMAIL_ADDRESS>escreveu:

@nunogoncalves https://github.com/nunogoncalves Good news : Redis keys
are now all lowercase.
I'll be able to merge the API PR soon now !
—
Reply to this email directly or view it on GitHub
https://github.com/vdaubry/github-awards/issues/74#issuecomment-167432040
.

--
Cumprimentos,
Nuno Gonçalves

I can see a problem with the documention. The api requests are failing.
The requests are being made to

http://github-awards.comhttp//api/v0/languages.json?sort=popularity
The base url is being duplicated. I'll have a look into it as soon as I can.

Ok i found where the problem was coming from, it's fixed now.
Actually it was an interesting issue :
The HOST environment variable was set in ~/.bashrc
This file was not read when Capistrano was executing rake swagger:docs
To make it work with Capistrano i had to set it in /etc/environment
http://capistranorb.com/documentation/faq/why-does-something-work-in-my-ssh-session-but-not-in-capistrano

The Github Awards API is available in beta ! Here is the documentation :
http://github-awards.com/docs
We're looking for feedback so please open an issue if you have any questions or if you find some bugs !
:warning: The API is still in beta and methods signature can change anytime :warning:
I'll close this issue when we officially release the API

Hey @vdaubry,
If I search for a city but use a country's name, I'm getting the same list as searching for that country.
Is that behaviour expected?
http://github-awards.com/api/v0/users/?language=javascript&city=Portugal&type=city&page=1

The docs page doesn't exist anymore.
Is this project still active ?

Crosslinking with #119 which is about the broken docs.

Any update on API Endpoints, really looking to see if there is a way to query for top users in a given city with a specific language/languages?

And just like that, I found the solution 😬. However, is there currently a way to query for multiple languages at once with the API? Also is there going to be any update to the docs? Sorry for being so needy, I just think this repo is great and would be even better with a well documented API


"import ." on the file you are in freezes the compiler

// main.odin
import . "main.odin";

main :: proc() {

}

the compiler just hangs forever

The import system is still in development and the main goal for the next release.


pull request for e2e test at 12/08/2016 10:56:01

:white_check_mark: Validation status: passed
For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.


Error when entering exit on the server

Forge CLI Version: 1.4.0
PHP Version: 8.2.0
Operating System: Darwin
Error Message: Carbon\Carbon::setLastErrors(): Argument #1 ($lastErrors) must be of type array, bool given, called in phar:///Users/mykolanizriukhin/.composer/vendor/laravel/forge-cli/builds/forge/vendor/nesbot/carbon/src/Carbon/Traits/Creator.php on line 98.

Description:
Got an error while exiting the server
Steps To Reproduce:
Enter exit when logged into the server

I released v1.4.1 with an update for Carbon that should fix this.

Cool! Thank you!


Migration to Resonite Ready

Hello! It just wanted to let you know that I forked the repo and updated the mod to work with Resonite. All DLLs have been updated to point to the new Resonite DLLs; code and unit tests were also updated as a result. When the modding group makes the decision on the official loader, I will make sure to do one final update and give those changes back to you via a PR or through other means that you prefer.
Fork: https://github.com/stiefeljackal/Resonite-TypeType

Sweet, thank you for making the migration! I wasn't sure if people actually used this mod.
I skimmed the changes and they looked pretty valid, but I can take an actual review pass later tonight or tomorrow.
If you want to, please make a pr with me marked as a reviewer, that way I can more easily see it in my queue.

Created PR #5 and marked as ready for your review.

Delta released the official mod loader. I’ll make the final PR today to update any necessary information. Once that is done, this mod will be ready for the full Resonite mod experience. :)

I pushed a new release and updated the config in this repo, it just needs to get merged into the mod manifest repo.

I see that, but the README needs to be updated to point to Delta's Official Mod Loader and the disclaimer above needs to be removed. The README is the only file that needs to be updated so you can do that if you want. The DLL might need to be recompiled to Delta's Mod Loader DLL as well

Good call, I'll do an update later today or tomorrow


⚠ Site ANTS has degraded performance

In f4811ba, Site ANTS (https://ants.gouv.fr) experienced degraded performance:

HTTP code: 200
Response time: 4486 ms

Resolved: Site ANTS performance has improved in 5d6b9be.


Remove: Unity.Unity.6000.tvOS version 6000.0.13f1

Microsoft Reviewers: Open in CodeFlow

URL: https://download.unity3d.com/download_unity/53a692e3fca9/TargetSupportInstaller/UnitySetup-AppleTV-Support-for-Editor-6000.0.13f1.exe
OK
(Automated message - build 923)

https://github.com/microsoft/winget-pkgs/pull/186121#issuecomment-2445759087

[Policy] Needs-Manual-Merge


Make mesos executor registration timeout a mea-culpa failure

Can you take a quick pass and see if there are others that could be set to mea-culpa? Originally we were conservative on which would be mea-culpa because they would be retried indefinitely. We have since added a limit so it is less of a problem.

I made 3 more changes, take a look and see what you think

Test failed. I'm assuming it is flaky. Restarted it, hopefully it will pass this time.


More register-specific config items

This makes the register download and delete endpoints into register-specific config values.

All looks good 👍


ignore origin bucket mfa delete

what

ignore mfa_delete property for origin s3 bucket

why

mfa_delete is not controlled by this module

references

https://github.com/cloudposse/terraform-aws-cloudfront-s3-cdn/issues/189

We have made the decision not to support S3 buckets that have MFA delete enabled. It was annoying with AWS provider v3 when the mfa_delete did not actually enable or disable the feature, it simply tracked its state. However, AWS provider v4 is now out and not only does that field set the state, when MFA delete is set, you have to supply an MFA token any time you want Terraform to work with the bucket. This is completely at odds with automation, and while there can be a good reason to enable MFA delete, our professional opinion is that in those cases, you should not be automating the provisioning and configuration of the S3 bucket with Terraform. Therefore, we are not going to support buckets where MFA delete is enabled.
You may want to use our companion module, terraform-aws-cloudfront-cdn, to take over the Cloudfront configuration and plug in your manually configured S3 bucket to use with it.
Closes #190 (this PR) and closes #189.


FEAT - 328 - Add support for maximum specification link depth

This PR adds maximum_specification_link_depth as a property on the BomAnalyticsClient object. Adds a pair of integration tests, and a couple of unit tests, as well as a new example cell in the notebooks.

Codecov Report

Merging #341 (beaac2a) into main (ccee303) will decrease coverage by 0.34%.
Report is 11 commits behind head on main.
The diff coverage is 93.10%.

@@            Coverage Diff             @@
##             main     #341      +/-   ##
==========================================
- Coverage   95.32%   94.99%   -0.34%
==========================================
  Files          10       10
  Lines        1370     1379       +9
==========================================
+ Hits         1306     1310       +4
- Misses         64       69       +5

Files Changed
Coverage Δ

src/ansys/grantami/bomanalytics/_connection.py
88.80% <93.10%> (+0.41%)
:arrow_up:

... and 5 files with indirect coverage changes

I realize we also need to add notes, at least on the property docstring, that explain this is only supported in the 2023 R2 RS reports bundle.


<EMAIL_ADDRESS>hash check failed (but only with aria2)

Using aria2:
PS > scoop install meld
WARN  Scoop uses 'aria2c' for multi-connection downloads.
WARN  Should it cause issues, run 'scoop config aria2-enabled false' to disable it.
Installing 'meld' (3.18.2) [64bit]
Starting download with aria2 ...
Download: [#ccd2e7 0B/17MiB(0%) CN:2 DL:0B]
Download: [#ccd2e7 8.0MiB/17MiB(46%) CN:2 DL:8.5MiB ETA:1s]
Download: [#ccd2e7 11MiB/17MiB(66%) CN:1 DL:5.9MiB]
Download: [#ccd2e7 13MiB/17MiB(80%) CN:1 DL:4.7MiB]
Download: [#ccd2e7 16MiB/17MiB(95%) CN:1 DL:4.2MiB]
Download: Download Results:
Download: gid   |stat|avg speed  |path/URI
Download: ======+====+===========+=======================================================
Download: 2a7ceb|OK  |   219KiB/s|C:/Users/user/scoop/cache/meld#3.18.2#https_download.gnome.org_binaries_win32_meld_3.18_Meld-3.18.2-win32.msi
Download: ccd2e7|OK  |   3.9MiB/s|C:/Users/user/scoop/cache/Meld-3.18.2-win32.msi
Download: Status Legend:
Download: (OK):download completed.
Checking hash of Meld-3.18.2-win32.msi ... ERROR Hash check failed!
App:         extras/meld
URL:         https://download.gnome.org/binaries/win32/meld/3.18/Meld-3.18.2-win32.msi
First bytes: 3C 3F 78 6D 6C 20 76 65
Expected:    6d071f0ddf75f075e2a0f849967ef96235dfddd5c0aa1bd8a82d25d47894c324
Actual:      af4dcf72a9ab168e531e40eec5b62b712b544271738f8030a47e83d2bc139578

But disabling aria2:
PS > scoop install meld
Installing 'meld' (3.18.2) [64bit]
Meld-3.18.2-win32.msi (17,3 MB) [=====================================] 100%
Checking hash of Meld-3.18.2-win32.msi ... ok.
Extracting Meld-3.18.2-win32.msi ... done.
Linking ~\scoop\apps\meld\current => ~\scoop\apps\meld\3.18.2
Creating shim for 'meld'.
Creating shortcut for Meld (Meld.exe)
'meld' (3.18.2) was installed successfully!

Not really an issue with meld but seems like aria2 broke (this particular) download!

Should be fixed in lukesampson/scoop#2560. Try again.