Taint nodes with a NoSchedule for Consolidation before Validation begins

Description
What problem are you trying to solve?
Karpenter adds a karpenter.sh/disruption:NoSchedule=disrupting taint for Consolidation actions after a 15s validation period. There is a narrow interval of time where pods blocking eviction can schedule to nodes when Karpenter taints the nodes, resulting in these pods getting eventually evicted during termination. This was validated to be a race of < 300ms here.
While https://github.com/aws/karpenter-core/issues/624 includes PreferNoSchedule as an option here, it may make more sense to only use NoSchedule for Consolidation here to completely remove this race condition.

Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
If you are interested in working on this issue or have submitted a pull request, please leave a comment

/assign @njtran

/assign @ljosyula

/assign jmdeal

I'm working on implementing a patch to deal with this issue at my company. We're running into this constantly when using Karpenter for a cluster with almost nothing but ephemeral CI jobs, which seems like a recipe for constant disruption evaluation because the pod profile is highly volatile.
Can I ask that we prioritize an air-tight fix for the issue instead of another "reduce the chance of it occurring" option that is proposed with the PreferNoSchedule implementation? Right now the do-not-disrupt annotation does not do what it says on tin.

@wmgroot Can you share how often you're hitting this? From my understanding the race is super small window, so I'm curious exactly how often this is hitting. Are you seeing a do-not-disrupt pod added/scheduled to a node, only for that node to be soon consolidated after?

We've seen almost 2300 occurrences in the last week with Gitlab CI job pods. Every pod has the do-not-disrupt annotation. This cluster has about 25 NodeClaims which are primarily used for extremely volatile CI jobs.

Here is the patch I've applied to our clusters to address the issue, which verifies there are no do-not-disrupt pods after a simple 30s sleep. We've seen 0 occurrences of the issue since I applied the patch.
https://github.com/wmgroot/karpenter/pull/1/files

Here are some notes I've taken as I've explored this particular problem space. Hopefully this is helpful as background to anyone else trying to understand the problem.
I'd ultimately prefer we didn't use this annotation at all because it has node-level impact (a single pod can keep a node of arbitrary size around indefinitely). The limitations of Gitlab CI are currently making it necessary to use the annotation to complete a transition from cluster-autoscaler to Karpenter, which is still worth the tradeoff.

Job-type workloads want a way to delay or avoid unnecessary disruption, since this results in lost work that must be performed again.
There are multiple cases where pod shutdown is desired, but each situation might have a different preferred outcome. For example:
a. Initial shutdown of a node due to efficiency consolidation or a regular maintenance update.
b. Node lifetime timeout due to compliance requirements.
c. User-initiated cancellation of a CI pipeline.
The do-not-disrupt annotation is Karpenter-specific, making it not portable between different cluster architectures (which may or may not include cluster node autoscaling.
PDBs are architecture agnostic, but are not a great fit for job-type workloads, they're designed for redundant pod patterns. In our clusters we have several OPA policies that forbid the creation of PDBs that do not tolerate voluntary disruption, blocking their use for single pod cases.
PreStop hooks are architecture agnostic, but make it difficult to support the desired outcomes for the cases described in point 2. They are not aware of "why" the pod is being requested to terminate.

Point 5 is the current reason why we can't just use a preStop hook to address the disruption of CI jobs. The hook doesn't know the difference between karpenter terminating the pod for node consolidation (we want to delay disruption) and a user in the Gitlab UI terminating the pod to cancel a CI pipeline (we want to terminate the pod immediately, but still run any post-job cleanup, which is skipped via forced pod termination). Adding the preStop hook as Gitlab CI is currently implemented would block termination of the job pod if a user attempted to cancel the job through the UI.

We are also still seeing this issue from time to time, though less often than previous to the mitigation in https://github.com/kubernetes-sigs/karpenter/pull/583
I observed the following events:
{"eventNamespace":"default","involvedObject":{"kind":"Node","name":"ip-172-31-6-136.eu-central-1.compute.internal","uid":"473d160c-783a-427e-a75f-5c57c57e29df","apiVersion":"v1"},"reason":"DisruptionBlocked","eventMessage":"Cannot disrupt Node: Pod \"default/cdp-default-2ekrbha7wakskum3uuw492ts4y\" has \"karpenter.sh/do-not-disrupt\" annotation","source":{"component":"karpenter"},"firstTimestamp":"2024-02-26T16:41:54Z","lastTimestamp":"2024-02-26T16:41:54Z","count":1,"type":"Normal","reportingComponent":"karpenter"}

{"eventNamespace":"default","involvedObject":{"kind":"NodeClaim","name":"default-karpenter-fh9zb","uid":"42c74ed6-77b9-41e9-ae6f-b27b4e29feab","apiVersion":"karpenter.sh/v1beta1"},"reason":"DisruptionBlocked","eventMessage":"Cannot disrupt NodeClaim: Pod \"default/cdp-default-2ekrbha7wakskum3uuw492ts4y\" has \"karpenter.sh/do-not-disrupt\" annotation","source":{"component":"karpenter"},"firstTimestamp":"2024-02-26T16:41:54Z","lastTimestamp":"2024-02-26T16:41:54Z","count":1,"type":"Normal","reportingComponent":"karpenter"}

{"eventNamespace":"default","involvedObject":{"kind":"Node","name":"ip-172-31-6-136.eu-central-1.compute.internal","uid":"473d160c-783a-427e-a75f-5c57c57e29df","apiVersion":"v1"},"reason":"DisruptionTerminating","eventMessage":"Disrupting Node: Consolidation/Delete","source":{"component":"karpenter"},"firstTimestamp":"2024-02-26T16:41:54Z","lastTimestamp":"2024-02-26T16:41:54Z","count":1,"type":"Normal","reportingComponent":"karpenter"}

{"eventNamespace":"default","involvedObject":{"kind":"NodeClaim","name":"default-karpenter-fh9zb","uid":"42c74ed6-77b9-41e9-ae6f-b27b4e29feab","apiVersion":"karpenter.sh/v1beta1"},"reason":"DisruptionTerminating","eventMessage":"Disrupting NodeClaim: Consolidation/Delete","source":{"component":"karpenter"},"firstTimestamp":"2024-02-26T16:41:54Z","lastTimestamp":"2024-02-26T16:41:54Z","count":1,"type":"Normal","reportingComponent":"karpenter"}

{"eventNamespace":"default","involvedObject":{"kind":"Node","name":"ip-172-31-6-136.eu-central-1.compute.internal","uid":"473d160c-783a-427e-a75f-5c57c57e29df","apiVersion":"v1"},"reason":"FailedDraining","eventMessage":"Failed to drain node, 10 pods are waiting to be evicted","source":{"component":"karpenter"},"firstTimestamp":"2024-02-26T16:41:54Z","lastTimestamp":"2024-02-26T16:41:54Z","count":1,"type":"Warning","reportingComponent":"karpenter"}

{"eventNamespace":"default","involvedObject":{"kind":"Pod","namespace":"default","name":"cdp-default-2ekrbha7wakskum3uuw492ts4y","apiVersion":"v1"},"reason":"Evicted","eventMessage":"Evicted pod","source":{"component":"karpenter"},"firstTimestamp":"2024-02-26T16:41:55Z","lastTimestamp":"2024-02-26T16:41:55Z","count":1,"type":"Normal","reportingComponent":"karpenter"}

The first two events show that the pod cdp-default-2ekrbha7wakskum3uuw492ts4y is blocking the disruption, but the very next events 1 second later is that the node is being disrupted.
This pod is used to run e2e tests and evicting this pod basically breaks our e2e run, so it's similar disruption as mentioned in the example from @wmgroot

@mikkeloscar Thats interesting. I wouldn't expect to see the behavior that you're describing. I could definitely see this race occurring when there is a pod that is just coming up and we don't see the binding to the new node yet, but it's odd that we would have a node that is blocked by a pod and then one second later we see that that same pod is no longer blocking (but no bindings have changed).
Did the state of that pod change in any way? Did it shift to a new node or did it change its phase or status conditions to indicate that it finished?

Did the state of that pod change in any way? Did it shift to a new node or did it change its phase or status conditions to indicate that it finished?

I'm not 100% sure as we rely on events that we ship to our long term storage, but in all the events about the pod I can only find the event about karpenter evicting the pod and before it was in a running state.
I looked at earlier events and the pod was just started 6s before the first attempt to disrupt, so that is maybe also a relevant thing to consider:
{"eventNamespace":"default","involvedObject":{"kind":"Pod","namespace":"default","name":"cdp-default-2ekrbha7wakskum3uuw492ts4y","uid":"1e9e7393-68db-466b-9126-956d9c9830f7","apiVersion":"v1","fieldPath":"spec.containers{main}"},"reason":"Started","eventMessage":"Started container main","source":{"component":"kubelet","host":"ip-172-31-6-136.eu-central-1.compute.internal"},"firstTimestamp":"2024-02-26T16:41:48Z","lastTimestamp":"2024-02-26T16:41:48Z","count":1,"type":"Normal","reportingComponent":"kubelet","reportingInstance":"ip-172-31-6-136.eu-central-1.compute.internal"}

i have the same problem with CI Job/Pods.
The Pod has do-not-disrupt & do-not-evict annotations.
The Pods is started some seconds before Karpenter try to consolidate the node
""message":"disrupting via consolidation delete, terminating 1 candidates "
The Pod will Evicted

I wouldn't expect to see the behavior that you're describing. I could definitely see this race occurring when there is a pod that is just coming up and we don't see the binding to the new node yet, but it's odd that we would have a node that is blocked by a pod and then one second later we see that that same pod is no longer blocking (but no bindings have changed).

We're also seeing frequent issues under almost the same circumstances as https://github.com/kubernetes-sigs/karpenter/issues/651#issuecomment-1944397047 - GitLab CI executor pods being evicted frequently even though they have the do-not-disrupt annotation specified at pod creation time. Anecdotally (I don't have before/after metrics), the frequency of this issue increased after upgrading from v0.33.x to 0.35.0.

Same here, also with GitLab CI Job execution pods. Just chiming in to underline that this is a serious bug seriously affecting (karpenter) users in real life :-).

My team (big global Company) is affected by this while using argo workflows (job templates behind the scenes).
Pods gets eviction notice before even entering init stage. do-not-disrupt annotation doesnt help

I'm going to wager we're seeing this occur more frequently as users migrate to versions of Karpenter with parallel disruption. More rapid, parallel consolidation == more occurrences of this race condition. We've been punting solving this issue for a full, airtight taint strategy redesign but given the increased prevalence we should take a temporary measure that may or not be amended when we do do the taint redesign addressing #624.
Realistically, I think @wmgroot's solution is a good route to go within our existing tainting behavior. I am curious if we really need a full 30 second waiting period, given that the pod list is eventually consistent we will need some sufficiently large waiting period. CAS implements a similar wait period that is defaulted to 5 seconds but is configurable via the node-delete-delay-after-taint flag, though I haven't seen any guidance on when a user might need to tune this.

Making it configurable just covers the case where someone might need to increase it in the future. I agree that 30s is likely much longer than it needs to be.

@wmgroot I tested your branch and it seems to have greatly improved the situation (I just made small changes: rebase from the latest published tag, restore the pdb exclusion and exclude failed / succeeded pods when comparing annotations).
However, I'm still seeing a few nodes being evicted when Karpenter is starting, here are the logs:
Starting workers
tainted node
deleted node
deleted nodeclaim

During the startup, I don't see the following message that was introduced in the PR:
waiting for 30 seconds to check for do-not-disrupt or do-not-consolidate pods that may have scheduled...

I can see it when the disruption controller is attempting to disrupt a node though.
Is there another place where nodes are being disrupted and we need to call the ValidateNoScheduleTaint() func?
Thanks!

These log lines should be coming from the termination controller which handles the eventual deletion of nodes instead of the disruption controller. If the disruption controller was responsible for deleting the nodes (rather than a manual user action) they should have already been tainted and validated by the disruption controller. I imagine what happened is when Karpenter was restarted a disruption decision had been made, candidates were tainted and validated, and then nodes had their deletion timestamps set. Karpenter restarted before the termination controller processed all of the nodes and it continued after it came back up. Does this line up with what you saw @gnuletik? Or were there instances of nodes with do-not-disrupt pods being interrupted?

As a temporary workaround I've implemented a validating webhook that rejects eviction requests from Karpenter if the pod is appropriately annotated. This seems to work, but is detrimental because (as I understand it) eviction will now be blocked for pods that are interrupted (e.g. spot reclaim), which is undesirable (but acceptable short-term in one particular case I'm dealing with).
@jmdeal do you have an estimate for when a short-term fix and a long-term fix will be available? We're looking to rapidly expand our use of Karpenter within our infrastructure and this issue is making it difficult to do so. Having an idea of when a short-term/long-term fix will be available will help us determine what our next steps should be.

Hello thank you for providing the fix. We have installed the release 0.36.1 on Friday and the whole weekend there were no crashes in our CI/CD agents. The last weekend we had an interruption almost every hour. The fix seems to be working well. Thank you very much !

We've upgraded to 0.36.1 around 6 days ago, the issue hasn't reoccurred as of yet. Appreciate your work, thanks guys.

I've also not received any reports of unexpected consolidation disruptions since upgrading to 0.36.1. However, I've seen drift disruptions on nodes with the do-not-disrupt annotation on one or more assigned pods, which I believe is unexpected. I've worked around this for now by disabling drift disruption.

Definitely not expected, how frequently are you seeing this occur? Do you have logs you can share? Maybe worth opening a separate issue?

We've upgraded to 0.36.1 around 6 days ago, the issue hasn't reoccurred as of yet. Appreciate your work, thanks guys.

Looks like we're still seeing pods getting evicted (despite do-not-disrupt annotation) immediately after scheduling due to node consolidation, even when running v0.36.1.
Karpenter log entries for the node as follows:
{"level":"INFO","time":"2024-05-24T11:26:25.504Z","logger":"controller.nodeclaim.lifecycle","message":"registered nodeclaim","commit":"fb4d75f","nodeclaim":"application-amd64-bottlerocket-on-demand-v1-bzkbj","provider-id":"aws:///eu-central-1c/i-0c349508d7a941d34","node":"ip-10-48-37-168.eu-central-1.compute.internal"}
{"level":"INFO","time":"2024-05-24T11:26:55.171Z","logger":"controller.nodeclaim.lifecycle","message":"initialized nodeclaim","commit":"fb4d75f","nodeclaim":"application-amd64-bottlerocket-on-demand-v1-bzkbj","provider-id":"aws:///eu-central-1c/i-0c349508d7a941d34","node":"ip-10-48-37-168.eu-central-1.compute.internal","allocatable":{"cpu":"15890m","ephemeral-storage":"60711501722","hugepages-1Gi":"0","hugepages-2Mi":"0","memory":"28604942517","pods":"234"}}
{"level":"INFO","time":"2024-05-24T11:30:59.945Z","logger":"controller.disruption","message":"disrupting via consolidation delete, terminating 1 nodes (0 pods) ip-10-48-37-168.eu-central-1.compute.internal/c5a.4xlarge/on-demand","commit":"fb4d75f","command-id":"e2b9463c-d676-4c3e-9df8-1c00b5101946"}
{"level":"INFO","time":"2024-05-24T11:31:00.412Z","logger":"controller.node.termination","message":"tainted node","commit":"fb4d75f","node":"ip-10-48-37-168.eu-central-1.compute.internal"}
{"level":"INFO","time":"2024-05-24T11:31:06.694Z","logger":"controller.node.termination","message":"deleted node","commit":"fb4d75f","node":"ip-10-48-37-168.eu-central-1.compute.internal"}
{"level":"INFO","time":"2024-05-24T11:31:07.213Z","logger":"controller.nodeclaim.termination","message":"deleted nodeclaim","commit":"fb4d75f","nodeclaim":"application-amd64-bottlerocket-on-demand-v1-bzkbj","node":"ip-10-48-37-168.eu-central-1.compute.internal","provider-id":"aws:///eu-central-1c/i-0c349508d7a941d34"}

The k8s event log regarding the pod in question is rather straightforward:
10m         Normal    Scheduled                    pod/runner-svhlvxier-project-30216564-concurrent-0-r6wflsak                           Successfully assigned gitlab-runner/runner-svhlvxier-project-30216564-concurrent-0-r6wflsak to ip-10-48-37-168.eu-central-1.compute.internal
10m         Normal    Evicted                      pod/runner-svhlvxier-project-30216564-concurrent-0-r6wflsak

I'd estimate this occurs once every 50 CI jobs. Do you require any other logs or loglevels to better analyze the issue?

Hmm, that seems pretty clear cut. There are some inflight changes that will mitigate the impact of these slipping through, #916 includes a change that will prevent pods with the do-not-disrupt annotation from being evicted during our drain process (with TerminationGracePeriod providing a mechanism for cluster operator to set an upperbound on node lifetime). Would this change be sufficient for your use case? The other option left for us is to have the overlapping taint / validation period, which will come at the cost of increased disruption latency since we would need to wait a few seconds to ensure the kube-scheduler has seen the taint.

#916 includes a change that will prevent pods with the do-not-disrupt annotation from being evicted during our drain process

The do-not-disrupt annotation being respected during drain should fix our issue. Let's see how it behaves when https://github.com/kubernetes-sigs/karpenter/pull/916 gets merged. Thanks for your hard work :)

@jmdeal I'm wondering if we might be subject to this bug, or a similar bug, or if Karpenter properly handles this use case. It is difficult to catch happening, and I have not seen it yet (we only just started using this mechanism), but I think it is likely that Karpenter does not handle this properly, and I want to get it addressed. I don't see an easy way to monitor for it, and I do not want to put the effort into catching the bug if you can confirm from reviewing the code that the bug exists. Please let me know your thoughts.
We are running ephemeral GitHub Action Runners. These Pods take jobs off a queue, run the job, then exit. They take a while to start up (anywhere from 10 seconds to 3 minutes depending on what else is going on with the Node), so we keep a warm pool of idle runners ready to accept jobs, and then launch new Pods when those idle Pods start doing real work.
Idle Pods can be disrupted, so we schedule and deploy Pods with no annotations. We want the idle Pods to be disrupted if it will allow consolidation, because we can scale from a few to a few hundred and back, and do not want idle Pods scattered across big instances to prevent them from being consolidated to a single small instance.
The catch is, once a Pod takes a job, we want the job to run to completion, and do not want it disrupted. GitHub Action Runners to not have an automatic retry mechanism (in part, because jobs are long and complex and not likely idempotent), so if they are killed, it requires manual intervention to decide what to do about the incomplete job. So to avoid having them interrupted, the first thing the Pod does after taking a job is add the "do-not-disrupt" annotation to itself.
Now in this case, the Pod is already on the Node, unaffected by any NoSchedule taints, and the Node looks like a consolidation candidate until the Pod adds the annotation. So my question is, in this case, will adding the annotation stop a consolidation in progress from going forward? If not, is that a bug?
If this use case is not already properly handled, how can I help get it handled (without writing code)?

Confirming @Nuru 's comment, we are seeing the same behaviour with our airflow jobs on v0.37.0.

/remove-lifecycle stale


googleDark should have a black background?

Hello,
Noticed googleDark has a Facebook like blue backgroud instead of black.
Can you correct it?
Alternatively, could we have a custom background color setting perhaps? So you dont have to hardcode these variables?

Hello,
The back color of the button is designed to match the document. Sign-In Branding Guidelines
But you can set the background color as you wish.
 btnColor: Colors.white,

Wow thx. I notice Google is strick about the background color. I guess we will leave it at that then :) Much appreciated


Multi-part form data passthrough fails

The following document tests that the api is working normally:
<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <title>Title</title>
</head>
<body>
<input type="file" name="aFile" id="input">
<script src="https://code.jquery.com/jquery-2.1.4.min.js"></script>
<script>
    $('#input').on('change',function(evt) {
        var formData = new FormData();
        var input = evt.target;
        formData.append(0,input.files[0]);
        debugger;
        $.ajax({
            type: "POST",
            url: "http://api.debian-vm/layoutbooks/imageupload",
            data: formData,
            cache: false,
            contentType: false,
            processData: false,
            headers: {
                "X_UPLOAD_IMAGE_ASSET_NAME": 'someName',
                "X-upload-image-asset-name": 'someName',
                "X_UPLOAD_IMAGE_ASSET_ID": 'someID',
                "X-upload-image-asset-id": 'someID',
            }
        }, function(data, textStatus, jqXHR) {
            debugger;
        });
    });

</script>
</body>
</html>

Given multiple ember apps running mirage (v0.1.11), inserting the input element via Chrome inspector and adding the event handler through the console, the initial OPTIONS request passes but the following POST request fails with "400 (Bad Request)".  Comparing the requests, I can see that the ember app POST request has "Content-Type:text/plain;charset=utf-8" wheras normally it is something like : "Content-Type:multipart/form-data; boundary=----WebKitFormBoundaryIpXCvBDCghXr5iTO" so it would seem the passthrough is muddling the request in some way.  I also tried cut/pasting the code into a non-mirage ember app and it still seems to work.  Sorry I can't provide an example with a working api as that one is running locally but hopefully this will help you make some sense of this.
P.S.  Though this is not urgent, your attention would be greatly appreciated.  Thanks a lot for making such a useful contribution to ember community :+1:

Thank you for the kind words :)
What does your current POST mock look like in Mirage? Could you start with something simple, like ignoring the data altogether and just returning a 201?
this.post('http://api.debian-vm/layoutbooks/imageupload', {}, 201);

There is no post mock for this endpoint.  Why would I need one when my imageupload api works otherwise ?

I see, so you're saying it's basically not working? The request is not being passed through?

The request is passed through but it is not the same as it is ordinarily (see inline comments at >>>>>>)
General:
Remote Address:<IP_ADDRESS>:80
Request URL:http://api.debian-vm/layoutbooks/imageupload
Request Method:POST
Status Code:400 Bad Request

Response Headers
view source
Access-Control-Allow-Origin:*
Connection:close
Content-Length:67
Content-Type:application/json
Date:Thu, 22 Oct 2015 20:53:52 GMT
Server:Apache/2.2.22 (Debian)
Set-Cookie:PHPSESSID=d9nub0p3h5ert6otd6q7bgtf25; path=/
X-Pad:avoid browser bug

Request Headers
view source
Accept:*/*
Accept-Encoding:gzip, deflate
Accept-Language:en-US,en;q=0.8,it;q=0.6
Connection:keep-alive
Content-Length:5204
Content-Type:text/plain;charset=utf-8  >>>>>>>>>>>> this should be multipart/form-data; boundary=-----WebKitFormBoundaryzRvee2NwIFVAHaxE
Host:api.debian-vm
Origin:http://localhost:4200
Referer:http://localhost:4200/layout-book/FD578D5F-09EF-4B99-9BEB-AA63E4630AD5/1
User-Agent:Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/45.0.2454.85 Safari/537.36
Request Payload
------WebKitFormBoundaryzRvee2NwIFVAHaxE
Content-Disposition: form-data; name="file"; filename="xmark_red.svg"
Content-Type: image/svg+xml

------WebKitFormBoundaryzRvee2NwIFVAHaxE
Content-Disposition: form-data; name="needsThumbnail"

true
------WebKitFormBoundaryzRvee2NwIFVAHaxE--

I realized this may be a bug with pretender and not your lib ...

hey,  i got this bug too,   content-type is always text/plain;charset=utf-8

Strange. I'd love some help tracking this down. Is it Pretender? Mirage?

I just ran into this and it turned out to be an issue with FakeXMLHttpRequest that has been resolved. Upgrading Pretender to 0.12.0 fixed it so you can probably close this.

Nice, thanks for the note!


Generated Python libraries should use google.cloud.future.operation instead of google.gax._OperationFuture

google.cloud.future.operation is in google-cloud-core.

This is similar to the discussion we've been having elsewhere about core and gax, but we should not be introducing dependencies on google.cloud packages in generated Python libraries, which might not be for cloud APIs.

How do we feel about introducing it in the interim until core/gax converge?

I have no objection to that as long there's plan to change the dependency namespace in a way that'll be transparent to users.
FYI @ethanbao, who's working with our non-cloud APIs.

yep, that's the idea as mentioned in the internal doc about the convergence (under 'Concern over the name google.cloud.core')

This appears to be done


Change Weather Module for Example

It seems Microsoft's Weather API has been changed and this means we need to update the example application and Quick Start guide to use a new Weather module:
https://social.msdn.microsoft.com/Forums/en-US/030116bb-401f-4ef7-a21e-ad59d2113a56/microsoft-weather-api

FYI, looks like weather-js has been updated to take this in count. The quick start works ok.

Thanks for the heads up.


Is this boilerplate using F5 grid?

Hello,
I am using Magento 1.9.4 and i wanted to develop the theme with Zurb Foundation. I installed your theme and didn't find any of the grid system or classes on the default templates .phtml files.
Is this a Zurb Foundation 5 based template ?

have a look @ the css files. grid classes are assigned to the native magento classes.

Thanks for your fast response :+1:


Rejected when reviewed on iOS 17.6.1

Apple rejects app updates due to being unable to locate the App Tracking Transparency permission request when reviewed on iOS 17.6.1. Currently using app_tracking_transparency: ^2.0.6 which is the most recent version available.

Could you please check if the example provided with the app_tracking_transparency plugin runs and confirm whether the dialog appears on both the simulator and a connected Apple test device?

@SahidKhan89
I also implemented the initPlugin() as per the code provided and got rejected during Apple's review for the same reason.
https://pub.dev/packages/app_tracking_transparency/example
Upon checking, it worked fine on my iPhone, but on my iPad, the issue occurred as described in the rejection.
However, when I changed the 200 milliseconds in the code to 1000 milliseconds, the problem was resolved, and the Apple review passed.
It may not be a fundamental solution, but for now, I believe this should help you get through the review.


[Cosmos Diagnostics Improvement] Separate RntbdContextNeogiation from ChannelAcquisitionStarted stage

Currently in cosmos diagnostics, the channelAcquisitionStarted stage include the time spent in RntbdContextNeogiation as well, separate them out could give us a better picture of the time spent in each stage

@rinatmini pls take a look at this, thanks!

Assigning to @jeet1995


get_redacted_args should be tolerant of entrypoints without sensitive_variables

The following should not raise an error. Instead it should behave as if no sensitive_variables were specified.
from nameko.containers import ServiceContainer
from nameko.testing.utils import get_extension
from nameko.utils import get_redacted_args
from nameko.web.handlers import HttpRequestHandler, http

class Service(object):
    name = 'foo'

    @http('GET', '/bar')
    def bar(self, request, arg):
        return 'bar'

container = ServiceContainer(Service, {})
entrypoint = get_extension(container, HttpRequestHandler)

print(get_redacted_args(entrypoint, "arg"))

Fixed in https://github.com/nameko/nameko/pull/440


sqlite-net-pcl or SQLite.Net.Core-PCL

Hello @jamesmontemagno
I saw your Video "Motz Codes Live: Let's create a SQLite Database!":
https://www.youtube.com/watch?v=_MX5ZrDAXP8
its a great tutorial, but know after one year, there is these two projects:
https://www.nuget.org/packages/sqlite-net-pcl/
vs
https://www.nuget.org/packages/SQLite.Net.Core-PCL/
and i am still confused.
and i want to use Xamarin.Forms for all devices, so can you give me a suggestion if you can?

https://www.nuget.org/packages/sqlite-net-pcl/ is the official and what I use.


pipe.go: add DialPipeAccessImpLevel

I would like to use impersonation on the server side of the pipe, but I currently cannot because all pipes are connected using the anonymous impersonation level.
This patch adds a new function that provides the ability to explicitly specify the desired impersonation level.
Fixes #297

@helsaawy Thanks for the review! Can you merge this, please?

👋 @msscotb, checking in on this to see if it can be merged.


Event organiser has "Allow IP Video" set to "off"

Can an event oraniser that has a "Messaging policy" with "Allow IP Video" set to "OFF" still record a live event, if the "Live event policy" setting "Who can record an event" is set to "Always record" or "Oganizer can record"?

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: becbf3ca-b88c-b033-a145-9a1af201ced3
Version Independent ID: 41a6a9b5-d3dd-d8c9-9e97-920ff2fd1a24
Content: What are Microsoft Teams live events? - Microsoft Teams
Content Source: Teams/teams-live-events/what-are-teams-live-events.md
Service: msteams
GitHub Login: @LanaChin
Microsoft Alias: v-lanac

@AlexanderSaad thank you for submitting feedback.
I think the best way forward is if you open a service ticket in your tenant so this can get resolved ASAP. Based on the outcome let me know if it is something that can be called out in the docs.
Please follow this link to contact support for business products:https://docs.microsoft.com/office365/admin/contact-support-for-business-products
Please keep us posted here on the resolution so we can feed whatever information you discover into the content.


Argument list too long: recursive header expansion failed

Getting a "Check dependencies" error in Xcode 8 for release/4.0.0-beta-2.
Argument list too long: recursive header expansion failed at .../Carthage/Checkouts/ProcedureKit/Carthage/Build/iOS/ProcedureKitMobile.framework.dSYM/Contents.

Hi @brandonskane - sorry - should have been clearer, there are schemes for Mobile, Mac etc - but nothing in them.
Only ProcedureKit works at the moment. See #398 for details.

Hi @brandonskane - ProcedureKitMobile is now available in beta 3. Gonna close this for now - please comment if you have any other issues 😀


Better readability of code

Hi,
I've tried to analyze few of your files. Sorry for saying that but readability is poor. For example:
https://github.com/SirCmpwn/sway/blob/master/sway/commands/resize.c
Function static bool resize_tiled(int amount, bool use_width)  is too long, there are too many indentation levels, etc.
If you need help with cleanup I can try to find time for this.

Send pull requests for this sort of thing, not issues.


Possibility to disable a whole IXP

Environment

Python version:  Python 3.6.8
Peering Manager version:  v1.1.1-dev

Proposed Functionality
It would be great if we could disable a whole IXP for example during maintenance. We currently connect to the router and deactivate the sessions/the group of sessions by hand but having this option from within peering Manager would be great!

Use Case
If an IXP shuts down ports during maintenance it would be good to deactivate the sessions first.

External Dependencies

I think that we should address this as part of #246 and be able to disable on connection to an IX (or several).

This is no longer block as connection model is now merged.

Closing, all further communication regarding this request will be done via #292.


Mem alloc routine test

Add simple tests for memory allocation routines on host

That's a good addition, thanks. Are the commented out examples things that should work but dont?


johndanz/ch17343/ledger-trezor-address-paging-need-transition

added an animation to the address rows to indicate that they are loading, the rows will now pulse/fade in and out until an address/balance is loaded.

Coverage remained the same at 56.462% when pulling a7783a07aba510781e6e4af2a45cea6dd4fe9d95 on johndanz/ch17343/ledger-trezor-address-paging-need-transition into 8959c2a8e561a6e32083a59f4cd91e5962aacd2b on master.

Need same pulsing behavior when paging forward and backward.


Run metadata-service as user 10001:10001

Also use alpine 3.17 instead of the datestamp based releases.

Codecov Report

Merging #82 (554e2ef) into main (ae844c1) will not change coverage.
The diff coverage is n/a.

:mega: This organization is not using Codecov’s GitHub App Integration. We recommend you install it so Codecov can continue to function properly for your repositories. Learn more
@@           Coverage Diff           @@
##             main      #82   +/-   ##
=======================================
  Coverage   77.54%   77.54%
=======================================
  Files          10       10
  Lines         935      935
=======================================
  Hits          725      725
  Misses        162      162
  Partials       48       48

Flag
Coverage Δ

unittests
77.54% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.


⚠ Bofrost.at has degraded performance

In b0276ab, Bofrost.at (https://www.bofrost.at) experienced degraded performance:

HTTP code: 200
Response time: 1217 ms

Resolved: Bofrost.at performance has improved in 77e6cd4 after 6 minutes.


Cert altnames

Prerequisites

[x] Put an X between the brackets on this line if you have done all of the following:

Checked that your issue isn't already filed: https://github.com/icetee/remote-ftp/issues

Description
Impossible to connect to my ftp : https://i.imgur.com/WlHRcZ6.gif
Steps to Reproduce

Create a new .ftpconfig config.
Fill each field correctly (good logins)
Try to connect to FTP

Expected behavior: /
Actual behavior: Problem with FTP connection
Reproduces how often: Everytime except with others FTP (not with NiHost)
Versions
Atom version: 1.21.2
System version: macOS 10.13.1
Additional Information
/

Resolved. (I changed FTP server)


Compression of saved datas

Testing to see if compression is necessary, and will it affect save/load time drastically

Already using built-in EncodeArray function


Investigate Keycloak not retaining client secret on new installs

The hexa-orchestrator realm that is auto-configured has a pre-configured oauth client credential however the password is being reset to "*******".
Figure out how to fix this or how to run a script to set up ENV variables for docker-compse.

No fix required because the export has to be done using the kc.sh shell script rather than the web ui.


Migrations guide

We need a migrations guide.
This issue it to note what needs to go into it.

Replacement of stop()/halt() as per https://github.com/slimphp/Slim/issues/1266

Lots of other things have been removed, too. Will add more as I think of them.

Hooks

Removal of HTTP caching methods into separate components.

Relocation of \Slim\App::redirect into the Response class.

Change in middleware signature
//From
class AuthMiddleware extends \Slim\Middleware
{
    public function call()
    { }
}

Too
$app->add(function ($request,$response,$next) {});

HTTP request and response changes to satisfy PSR-7

Removal of some components from core
Flash Messages
Cookies

urlFor() is in Router now

New \Slim\App class name, and new \Slim\App constructor signature.

New route callback signature: request, response, args

New minimum PHP version required.

Removal of crypto

How to read and parse request bodies based on content type

New Route Callback Signature
$app->get('/', function (\Psr\Http\Message\ServerRequestInterface $request,
                             \Psr\Http\Message\ResponseInterface $response, $args) {
//do stuff!
});

new url defintion for parameters

Read and parse request bodies based on content type:
``php
require 'vendor/autoload.php';
$app = new Slim\App();
//You want to make sure this one is as close to app->run
//Middlewares are run Last In First Executed
$app->add(function (\Psr\Http\Message\ServerRequestInterface $request,
\Psr\Http\Message\ResponseInterface $response $response, $next) {
switch($request->getHeader('Content-Type')) {
case 'your-content-type' : { //Keep in mind slim does define some basic parsers.
}
default : {
$response->withStatusCode(400)->withBody("Unsupported Content-Type");
}
}
return $response;
});
$app->run();

Hooks:  Should be converted into Middleware.
Route Middleware is added differently.
Previously
$app->get('/', $mw, $mw2, function () {});

Now
$app->get('/', function () {})->add($mw2)->add($mw);

To get the container inside a route function, IE to replace the DI from slim 2.
$app->get('/', function () {
    $container = $this->getContainer();
});

@akrabat @codeguy google doc for this?

No. It's part of https://github.com/slimphp/Slim-Documentation/tree/gh-pages

Optional Route Parameters need to be solidified

urlFor => pathFor
Also, pathFor prepends a '/', so to create a fully qualified URL, you now need to do this:
    $router = $this->router;
    $uri = $request->getUri();
    $url = $uri->getScheme() . '://' . $uri->getHost()
            . $uri->getPort() ? ':' . $uri->getPort() : ''
            . rtrim($uri->getBasePath(), '/')
            . $router->pathFor('news-archive', ['year'=>'2015'], ['foo' => 'bar']);

SLIM MIGRATION GUIDE   June 27th 2015   Glenn Eggleton<EMAIL_ADDRESS>Removal of Stop/Halt
Slim Core has removed Stop/Halt.
In your applications, you should transition to using the withStatusCode() and withBody()
Example In Slim 2.x:
$app->get(‘/’, function () {  $app->halt(400, ‘Bad Request’); });

And now in Slim 3.x:
$app->get(‘/’, function ($req, $res, $args) { return $res->withStatus(400)->withBody(“Bad Request”); });

Hooks
Slim v3 no longer has the concept of hooks. Hooks were removed as they duplicate the functionality already present in middlewares. You should be able to easily convert your Hook code into Middleware code.
Removal HTTP Cache
Slim v3 no longer ships with HTTP Cache methods in core. It has been moved to its own separate repo (https://github.com/slimphp/Slim-HttpCache )
Changed Redirect
In Slim v2.x one would use the helper function $app->redirect(); to trigger a redirect request.
In Slim v3.x one can do the same with using the Response class like so.
Example:
$app->get(‘/’, function ($req, $res, $args) {
    return $res->withStatus(301)->withHeader(“Location”, “yournewuri”);
});

Middleware
Signature
The middleware signature has changed from a class to a function
New signature: php $app->add(function ($req, $res, $next) {});
Execution
Application middleware is executed as Last In First Executed (LIFE)
Flash Messages
In v3.0 the concept of flash messages has been removed. There currently is no planned feature for this, but could likely be a part of the Cookies package
Cookies
In v3.0 cookies has been removed from core and moved to a separate component  See (https://github.com/slimphp/Slim-Http-Cookies)
Removal of Crypto
In v3.0 we have removed the dependency for crypto in core
PHP Version
Slim v3.0 requires php 5.4+
Route Callbacks
In v3.0 we have adopted a new callback signature
$app->get('/', function (\Psr\Http\Message\ServerRequestInterface $request,
\Psr\Http\Message\ResponseInterface $response, $args) {
//do stuff!
});

New Router
Slim now utilizes a new more powerful router ( https://github.com/nikic/FastRoute )!
Route Middleware
The syntax for adding route middleware has changed slightly.
In v3.0:
php $app->get(…)->add($mw2)->add($mw1);

How about putting the migration guide on wiki?

The wiki is not really being maintaned ...
Migration guide is in the v3 docs:
http://www.slimframework.com/docs/start/upgrade.html

@geggleto there is helper method withRedirect for redirects :+1:
Also php version: 5.5+

@dopesong Yeah I need to update the migrations docs this week.

Add Page to explain how the Container works with callables
Add Page to explain what the Immutability of the PSR-7 objects means

Added issues to Slim-Website.


directly vendor schema files

Issue
Pypi packages apparently cannot depend on git+ dependencies.
https://github.com/canonical/cos-lib/actions/runs/12252877996/job/34180522427
charm-relation-interfaces is not on pypi (yet)

Solution
Instead of installing 'interfaces' from git, download them in this repository tree for the time being.
This is a short term workaround, not a solution.
If charm-relation-interfaces is not to be on pypi, a better approach would be to pull the schemas automatically from CI every time there's a merge on CRI main.

@PietroPasotti what was the reason for adding cryptography as a dependency in pyproject.toml? As of the latest cosl release, every charm that pulls in cosl will need to include a Rust toolchain during the packing process to compile cryptography, or add an entry for cryptography in charm-binary-python-packages.


Investigate using SO_TIMESTAMP for packet timing

Per this thread, we should be able to get more accurate RTT results if we use the Linux kernel to get timestamps (depending on the platform of course).

Related: https://github.com/golang/go/issues/47926

Would be very interested in the progress of this feature!


Better results for communes

If a user is looking for a commune name, it would be better that the first result is the Etablissement of the commune instead of results of other Etablissements which might include the commune name in their name.

Implemented in 144470b3826cccd751e1a17c997802bd709cc3f1


Improve display of health check solution message when it contains a SOQL query

As per this hub thread: https://powerofus.force.com/0D58000002oVW9G
When displaying a SOQL query in a Health Check solution message, the query should be made easier to copy by removing wrapping quotes and offsetting the SOQL query text.

**lurch: add

Tracking W-010840

This has been marked as "Never" internally.


x/tools/go/gcexportdata: simplify implementation assuming go >= 1.21

This is a tracking issue to simplify the implementation of x/tools/{go/gcexportdata,internal/exportdata} since the acceptance of proposal #68898. These can now assume exportdata only comes from go versions >= 1.21.

Related Issues

x/tools/go/gcimporter: update export data format version #17734 (closed)

(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.)


Cope with the upstream Lean 3 repository rename.

Previously trying to run this (with newer elans) would say there was no binary package for Linux, seemingly because it was trying against leanprover/lean and not following the redirect, but this seems to work now here (for me in Gitpod) after this change.

Fixed by #40


document agent-server communication options are not applicable to AWS lambda extension

Due to architecture for AWS Lambda agent options related to agent-server communication such as verify_server_cert do not apply because agent communicates with the extension, not the APM server. This is not properly documented today. The Configuration options page redirects to generic APM agent options with no caveats or restrictions.
Related: https://github.com/elastic/apm-aws-lambda/issues/186

@bmorelli25 could you take a look at how to reflect this in the docs?


[ENG-8956][Change] Change tsconfig.json options for easier development

Changed noUnusedLocals and noUnusedParameters to false for easier local development and experimenting.
These checks do not run during local development. Instead, eslint catches these cases on github.

Why
Please describe the motivation for this PR, and link to relevant GitHub issues, forums posts, or feature requests.
How
How did you build this feature or fix this bug and why?
Test Plan
Please describe how you tested this change and how a reviewer could reproduce your test, especially if this PR does not include automated tests! If possible, please also provide terminal output and/or screenshots demonstrating your test/reproduction.

/changelog chore Skip noUnusedLocals and noUnusedParameters during local development

/changelog-entry chore Skip noUnusedLocals and noUnusedParameters during local development


Detect code in private constructor for utility classes and suggest the removal

What it does
A private constructor can only be called from inside a class. This is used to prevent the
instantiation of a class which only has static methods.
Some IDEs add a throw Exception inside the private constructor. That code is there to prevent
someone from calling the constructor through reflections (even though it is private), but this is
unnecessary here. It will just result in more code, might introduce other mistakes like having a bad constant name for the exception message at the top of the class.
What needs to be considered:

the private constructor must not be called from anywhere inside the class (for example in a factory method)

Lint Name
UNREACHABLE_CODE
Category
complexity
Example
class Utils {
    private Utils() {
        throw new AssertionError("do not call me");
    }
}

Could be written as:
class Utils {
    private Utils() {
    }
}

I know you already implemented the check, but at least with our lecture throws in those constructors are fine, and actually wanted (though not required)


readme: fix typo (aginst > against)

ah! third time's the charm :sweat_smile:

Thanks :sweat_smile:


Skip test if irun not available

This prevents the tests from failing when testing on a local machine where ncsim isn't available. Ideally we can remove this once we get the iverilog version of the test (since we can expect this to be installable in broader contexts).

Pull Request Test Coverage Report for Build 230

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 95.035%

Totals

Change from base Build 225:
0.0%

Covered Lines:
134

Relevant Lines:
141

💛  - Coveralls


Replace phantomjs with chromium headless

Originally opened as a sumaform issue: https://github.com/moio/sumaform/issues/146

thx @moio @kkaempf , i don't see any hurry for that, since chromium headless is running on beta, and we need absolutely stable test with screenshot.
we need to wait for this. setting in  longterm milestone

https://developers.google.com/web/updates/2017/04/headless-chrome is out since some months
Capybara support is also in
We should probably give it a try

@Mallozup @kkaempf @moio
Well, it might be less efforts to update our phantomjs version first.
Current phantomJS version is 2.1.1 and we are still using 2.0.0, while a version 2.5.0 is in beta state. I have seen changes in the source code that would probably enable us to solve some testsuite problems -- at least the issues where we do not see in phantomJS the changes to the DOM tree. phantomJS is not so much updated anymore, but it is stable, while we might hit all youth problems of a headless chromium.
Of course headless chromium is the long term solution (we would have same browser in testsuite and at users), but I would vote too for not hurrying too much.

I would go for a quick and dirty test with Chromium. If it looks difficult, phantomjs could be plan B.
Reasoning is: I do not expect big difficulties (but of course can be wrong)

https://github.com/SUSE/spacewalk-testsuite-base/pull/442

this is not something that can be done from my side. Afaik this is technical debt.

@moio what about moving this issue to "galaxy" repo? Let's have issues in only one place.

Exists already in spacewalk the task. Closing


[BUG] Generator doesn't validate config values

So, title is pretty self descriptive, but right now user can put whatever they want in pretty much any config field and it won't throw an error, but will cause troubles, super dumb example: "wordbreak_char": "hello world" is "valid" config, while its not
This issue is just a reminder to add config value validation

Should also catch wrong json syntax and pretty-print it to avoid stack trace dump

This isn't really a bug, so I created a new tag for usability issues


Deal with increased costs for Chargeprice API

For a couple years now, we have been using the Chargeprice.app API for our price comparison feature in Europe. Being a non-commercial open source project and also having contributed to Chargeprice's open source web frontend, the price I paid for this API was significantly reduced compared to commercial customers. Unfortunately, this is going to change now - due to the increased effort for maintaining the data, the monthly price will be doubled now and potentially increase further in the future.
The current volume of donations is about the same as the new price of the API, so basically all donations would now be going to Chargeprice. This is not viable in the long term, especially if prices will further increase.
With the next update, I am going to slightly increase the frequency of dialogs asking for donations and see how things evolve over the next few months. If this doesn't help, I will have to remove the native integration of Chargeprice. In that case, I could revert back to linking to their own website or app.
A long-term solution could be to run our own source for pricing data under an open license. This could be either filled from community contributions or scraped from the providers' APIs (where reasonably possible). But I don't think I have enough time to be the one who builds and maintains this alone.
GoingElectric.de do also have a database of payment providers (https://www.goingelectric.de/stromtankstellen/anbieter/), but it is not accessible through their public API and therefore not permitted to use for third-party apps according to their API terms of service. The data are also in a less useful format, as the prices are filled in using free-text fields.

i just did a donation. :-)

Hmm, yeah. It is a possibility, though it would be at least slightly against the open-source spirit of the app... And it would require me to maintain two separate payment and validation systems for Google Play and F-Droid (or, the F-Droid version would lose access to Chargeprice).
The pricing of the Chargeprice data also (at least currently) does not depend on the number of users - so to find a sensible price for a subscription I would have to guess how many users would want to pay for it.


Bar Button to toggle pm-powersave issue/question

The basic goal of what I am trying to accomplish is to have a button on the bar that toggles pm-powersave the issue I am running into is two fold. First I don't want to have my script run on an interval, I just want it to execute when the button is pressed. Second currently when I link my module the bar seems to remove other modules, specifically the modules aligned to the right, they just become invisible (pulseaudio, batery, and date modules).
if you need any more information about my config please ask :+1:
additional question:
is there a way to save the state of the script on i3 reload without re-runing the script
;[module/powsave]
;type = custom/script
;label = powSaver:%output%
;format = %{A1:~/.config/polybar/powMode.sh}  %{A}
;exec = ~/.config/polybar/powMode.sh
;interval = 1000000
bs@bs-ubuntu:~/.config/polybar$ cat powMode.sh
#!/bin/bash

#polybar script for switching powersaving mode

if [ -z "$pmMode" ]; then
  export pmMode="false"
  #sudo pm-powersave false
fi

if [ $pmMode == "false" ]; then
  #sudo pm-powersave true
  pmMode="true"
  echo "ON"
else
  #sudo pm-powersave false
  pmMode="false"
  echo "OFF"
fi

There currently is no built-in way to run the exec script only when you click the modules. If you want to achieve this, you will have to program the update functionality into the script. The easiest approach would probably be to use a non-terminating script with tail = true and in that script you listen for some signal (preferably SIGUSR1) which would make the script update its output, similar to the date example in the wiki.
As for the other issue, the cause is likely that your action tag is malformed: %{A1:~/.config/polybar/powMode.sh} %{A} there is supposed to be a colon after the command.


Mobile Network Content Validation Issue for github.io website

Section links:

https://azuresdkdocs.blob.core.windows.net/$web/python/azure-mgmt-mobilenetwork/3.3.0/index.html
https://azuresdkdocs.blob.core.windows.net/$web/python/azure-mgmt-mobilenetwork/3.3.0/azure.mgmt.mobilenetwork.operations.html

Reason:
Format validation Issue: Extra symbols _ or -.

Section links:

https://azuresdkdocs.blob.core.windows.net/$web/python/azure-mgmt-mobilenetwork/3.3.0/genindex.html
https://azuresdkdocs.blob.core.windows.net/$web/python/azure-mgmt-mobilenetwork/3.3.0/azure.mgmt.mobilenetwork.models.html

Reason:
Format validation Issue: Many text in this page exceed the page size.

Section links:

https://azuresdkdocs.blob.core.windows.net/$web/python/azure-mgmt-mobilenetwork/3.3.0/azure.mgmt.mobilenetwork.models.html#azure.mgmt.mobilenetwork.models.UeInfo4G
https://azuresdkdocs.blob.core.windows.net/$web/python/azure-mgmt-mobilenetwork/3.3.0/azure.mgmt.mobilenetwork.models.html#azure.mgmt.mobilenetwork.models.UeInfo5G

Reason:
Format validation Issue: Missing description.

Section links:

https://azuresdkdocs.blob.core.windows.net/$web/python/azure-mgmt-mobilenetwork/3.3.0/azure.mgmt.mobilenetwork.operations.html

Reason:
Typing annotation Issue: Please unify the format, update to *args:Any, **kwargs:Any or *args, **kwargs.
@rohit-ganguly, @lmazuel for notification.

Close this issue as we'll put it into a summarzied one.


Python update

Update System Requirements

Python 3.8 and newer versions are not yet fully supported, since there are no pre-built Python packages for Tensorflow 2.5 and <2 and other related software. We expect to unconditionally support Python 3.8 once all processors and models are upgraded to work with a more recent Tensorflow.

@bertsky How up-to-date is that statement?

How up-to-date is that statement?

Not up to date at all. And with https://github.com/OCR-D/ocrd_all/pull/362 it does in fact work with all modules.
But we can simply replace 3.8 in that statement with 3.9 – it is correct that we have no TF1 from then on.

But we can simply replace 3.8 in that statement with 3.9 – it is correct that we have no TF1 from then on.

To sum it up for Python, does that mean, our target platform is 3.7, at the moment it works with 3.8 but not with 3.9?


add feature

closes https://github.com/MicrosoftDocs/OfficeDocs-SkypeForBusiness/issues/10171
source https://support.microsoft.com/en-au/office/what-s-new-in-microsoft-teams-devices-eabf4d81-acdd-4b23-afa1-9ee47bb7c5e2#ID0EBD=Teams_displays
@tonysmit Tony, Can we add some instructions on how to enable and configure this feature? Thanks

@tonysmit
PR has been copyedited and is ready for final review, could you please check and merge? Thanks!


Enforce PEP-8 guidelines all over the Python Codebase

💥 Proposal
With the growing number of scripts, it would be a good idea to ensure that PEP-8 guidelines are satisfied.
Have you read the Contributing Guidelines on Pull Requests?
Yup

Hey @ankitapuri Can you assign this to me 😄


Enable compact-after-snapshot-load make ardb crashed

When set it to true, and import  dump.rdb (8GB), after load rdb successfully, ardb start to do compaction and crashed.
#0  0x00007f5184eb4428 in __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:54
#1  0x00007f5184eb602a in __GI_abort () at abort.c:89
#2  0x00007f5184ef67ea in __libc_message (do_abort=do_abort@entry=1, fmt=fmt@entry=0x7f518500d8a2 "*** %s ***: %s terminated\n")
    at ../sysdeps/posix/libc_fatal.c:175
#3  0x00007f5184f9756c in __GI___fortify_fail (msg=<optimized out>, msg@entry=0x7f518500d884 "stack smashing detected")
    at fortify_fail.c:37
#4  0x00007f5184f97510 in __stack_chk_fail () at stack_chk_fail.c:28
#5  0x0000000000572756 in ardb::RocksDBLogger::Logv (this=<optimized out>, log_level=<optimized out>,
    format=0x7c00a8 "[%s] Compaction start summary: %s\n", ap=0x7f517d5fbb10) at db/rocksdb/rocksdb_engine.cpp:222
#6  0x000000000064d328 in rocksdb::Log (log_level=log_level@entry=rocksdb::INFO_LEVEL, info_log=...,
    format=format@entry=0x7c00a8 "[%s] Compaction start summary: %s\n") at util/env.cc:199
#7  0x00000000006b5364 in rocksdb::CompactionJob::LogCompaction (this=this@entry=0x7f517d5fc970) at db/compaction_job.cc:1365
#8  0x00000000006ba362 in rocksdb::CompactionJob::Run (this=this@entry=0x7f517d5fc970) at db/compaction_job.cc:518
#9  0x0000000000592e92 in rocksdb::DBImpl::BackgroundCompaction (this=this@entry=0x7f51849f9000,
    made_progress=made_progress@entry=0x7f517d5fd0bf, job_context=job_context@entry=0x7f517d5fd0f0,
    log_buffer=log_buffer@entry=0x7f517d5fd2f0, arg=arg@entry=0x7f516d1fdc00) at db/db_impl.cc:3615
#10 0x00000000005a267e in rocksdb::DBImpl::BackgroundCallCompaction (this=0x7f51849f9000, arg=0x7f516d1fdc00)
    at db/db_impl.cc:3313
#11 0x000000000068beb1 in rocksdb::ThreadPoolImpl::BGThread (this=this@entry=0x7f51848bf800, thread_id=thread_id@entry=10)
    at util/threadpool_imp.cc:229
#12 0x000000000068bfe3 in rocksdb::BGThreadWrapper (arg=0x7f5184843200) at util/threadpool_imp.cc:253
#13 0x00007f5185cf86ba in start_thread (arg=0x7f517d5fe700) at pthread_create.c:333
#14 0x00007f5184f8582d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109

frame 10:
info locals:
l = {mutex_ = 0x7f51849f94b0}
pending_outputs_inserted_elem = <optimized out>
s = {code_ = rocksdb::Status::kOk, subcode_ = rocksdb::Status::kNone, state_ = 0x0, static msgs = {0x7c7c64 "",
    0x7bdac8 "Timeout Acquiring Mutex", 0x7bdae0 "Timeout waiting to lock key",
    0x7bdb18 "Failed to acquire lock due to max_num_locks limit", 0x7bdafc "No space left on device", 0x0}}
made_progress = false
m = 0x7f516d1fdc00
job_context = {job_id = 4, full_scan_candidate_files = std::vector of length 0, capacity 0,
  sst_live = std::vector of length 0, capacity 0, sst_delete_files = std::vector of length 0, capacity 0,
  log_delete_files = std::vector of length 0, capacity 0, log_recycle_files = std::vector of length 0, capacity 0,
  manifest_delete_files = std::vector of length 0, capacity 0, memtables_to_free = {num_stack_items_ = 0, values_ = {0x0, 0x0,
      0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, vect_ = std::vector of length 0, capacity 0}, superversions_to_free = {
    num_stack_items_ = 0, values_ = {0x7f5184a00000, 0x1, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0},
    vect_ = std::vector of length 0, capacity 0}, logs_to_free = {num_stack_items_ = 0, values_ = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
      0x0, 0x0}, vect_ = std::vector of length 0, capacity 0}, new_superversion = 0x7f517be34300, manifest_file_number = 0,
  pending_manifest_file_number = 0, log_number = 0, prev_log_number = 0, min_pending_output = 0, prev_total_log_size = 0,
  num_alive_log_files = 0, size_log_to_delete = 0}
log_buffer = {log_level_ = rocksdb::INFO_LEVEL, info_log_ = 0x7f51849bae40, arena_ = {<rocksdb::Allocator> = {
      _vptr.Allocator = 0x7b60a0 <vtable for rocksdb::Arena+16>}, static kInlineSize = 2048, static kMinBlockSize = 4096,
    static kMaxBlockSize =<PHONE_NUMBER>,
    inline_block_ = "\272g\255X\000\000\000\000\251q\000\000\000\000\000\000[0] Manual compaction from level-0 to level-1 from (begin) .. (end); will stop at (end)\n", '\000' <repeats 1160 times>..., kBlockSize = 4096,
    blocks_ = std::vector of length 0, capacity 0, huge_blocks_ = std::vector of length 0, capacity 0, irregular_block_num = 0,
    unaligned_alloc_ptr_ = 0x7f517d5fdb08 "", aligned_alloc_ptr_ = 0x7f517d5fd508 "", alloc_bytes_remaining_ = 1536,
    hugetlb_size_ = 0, blocks_memory_ = 2048}, logs_ = {num_stack_items_ = 0, values_ = {0x7f517d5fd308, 0x7f51848bf810, 0x0,
      0x7f5185cfc4ff <__GI___pthread_mutex_unlock+63>, 0x7f517be0d000, 0x7f51849bf110,
      0x68af76 <std::_Hashtable<rocksdb::ThreadStatusData*, rocksdb::ThreadStatusData*, std::allocator<rocksdb::ThreadStatusData*>, std::__detail::_Identity, std::equal_to<rocksdb::ThreadStatusData*>, std::hash<rocksdb::ThreadStatusData*>, std::__detail::_Mod_range_hashing, std::__detail::_Default_ranged_hash, std::__detail::_Prime_rehash_policy, std::__detail::_Hashtable_traits<false, true, true> >::_M_rehash(unsigned long, unsigned long const&)+182>, 0xb}, vect_ = std::vector of length 0, capacity 0}}

If I manually do compactall, it works fine.

seems use too many  log buffer to corrupt current stack.  fixed in latest commit.

Works now, thanks


PHP 8.2: Deprecated ${} string interpolation.

${var} String Interpolation Deprecated
PHP has always supported string variable interpolation with "foo {$bar}" pattern, and along with an alternative syntax that the dollar sign is placed outside the curly braces (e.g. "foo ${bar}").
In PHP 8.2, the alternative syntax of placing the dollar sign outside the curly braces is deprecated.

Deprecated in PHP 8.2
Recommended syntax for PHP 8.2

Hello ${name};
Hello {$name}

echo "Hello ${$var}";
echo "Hello {$var}";

Source: https://php.watch/versions/8.2
For detailed information see PHP RFC: https://wiki.php.net/rfc/deprecate_dollar_brace_string_interpolation

Thanks for your report, we have prepared a change!

@rkoopmans Thanks for the change. LGTM and I am looking forward for the release. :)

@rkoopmans AFAICS you merged the changes to master and changed the bumped the version in the code, but there is a tag missing to get the release f.e. via packagist.
Mind to add the 1.6.1 tag? :)
If done, this issues can be closed 👍


AKPlayer. currentTime issue

Hi everyone. I have an issue with AkPlayer's currentTime. If I try connect AKVariSpeed to AKPlayer and then use AKVariSpeed like output:
let speed = AKVariSpeed()
AudioKit.output = speed
then during playback I see that AKPlayer's currentTime changes quicker than usually (in 2 times faster). Although I change a rate of AKVariSpeed only between 0.997-1.01

Usually multiples of 2 means something to do with stereo not being handled properly.

Can you share a project demonstrating this?

Seems like I found a problem of such behaviour. It is on my side. Thanks


Scheduler leaks jobs

In multiple situations, rq-scheduler will leave its jobs in redis and never remove them again, effectively leaking redis storage.
Ways to make this happen:

Jobs without result_ttl:

Call schedule() with interval or cron() with any parameters and pass a repeat to either of these

All jobs:

Schedule a job in any way and cancel() it before it was enqeued

So, what happens if you use schedule() with interval but no result_ttl and no repeat?
The reason I ask is because, anecdotally, setting any result_ttl on a schedule(interval=x) job results in the scheduler ceasing to schedule that job after a period of time.


Fix the return order of batched requests

Type

[ ] Refactor
[ ] Feature
[x] Bug Fix
[ ] Optimization
[ ] Documentation Update

Description

Related

Related Issue #
Closes #

I don't think I understand the problem and by consequence the solution, would you mind writing a test?

While it works and looks good to me, I'm not sure why the behaviour changed after Mike's request refactor.
I'll defer to @mikearnaldi to review for this one :)

I didn't touch that function

While it works and looks good to me, I'm not sure why the behaviour changed after Mike's request refactor.
I'll defer to @mikearnaldi to review for this one :)

I didn't touch that function

I was pretty convinced this was my error in the original port :) We just probably never noticed the issue before.

The issue basically was - if you send a set of batched requests that were received as follows:
Request 1 -> Request 2 -> Request 3

the results were being returned as:
Result 3 -> Result 2 -> Result 1

We tracked down the inadvertent reversal of results to this method which was combining results in reverse order instead of the correct order.
I'll write a test in a separate PR - apologies for merging before seeing your messages.


Labels cause e2e tests to fail via accessibility errors [9]

Describe the Bug:
Probability (how likely the bug is to happen, scored from 1-5): 4
(For example, probability of 5 is something like "it happens to all users every time they log in."
Probability of 1 "only happens to certain users when a really specific and unlikely path is followed.")
Effect (how bad the bug is when it does happen, scored from 1-5): 5
(For example, effect of 5 is "the entire app crashes and makes it unusable for all users" or "the bug causes the wrong data to be saved, with critical information (e.g. payment) being affected."
Effect of 1 is "It makes some styling look a little bit weird.")
Steps to reproduce the behaviour:
There is an assertion and wait statement near https://github.com/bcgov/cas-cif/blob/develop/app/cypress/integration/cif/project-revision/edit-project-revision.spec.js#L121 .  Without these the e2e throws accessibility errors.  These errors are caused by the rendering of the label of on track, etc.
Screenshots:
Additional information:

OS: [e.g. iOS]
Browser: [e.g. chrome, safari]
Version: [e.g. 22]
Additional context

Hey @gurjmatharu! I've removed the wait command and it's not causing an issue on my end; Can you try that on your end as well to see if this issue still exists?!

@LindsayMacfarlane Moved this bug into Accepted by PO or Dev as it contains only code changes and nothing to test.


Recommended way to override parts of a formatter

I've been fiddling with conform.nvim and I wonder if there is a recommended way to do the following:
Let's say there are 2 directories a and b. In a is a configuration file for prettier. In b there is no configuration for prettier. When I am editing a buffer that is within a I would like prettier to use the configuration file in a and change directory to there -- while also using the current definition for prettier for all other fields (plus I'd probably just assume use the same arguments as are in the defaults, but just prepending --config=). If I'm in b (or really anywhere else) I would like the defaults. I have been unable to come up with a satisfactory way to do this. What is recommended?
Have you considered opening up Discussions for this project? This question seems more appropriate to there.

use the configuration file in a and change directory to there

I'm a little confused by this because prettier should already run the command from the root directory that contains a config file
https://github.com/stevearc/conform.nvim/blob/bf68b4a987231b18018f9621cfb15670a9a681b3/lua/conform/formatters/prettier.lua#L14-L27
And prettier should automatically pick up that config file with no commandline arguments required.
Are you not seeing this behavior, in which case there is a bug I need to fix, or is your situation somehow different (e.g. nonstandard config file name)? Happy to provide some sample code on the best way to configure the formatter in different directories, but knowing more about the exact scenario will help.
I've tried opening up Discussions in a few of my other plugins, but I found that some people would report bugs there, bypassing the bug report issue template and forcing me to do the whole "what's your system, what are your logs, do you have a repro". I'd rather just use issues, and I'm happy to take questions like this in an issue!

In this particular case it is a non-standard config file. I don't want to get bogged down in the particulars of a specific formatter though. I have similar, but not necessarily the same, problems with other formatters.
An easy one was shfmt. For me I always need it to have the same arguments. Those arguments are completely different from the default arguments provided by conform. So I just do this:
local shfmt = require 'conform.formatters.shfmt'
shfmt.args = function()
  return { '-i=4', '-ci', '-s', '-bn' }
end

Similar to nvim-lint.
I'm sorry to hear about the discussions. I like that feature but understand your issues with it.
Also, thank you for oil.nvim. I love it and use it every day.

I think probably the thing you're missing (because it's not properly documented) is that the functions have a context parameter that you can use. So for example, to set the arguments based on whether your custom config file is present:
require("conform.formatters.prettier").args = function(ctx)
  local args = { "--stdin-filepath", "$FILENAME" }
  local found = vim.fs.find(".custom-config.json", { upward = true, path = ctx.dirname })[1]
  if found then
    vim.list_extend(args, { "--config", found })
  end
  return args
end

For changing the working directory, you can do that by modifying the cwd property
require("conform.formatters.prettier").cwd = require("conform.util").root_file({
  ".custom-config.json",
  -- These are the builtins
  ".prettierrc",
  ".prettierrc.json",
  ".prettierrc.yml",
  ".prettierrc.yaml",
  ".prettierrc.json5",
  ".prettierrc.js",
  ".prettierrc.cjs",
  ".prettierrc.toml",
  "prettier.config.js",
  "prettier.config.cjs",
  "package.json",
})

There is another approach as well: I just made a change so that the buffer number will be passed in to the config function, if your config is defined as a function. This allows something like this:
require("conform").formatters.prettier = function(bufnr)
  local bufname = vim.api.nvim_buf_get_name(bufnr)
  local config = vim.fs.find(".custom-config.json", { upward = true, path = bufname })[1]
  local default = require("conform.formatters.prettier")
  if config then
    return vim.tbl_deep_extend("force", default, {
      args = { "--stdin-filepath", "$FILENAME", "--config", config },
      cwd = function()
        return vim.fs.dirname(config)
      end,
    })
  end
end

Glad to hear you like oil.nvim!

Is there a way to do it where I don't have to copy the current args from the formatter defaults? That seems error prone since those could change. I've tried mutating args but I always end up changing the value of the default ... so the next time what I prepended is doubled, and then tripled, so on.

I would argue that it's actually not as error prone as you would think. The only times when I would expect the args to update is if a new version of a CLI tool comes out with backwards-incompatible changes, or with some new feature that needs to be enabled. But in that scenario, you may not even want those changes because you may be using an older version of that tool. Fundamentally, if you know what formatter you're using I think you should be completely comfortable specifying the args yourself. That's just my opinion, though.
If you do want to re-use the built-in args, you can do that:
local prettier = require("conform.formatters.prettier")
local default_args = prettier.args
prettier.args = function(ctx)
  local found = vim.fs.find(".custom-config.json", { upward = true, path = ctx.dirname })[1]
  if found then
    vim.list_extend({ "--config", found }, default_args)
  end
  return default_args
end

Fair enough. Thank you for your help.
I'm still working through some things, but I have noticed that formatters can fail and there is no notification of this fact (that I can tell).  Is this a bug?

This is because some formatters are very noisy. For example, if you have a syntax error stylua will fail and provide a lot of output. I am undecided on this. I could make it notify on error unless you pass in quiet = true, but my concern is that for many users I've just created a chore where they get annoyed by the noise, have to look up the docs, and set quiet = true. I could make quiet = true the default, but there are other useful notifications that I really think shouldn't be silenced by default.
My hope with the current configuration was that if a formatter isn't working you'll check the logs. That might be too onerous. Would it help if I put the last few lines of the logfile in the :ConformInfo panel?

The problem I run into is that I don't often notice whether the formatter is working or not until quite some time after it has stopped working. I like the ConformInfo panel (I've used it a lot testing some new formatters), but it doesn't tell me that the formatter is failing at the time it starts to fail. I have to know that it is failing to look there. Or just happen on it by chance.  What about a generic error/warning message: "Formatter f is failing. Check logs for more information."?

What do you think of #16 as a solution?

What do you think of #16 as a solution?

That's great. I like it a lot.


Duplicate "onLoaded" for Singleton Pattern

📚 What are you trying to do?
I have a Vue component that loads a 3rd party script with useScript. This script adds it's interface to the window of the page and upon the script being loaded I need to invoke one of it's methods immediate (e.g. initialization of the script).
I've been able to do this by leverage the onLoaded return from useScript to then access window and invoke the method just fine.
However, when my Vue component has multiple instances in the page; the onLoaded is executed multiple times; once for each component. The net effect is that the initialization routine of the 3rd party scripts runs multiple times; once for each instance of the components.
I suspect I'm misunderstanding something about the singleton pattern; I can confirm only a single script tag is injected despite the presence of multiple useScript calls on the page (e.g. multiple vue components). Perhaps there's another approach I'm supposed to take to scaffold this?
Note that I cannot use a "Global" approach here as only some pages on my site would have these Vue components.
🔍 What have you tried?
I'm tried to see if there's a reliable way to detect which Vue component instance I'm in within my onLoaded callback; theory was to simply only do the initialization methods on "index 0" or equivalent. Unfortunately, I haven't been able to find how to add such details to the onLoaded callback.
ℹ Additional context
No response

Hi, there are many solutions here. I can provide the most help if you tell me which third party you're integrating.
One option would be to register the script in a Nuxt plugin with a manual trigger and a single onLoaded then within your components, you would simply trigger the load. I may consider adding in a onLoadedSingleton function if there's a valid use case.
// plugins/script.ts
import { useScriptFoo } from "~/utils/scripts";

export default defineNuxtPlugin({
  setup() {
    const { onLoaded } = useScriptFoo()
    onLoaded(() => {
      // do something
    })
  }
})

//utils/script.ts
export function useScriptFoo() {
  return<EMAIL_ADDRESS>{
    trigger: 'manual'
  })
}

<script lang="ts" setup>
import { useScriptFoo} from '~/utils/scripts'

const { onLoaded, load } = useScriptFoo()
load() // load the script
onLoaded(() => {
  // do component specific stuff (if applicable)
})
</script>

In my case, I'm integrating HTL BID as our primary advertising stack. In essence we setup specifically-attributed <div>s throughout our page and then invoke window.htlbid.layout() after their script has loaded which will search the dom and inject the necessary children.
I'll give your proposal here a shot and report back; considering I also already have to create a plugin for this integration to hook into page changes (must invoke another method when that finished) it shouldn't be too hard to test out.

Just following up confirming this worked just fine. Thanks for the help!!!

@harlan-zw wanted to reply back here; after further evaluation; I suspect that while your proposal works from keeping the onLoaded from being invoked multiple times; it actually breaks another desire of mine which I neglected to mention in the original post (apologies for that!)
In essence, I ONLY want this script to be loaded when my Vue Component is actually present on the page. With the plugin approach; the script will ALWAYS be loaded on every route since it's done as part of an overall plugin instead of within the component's setup (which wouldn't execute if the component never got put on the page).
We have use cases where we don't want to inject extraneous scripts into the route (e.g. ad-free users). If I go with the plugin route; I would have to build out a separate tracking mechanism to determine if the load the script or not which will complicate the overall application architecture (e.g. can't just use a v-if on my component to handle everything).
Do you have any other options? FWIW the onLoadedSingleton idea would presumably work.
Thanks,
Ken

Apologies; I was getting a little confused in my referencing. I can confirm the script itself is not loaded in the DOM until the component is on.
I was referring to the plugin got which sets up the onLoaded callback; it gets executed since it's a plugin. That said, to your point; it's not doing anything other than setting up a callback that wouldn't be invoked so not a big deal.
I think I'm good; though it would still be nice to be able to fully encapsulate our "optional" functionality into a VueJS component if y'all decide you want to support a singleton loaded pattern.
Thanks for supporting me throughout this!!!

Yes, I'd like to still support the onLoadedSingleton but I'm looking for a valid use case in one of the Registry components before committing to it. otherwise I'll take a look at the HTL BID implementation when I have a chance and see what it looks like.


update to cake.incubator 4.0.2, Gitversion to 4.0.1-beta1-58

This PR is needed in order to be able to update to cake 0.33.0. As Cake.Recipe builds with Cake.Recipe we need to update some dependencies first. Another PR will follow

@gep13 do you mind having a look? I have used the same version of GitVersion as Cake team is using for now

Personally I think updating Gitversion to 4.0+ could be a bad idea.
Just do to one reason though: It comes with a breaking change (compared to 3.x) when using a configuration file, as well as some some branches is using a different pre-release label.
IMO, a opt-in should rather be implemented instead.

@AdmiringWorm you raise a good point.
Making this change does have it's good points though, as it would mean that it could be one less thing that needs a mono dependency, so in theory, it would get us further along the road in terms of that.
@arturcic I think I would suggest holding off on making this change, based on what @AdmiringWorm has stated.  I would really like to get to a release of Cake.Recipe in the near future, which will likely be a 1.0.0 release, and then we can look at pulling in breaking changes like this.
Thoughts?

Just want to point out that there is an automated process that takes care of upgrading addin references that are used by Cake.Recipe. Additionally, this automated process will upgrade the version of Cake used to build Cake.Recipe as soon as all the addins support Cake 0.33.0.

The reason I updated GitVersion is because when I tried updating to cake version 0.33.0 I got this error

As far as I understand the Cake team has added verbosity settings or similar https://github.com/cake-build/cake/issues/2141 (have a look at release notes)

@arturcic hmmm....
You make a good point... argh!

I could agree that GitVersion should remain 3.6.5 for now, as there are some breaking changes in 4.0+, or even 5.0-beta+. That's why my choice was to use the same version as Cake team uses for now

@AdmiringWorm said...
if the verbosity argument is always passed when calling the gitversion alias,

As of 0.33.0 of Cake, this is now always passed yes 😢
There was a quick discussion as to whether or not we should create a GitVersion3 and GitVersion4 aliases, similar to what is done for the likes of NUnit, but I personally don't want to go down that route, and instead, recommend people to update to newest GitVersion.
I think I should look to "finally" getting a finalised release of Cake.Recipe out the door, and then look to bump to 0.33.0 of Cake and support things like newer GitVersion, and then start making some other changes as well, i.e. TypedContext for all tasks, and other improvements.

I am going to go ahead and close this PR, in favour of the other two PR's that are raised here:
https://github.com/cake-contrib/Cake.Recipe/pull/333
https://github.com/cake-contrib/Cake.Recipe/pull/339


Fix typo

Fixed wrong typo filnk. Please look on.

Also, there are few more bugs(or maybe I'm not doing it right...) in docs.

There are no guide for running a docker all in one image. Is it missing?
I couldn't create jar file with mvn clean install on repository. Do I have to run with flink?

It turns out that the typo also exists in AthenaXConfiguration.java. Can you please change that as well?
For your questions:
(1) Currently AthenaX requires plugging in your own CatalogProvider, thus packaging everything in a docker will not work out of the box. Having a docker image that can work out-of-the-box would be very nice.
(2) The jar file resides in athenax-backend/target/ after you run mvn clean install.

@haohui Thanks for notice! I updated it.
(1) That's okay, cause I'm not testing on docker yet. But in document, there are guide for running a docker all in one image and this link just goes on to starting guide. It seems something wrong.
(2) I couldn't find AthenaX-xxx.jar file below /target. In command line, it does not go after below.
2017-10-14 14:30:29,903 [ResourceManager Event Processor] WARN  capacity.LeafQueue (LeafQueue.java:activateApplications(632)) - maximum-am-resource-percent is insufficient to start a single application in queue, it is likely set too low. skipping enforcement to allow at least one application to start
2017-10-14 14:30:29,903 [ResourceManager Event Processor] WARN  capacity.LeafQueue (LeafQueue.java:activateApplications(653)) - maximum-am-resource-percent is insufficient to start a single application in queue for user, it is likely set too low. skipping enforcement to allow at least one application to start
2017-10-14 14:30:29,903 [ResourceManager Event Processor] INFO  capacity.LeafQueue (LeafQueue.java:activateApplications(667)) - Application application_1507959024479_0001 from user: kwangin activated in queue: default
2017-10-14 14:30:29,903 [ResourceManager Event Processor] INFO  capacity.LeafQueue (LeafQueue.java:addApplicationAttempt(683)) - Application added - appId: application_1507959024479_0001 user: org.apache.hadoop.yarn.server.resourcemanager.scheduler.capacity.LeafQueue$User@4691abde, leaf-queue: default #user-pending-applications: 0 #user-active-applications: 1 #queue-pending-applications: 0 #queue-active-applications: 1
2017-10-14 14:30:29,904 [ResourceManager Event Processor] INFO  capacity.CapacityScheduler (CapacityScheduler.java:addApplicationAttempt(843)) - Added Application Attempt appattempt_1507959024479_0001_000001 to scheduler from user kwangin in queue default
2017-10-14 14:30:29,907 [AsyncDispatcher event handler] INFO  attempt.RMAppAttemptImpl (RMAppAttemptImpl.java:handle(815)) - appattempt_1507959024479_0001_000001 State change from SUBMITTED to SCHEDULED
2017-10-14 14:30:30,046 [main] INFO  impl.YarnClientImpl (YarnClientImpl.java:submitApplication(273)) - Submitted application application_1507959024479_0001
2017-10-14 14:30:30,057 [pool-11-thread-1] INFO  yarn.AthenaXYarnClusterDescriptor (AthenaXYarnClusterDescriptor.java:poll(282)) - Deploying cluster, current state ACCEPTED
2017-10-14 14:40:24,181 [Timer-3] INFO  scheduler.AbstractYarnScheduler (AbstractYarnScheduler.java:run(469)) - Release request cache is cleaned up

I waited about 30 minute, but process are not going on. Is it correct?

@djKooks mvn install runs along with tests and I don't know why the tests stops here, just use mvn install -DskipTests to skip ti. As mentioned at http://athenax.readthedocs.io/en/latest/getting_started/#start , the jar you need is located at athenax-backend/target.

@SilverRainZ Thanks for advice! It works now.


Configuring commonauth URL parameter for SAMLSSOAuthenticator not documented

We can change commonauth URL for federated authentication by adding the following parameter under SAMLSSOAuthenticator in application-authentication.xml. This is not documented.
http://<IP_ADDRESS>:9443/commonauth

Thank you for your contribution!
We are closing this issue since it has not been prioritized for a long time. Chances are that it has already been solved in more recent versions. If not, we will be re-evaluating this when it becomes a priority.


[$500] Android - Cursor Appears before the text in edit box

If you haven’t already, check out our contributing guidelines for onboarding and email<EMAIL_ADDRESS>to request to join our Slack channel!

Action Performed:
Action Performed:

Go to any chat report
Type some text
Long press and choose edit option.
Notice that the cursor appears before the editable text in edit-box.

Expected Result:
n other platforms - web, mweb, desktop, the cursor appears beside the text in edit box. However in android it appears before.
Actual Result:
Cursor Appears before the text in edit box
Workaround:
Unknown
Platforms:

Which of our officially supported platforms is this issue occurring on?

[ ] Android / native
[ ] Android / Chrome
[ ] iOS / native
[ ] iOS / Safari
[ ] MacOS / Chrome / Safari
[ ] MacOS / Desktop

Version Number: <IP_ADDRESS>
Reproducible in staging?: y
Reproducible in production?: y
If this was caught during regression testing, add the test name, ID and link from TestRail:
Email or phone of affected tester (no customers):
Logs: https://stackoverflow.com/c/expensify/questions/4856
Notes/Photos/Videos: Any additional supporting documentation
https://github.com/Expensify/App/assets/93399543/5ed49e4d-b265-48cb-9873-a091ad24844b
https://github.com/Expensify/App/assets/93399543/1d4ed62f-4c87-4ac4-a209-3b9f25251f43
Expensify/Expensify Issue URL:
Issue reported by: @ashimsharma10
Slack conversation: https://expensify.slack.com/archives/C049HHMV9SM/p1693847352660869
View all open jobs on GitHub
Upwork Automation - Do Not Edit

Upwork Job URL: https://www.upwork.com/jobs/~01d231624524297556
Upwork Job ID:<PHONE_NUMBER>647878656
Last Price Increase: 2023-09-09

https://github.com/Expensify/App/issues/24157 has contributors assigned, so closing this one


Add SIGs to testowners munger parsing

This adds support for parsing the SIG column added in kubernetes/kubernetes#40031. It should not be merged until that PR is.
Later PRs will label flakes with the appropriate SIG.

This change is

Code changed moved to kubernetes/test-infra


Remove references to Ergo from Concerto

With the Ergo language no longer maintained we should clean up all of the code paths that are Ergo-specific in Concerto.
This is expected to be a breaking-change because it will require removing parameters from some public API operations. However, the impact is expected to be very limited, because the only usage of those parameters is within the Ergo engine.
We could consider retaining the ordering of parameters in API operations so as not to force a new major version ahead of time.
Examples of redundant code can be found with the following query:
https://github.com/search?q=repo%3Aaccordproject%2Fconcerto+ergo+language%3ATypeScript+OR+language%3AJavaScript&type=code&l=TypeScript
e.g.
https://github.com/accordproject/concerto/blob/2f22485b57601dd82df38a0c987379d1ad993361/packages/concerto-core/lib/serializer/jsongenerator.js#L123-L133
The clean-up should also remove redundant tests, and CLI operations.

Please assign this to me.


Include brief responses frontend

This is a based on this https://github.com/alphagov/digitalmarketplace-functional-tests/pull/322. Once that's merged the stuff about finding radio buttons will disappear.
Create brief-responses-frontend service
We add the new brief responses frontend as a service in the
docker-compose file, following the same pattern as the other frontend
apps.
Add a new location to the nginx config
The brief-responses frontend app has a new prefix so traffic is routed
correctly.

Yep, i'll stick it in.

I have no idea what's going on with the functional tests these days.  What do they have to do with Docker?  I'm lost.

Why are there empty "description" fields in the table of tags in the README?  Feels like they would be really really useful. (Not for this PR, I know)

@TheDoubleK We've got a docker-compose file in the functional tests repo. Allows you to spin up all the apps locally easily without faff, so you can run local functional tests easily. It's all documented in the readme. Has no impact on the tests we run on Jenkins though.

Is the docker thing only relevant for running functional tests?  Or could it be an everyday part of dev setup for running all the things?  In which case having it squirrelled away here might not be the best place for it (you can say the same thing about the nginx bootstrap script here, we really should have a better home for that).

It could be useful for everyday, although I suspect it might be more of a pain than what people are currently doing. To get any changes up and running you'd need to rebuild the docker image and then restart the whole thing. Also, the logging is weird in them cos the apps are running behind supervisor/uwsgi/nginx. And using a debugger for example would be pretty difficult. I guess if people start using the compose thing we can see how they like to use it and go from there?


perf(hono-base): don't import HTTPException

This is like a refactor but is made a perf since reducing the bundle size for the performance.
With this PR, the hono-base.ts does not need to import the HTTPException class directly. So, the bundle size for the app that does not use HTTPException will be small. To enable it, it does not use instanceOf; it will detect by checking the property named a symbol of IS_HTTP_EXCEPTION.
Result:

It was reduced by 260 bytes. It seems small, but reducing size is important for edge environments such as Cloudflare Workers.
The author should do the following, if applicable

[ ] Add tests
[x] Run tests
[x] bun run format:fix && bun run lint:fix to format the code
[ ] Add TSDoc/JSDoc to document the code

Hey @usualoma. I want to know your thoughts on this.

@yusukebe
Ah I see, this is very nice!
Alternatively, how about the following. It simplifies the definition and opens up the possibility for users themselves to use "errors implementing getResponse()", other than hono’s HTTPException. The behaviour would change if an existing application used "errors implementing getResponse()", but, well, there would be no such application.
diff --git a/src/hono-base.ts b/src/hono-base.ts
index f3e9ad03..858d65db 100644
--- a/src/hono-base.ts
+++ b/src/hono-base.ts
@@ -7,7 +7,6 @@
 import { compose } from './compose'
 import { Context } from './context'
 import type { ExecutionContext } from './context'
-import { HTTPException } from './http-exception'
 import { HonoRequest } from './request'
 import type { Router } from './router'
 import { METHODS, METHOD_NAME_ALL, METHOD_NAME_ALL_LOWERCASE } from './router'
@@ -21,6 +20,7 @@ import type {
   MergeSchemaPath,
   MiddlewareHandler,
   MiddlewareHandlerInterface,
+  HTTPResponseError,
   Next,
   NotFoundHandler,
   OnHandlerInterface,
@@ -38,8 +38,8 @@ const notFoundHandler = (c: Context) => {
   return c.text('404 Not Found', 404)
 }

-const errorHandler = (err: Error, c: Context) => {
-  if (err instanceof HTTPException) {
+const errorHandler = (err: Error | HTTPResponseError, c: Context) => {
+  if ('getResponse' in err) {
     return err.getResponse()
   }
   console.error(err)
diff --git a/src/types.ts b/src/types.ts
index 2178e5c1..87691b01 100644
--- a/src/types.ts
+++ b/src/types.ts
@@ -91,8 +91,12 @@ export type H<
 > = Handler<E, P, I, R> | MiddlewareHandler<E, P, I>

 export type NotFoundHandler<E extends Env = any> = (c: Context<E>) => Response | Promise<Response>
+
+export interface HTTPResponseError extends Error {
+  getResponse: () => Response
+}
 export type ErrorHandler<E extends Env = any> = (
-  err: Error,
+  err: Error | HTTPResponseError,
   c: Context<E>
 ) => Response | Promise<Response>

@usualoma Thank you for the suggestion!
I also thought it was okay to check getResponse only first. As you said, we can ignore other applications that have "errors implementing getResponse()" since they are very rare or do not exist. So, I'll follow your idea.

@usualoma
Can you create the new PR with your patch?

This is not necessary now since #2898 has been merged.


Improving in-memory cache with external component + eviction strategies

Outdated - The core got refactored heavily since the PR was opened


Refactor and a couple of fixes for adapter layer updates

This started as a simple refactor, but during this, I discovered a few issues too, which should now be fixed. This is probably best reviewed by checking each commit separately.
Here are the descriptions for the individual changes:
1. Refactor: Move LoRA update_layer to child classes
For LoRA, so far, we have update_layer for Linear, update_layer_embedding for Embedding, and update_layer_conv2d for Conv2d, all defined on LoraLayer.
We can simplify the code by always using the name update_layer, and by moving the layer-specific methods to the subclasses. So e.g. update_layer_embedding is moved to the Embedding class and renamed to update_layer. This way, the caller does not need to differentiate which type of layer it's calling, making it much easier (see the simplification in LoraModel._create_and_replace). It also makes the code less error prone (see change 4 described below).
Interestingly, this was already practiced for IA³, so the same change was not necessary there. But I did find the same method implemented twice, once on IA3Layer and once on Linear, so I removed one of the duplicates. For all other adapter methods, no change was required, as they only implement Linear.
Note: This could technically be backwards incompatible if users do some custom stuff with LoraLayers. I could add a note for next release that all update_layer_* methods have been consolidated to use the same update_layer name.
2. Systematic handling of r (rank) <= 0
Always raise an error when r <= 0, not only for LoRA. Also, removed later check for r > 0 in LoRA layers, since we already check for r <= 0.
Note: This could technically also be considered backwards incompatible, but r<=0 should not work correctly anyway, so better to raise an error right away.
3. Fix broken __repr__ method on QuantLinear
Was indented too deep, thus not being applied.
4. Fix bug for updating Lora GPTQ and IA3 bnb layers
Before this fix, when adding a 2nd adapter to a model, we did not correctly check if there was already an adapter layer in the model when dealing with LoRA GPTQ or IA3 bnb layers. As a consequence, instead of updating the existing layers, we would create a new layer and the existing layer would be set as the base_layer of that new layer. Now, we correctly update the existing layer to add the new adapter.
For this fix to work correctly with LoRA and GPTQ, I had to add a check for qweight in update_layer, since we only checked for weight before. This was a mistake that didn't surface so far because of the error described in the previous paragraph.
Tests were extended to check this. They fail with the current main but pass on my machine with this PR.

The docs for this PR live here. All of your documentation changes will be reflected on that endpoint. The docs are available until 30 days after the last update.

@younesbelkada Integration tests don't work on forks, right? So we can check after merging only.

I just ran it here: https://github.com/huggingface/peft/actions/runs/7246319576

Tests are green ! Feel free to merge!


grpc_tcp_client_connect function type mismatch

api_fuzzer.c expects grpc_tcp_client_connect to have arguments
(grpc_exec_ctx*, grpc_closure*, grpc_endpoint**, grpc_pollset_set*, grpc_channel_args const*, grpc_resolved_address const*, gpr_timespec)
but instead should have
(grpc_exec_ctx *, grpc_closure *, grpc_endpoint **, grpc_pollset_set *, const grpc_channel_args *, const grpc_resolved_address *, grpc_millis)

Fixed as part of #13147