[Bug]: context dealing exceeded due to metrics-server pod not terminating on terraform destroy

Welcome to Amazon SSP EKS Accelerator!

[X] Yes, I've searched similar issues on GitHub and didn't find any.

Amazon EKS Accelerator Release version
3.5
What is your environment, configuration and the example used?
Terraform v1.0.10
on darwin_amd64

provider registry.terraform.io/gavinbunney/kubectl v1.13.1
provider registry.terraform.io/hashicorp/aws v4.5.0
provider registry.terraform.io/hashicorp/cloudinit v2.2.0
provider registry.terraform.io/hashicorp/helm v2.4.1
provider registry.terraform.io/hashicorp/kubernetes v2.8.0
provider registry.terraform.io/hashicorp/local v2.1.0
provider registry.terraform.io/hashicorp/null v3.1.0
provider registry.terraform.io/terraform-aws-modules/http v2.4.1

Using the getting started guide
What did you do and What did you see instead?
What did I want to do?
Tried to terraform destroy the cluster
What did I expect:
The cluster to be deprovisioned
What happened?
Terraform destroy failed with error:  context deadline exceeded
Exploring the cluster, the error took place because the metrics-server pod was stuck in terminating state
Once the pod was deleted forcefully (kubectl delete pod metrics-server-694d47d564-4xv72 --grace-period=0 --force  -n metrics-server), and then the related namespace was deleted, Terraform was able to destroy the cluster
Additional Information
No response

Thanks @camba1 fro reporting the issue. @Zvikan can you please have a look at this one?

Still getting a similar issue regarding Error: context deadline exceeded. Sometimes terraform destroy works, sometimes it doesn't. Any ideas? The hangup is always around the kubernetes-addons module.

Hi @danvau7, thanks for following up on this. We're working on a list of known issues, including this one. We're also working on a fix for this problem in particular, but don't have an estimate for when that will be pushed out. In the meantime, if you are trying to deploy the examples you can avoid the issue by deploying the VPC separately from the rest of the example.

Setting the following in the aws-eks-accelerator-for-terraform helps significantly and would perhaps recommend adding to main example in the README.md:
  cluster_timeouts = {
    create = "120m"
    update = "120m"
    delete = "120m"
  }

Also modifying the helm configs such as in the following also helps. I change the default value from 1200 -> 3600.
  enable_argocd = true
  # Optional Map value
  argocd_helm_config = {
    name             = "argo-cd"
    chart            = "argo-cd"
    repository       = "https://argoproj.github.io/argo-helm"
    version          = "3.35.4"
    namespace        = "argocd"
    timeout          = "3600" # changed from 1200
    create_namespace = true
  }

Sorry for replying late to this.
As Naris mentioned, currently our examples are a single TF apply and destroy approach, the problem with it is that other modules and resources may be deleted (e.g. VPC resources), this may lead to addons not being deleted properly and reporting back with timeouts/deadline exceeded.
The ideal destroy order would be:

k8s Addons
k8s managed addons (e.g. VPC CNI)
nodes
cluster
VPC and other.

You can use the -target arg while running TF apply/destroy to target the specific modules/resources you want to be deleted.
Here's what I suggest to check next time you are facing this issue:

Run kubectl describe pod <POD_NAME> where pod name is the one with the timeout/deadline exceed issue,  check under the events if there are any issues around sandbox/CNI
Run kubectl get nodes and check the status of the nodes

If any of the above is true, check terraform destroy order, and you may see that VPC resources have been deleted before the addons, which leads to nodes unhealthy and overall cluster in a state that addons can't be deleted properly (this may be true NOT just for metrics-server, but other addons too).

Sadly, I am also facing this issue:
module.eks-addons.module.aws_for_fluent_bit[0].module.irsa.kubernetes_namespace_v1.irsa[0]: Still destroying... [id=logging, 4m50s elapsed]
module.eks-addons.module.ingress_nginx[0].module.helm_addon.module.irsa[0].kubernetes_namespace_v1.irsa[0]: Still destroying... [id=nginx, 4m50s elapsed]
╷
│ Error: context deadline exceeded
│
│

The Pods hang in Terminating state. Here is the describe pod output of the nginx controller:
Name:                      ingress-nginx-controller-559c9cc878-wgg42
Namespace:                 nginx
Priority:                  0
Node:                      ip-XX-XX-XX-XX.eu-central-1.compute.internal/XX.XX.XX.XX
Start Time:                Thu, 05 May 2022 23:09:12 +0200
Labels:                    app.kubernetes.io/component=controller
                           app.kubernetes.io/instance=ingress-nginx
                           app.kubernetes.io/name=ingress-nginx
                           pod-template-hash=559c9cc878
Annotations:               kubernetes.io/psp: eks.privileged
Status:                    Terminating (lasts 10h)
Termination Grace Period:  300s
IP:                        <IP_ADDRESS>
IPs:
  IP:           XX.XX.XX.XXX
Controlled By:  ReplicaSet/ingress-nginx-controller-559c9cc878
Containers:
  controller:
    Container ID:  docker://631f2c8a81683c06978875f60218319a9ecf7a62ff97a5835ea158dab1c86819
    Image:         k8s.gcr.io/ingress-nginx/controller:v1.0.4@sha256:545cff00370f28363dad31e3b59a94ba377854d3a11f18988f5f9e56841ef9ef
    Image ID:      docker-pullable://k8s.gcr.io/ingress-nginx/controller@sha256:545cff00370f28363dad31e3b59a94ba377854d3a11f18988f5f9e56841ef9ef
    Ports:         80/TCP, 443/TCP, 8443/TCP
    Host Ports:    0/TCP, 0/TCP, 0/TCP
    Args:
      /nginx-ingress-controller
      --publish-service=$(POD_NAMESPACE)/ingress-nginx-controller
      --election-id=ingress-controller-leader
      --controller-class=k8s.io/ingress-nginx
      --configmap=$(POD_NAMESPACE)/ingress-nginx-controller
      --validating-webhook=:8443
      --validating-webhook-certificate=/usr/local/certificates/cert
      --validating-webhook-key=/usr/local/certificates/key
    State:          Running
      Started:      Thu, 05 May 2022 23:09:19 +0200
    Ready:          True
    Restart Count:  0
    Requests:
      cpu:      100m
      memory:   90Mi
    Liveness:   http-get http://:10254/healthz delay=10s timeout=1s period=10s #success=1 #failure=5
    Readiness:  http-get http://:10254/healthz delay=10s timeout=1s period=10s #success=1 #failure=3
    Environment:
      POD_NAME:                     ingress-nginx-controller-559c9cc878-wgg42 (v1:metadata.name)
      POD_NAMESPACE:                nginx (v1:metadata.namespace)
      LD_PRELOAD:                   /usr/local/lib/libmimalloc.so
      AWS_DEFAULT_REGION:           eu-central-1
      AWS_REGION:                   eu-central-1
      AWS_ROLE_ARN:                 arn:aws:iam::XXXXXXXXXX:role/simphera-reference-dev-eks-ingress-nginx-sa-irsa
      AWS_WEB_IDENTITY_TOKEN_FILE:  /var/run/secrets/eks.amazonaws.com/serviceaccount/token
    Mounts:
      /usr/local/certificates/ from webhook-cert (ro)
      /var/run/secrets/eks.amazonaws.com/serviceaccount from aws-iam-token (ro)
      /var/run/secrets/kubernetes.io/serviceaccount from kube-api-access-r824n (ro)
Conditions:
  Type              Status
  Initialized       True
  Ready             False
  ContainersReady   True
  PodScheduled      True
Volumes:
  aws-iam-token:
    Type:                    Projected (a volume that contains injected data from multiple sources)
    TokenExpirationSeconds:  86400
  webhook-cert:
    Type:        Secret (a volume populated by a Secret)
    SecretName:  ingress-nginx-admission
    Optional:    false
  kube-api-access-r824n:
    Type:                    Projected (a volume that contains injected data from multiple sources)
    TokenExpirationSeconds:  3607
    ConfigMapName:           kube-root-ca.crt
    ConfigMapOptional:       <nil>
    DownwardAPI:             true
QoS Class:                   Burstable
Node-Selectors:              kubernetes.io/os=linux
Tolerations:                 node.kubernetes.io/not-ready:NoExecute op=Exists for 300s
                             node.kubernetes.io/unreachable:NoExecute op=Exists for 300s
Events:                      <none>

@Zvikan do you have a hint for me how I can fix it?

Hey @schwichti , I can see that your nodes are in status "NotReady" , this may be similar issue as I explained above.
Did you run the whole example with a single terraform destroy command?
If so, you may faced a situation where some of the VPC resources were deleted before the addons & the cluster, which leads to this situation where nodes are not healthy, and then TF is unable to destroy the addons.
Did you try to do a cleanup/destroy process using the -target arg as I mentioned above?

@Zvikan I am not using any example, but created my own module based eks blueprints: https://github.com/dspace-group/simphera-reference-architecture-aws/tree/feat_update_dependencies . In fact, I am able to complete when I delete the Helm charts manually (see above), therefore I do not have the need to use -target. However, I would like to destroy everthing with one run without any troubles.
I think you are right that VPC resources were deleted before the addons, but I cannot see why that is the case. In https://github.com/aws-ia/terraform-aws-eks-blueprints/pull/356/files you have added an explicit dependency from the blueprints module to VPC. I do not see why is necessary, because there is an implicit dependency. It also appears that this explicit dependency was removed again from the examples.

@schwichti the implicit dependency is just for several of the VPC resources like the subnet ids, but what can cause this domino effect may be your NAT gateway, or VPC related resources that leads the nodes to be in unstable state and therefore TF not being able to cleanup the addons properly.
And we've removed the explicit dependency between addons and/or accelerator (now known as EKS blueprint) to VPC (due to upstream changes in newer versions where we can't use depends_on  as you will face this issue.
We've been trying to keep a single TF apply &/ destroy without any issues, but we entered the dependency rabbit hole and faced the following issues:

explicit dependencies can add ALOT of time to the TF plan - due to the nature of how TF works and the amount of the project
implicit dependencies doesn't cover all use cases (as the example I provided here with the VPC resources)

And more.
So how do we go from here? we've been thinking alot and game into a decision that the best next steps is to take a step back, and suggest to deploy modules in the correct order via -target. (if you wish to have it all under the same repo and in a single TF state...)

@Zvikan do I get you right that adding an explicit dependency to the vpc resources could solve the issue in my case (coming at the price of slowing down)?
Using the -target option is quite unsatisfying for me and can only be a temporary solution.

@schwichti Yes, by adding explicit dependency in your case you control the deployment (apply/destroy) flow, achieving what I've said above.

do think a destroy that includes of a EKS cluster should without being told automatically delete the add-ons first.

Hi, i started playing with eks-blueprints a couple of weeks ago and ran into similar problems to this and #524 .
Not sure this is 100% related, but after some testing (especially with the ingress-nginx addon), i noticed the Loadbalancer-Service was stuck pending - although the helm-chart was removed.
So i manually ran helm delete ingress-nginx which removed the service successfully. This led me to think the problem is terraform and it's handling of helm_release. I stumbled upon an open issue regarding the helm-provider which.
Main Problem seems to be: Helm-destruction is immediate and terraform continoues which causes problems.. only solution i've seen so far is a fixed wait-timout.. ;(


buildGoModule modSha256 differs from unstable and 19.03

Issue description
It seems the modSha256 differs between building on unstable and on 19.03.
λ nix run -f channel:nixos-19.03 go -c go version
[21 copied (591.7 MiB), 141.0 MiB DL]
go version go1.11.6 linux/amd64
λ nix run nixpkgs.go -c go version
[1 copied (373.7 MiB), 95.9 MiB DL]
go version go1.12.6 linux/amd64

There has been so issues with go modules hashes in go 1.12, so it might be the reason why it fails.
Steps to reproduce

Using this derivation https://github.com/vdemeester/nur-packages/blob/master/pkgs/athens/default.nix
Building on unstable works : see here
Building on 19.03 fails: see here

fixed-output derivation produced path '/nix/store/xa2110n19mzfyiwrvwi1j9p5rh39i51r-athens-0.5.0-go-modules' with sha256 hash '0l43q3x5a2vp0s9yng8hr4pb4fh922q8vd6xf1f6qys876x4b4q5' instead of the expected hash '1fanb3mhvnldkryz74yarcwl4ma6353mfkivs5hr678g6785srqj'

Technical details
Please run nix-shell -p nix-info --run "nix-info -m" and paste the
results.
 - system: `"x86_64-linux"`
 - host os: `Linux 5.1.15-300.fc30.x86_64, Fedora, 30 (Workstation Edition)`
 - multi-user?: `no`
 - sandbox: `yes`
 - version: `nix-env (Nix) 2.2.2`
 - channels(vincent): `"home-manager, nixpkgs-19.09pre184383.e8d00113e23"`
 - nixpkgs: `/home/vincent/.nix-defexpr/channels/nixpkgs`

I think it can be marked as closed :angel:


Optimize message re-rendering, and fix bug to only animate relevant edits.

Followups to #22094, specifically this commit that did the following:

Previously, the topic_edited and stream_changed variables were
incorrectly used outside the loop over events, in a way that meant
we'd use the values of these from the last event, when we clearly
meant to use whether, for example, the current stream was changed.
In practice, it's rare for a client to process multiple message edit
events at the same time, but this will happen anytime a client is
offline for a few minutes during which several edits occur.

There is a followup bug:
        // BUG: This triggers the "message edited" animation for every
        // message that was edited if any one of them had its content
        // edited. We should replace any_message_content_edited with
        // passing two sets to rerender_messages; the set of all that
        // are changed, and the set with content changes.
        message_lists.current.view.rerender_messages(msgs_to_rerender, any_message_content_edited);

and a followup TODO:
        // TODO: We can potentially optimize this logic to avoid
        // calling `update_muting_and_rerender` if the muted
        // messages would not match the view before or after this
        // edit.  Doing so could save significant work, since most
        // topic edits will not match the current topic narrow in
        // large organizations.
        if (!changed_narrow && message_lists.current === message_list.narrowed) {
            message_list.narrowed.update_muting_and_rerender();
        }

Relevant comment here

If you're interested, both the BUG comment noted in the last commit and the TODO comment in the block just above it are both reasonable follow-ups while we're working in this codebase. I think the BUG is likely easy to fix (you can likely reproduce, at least at a console.log level, by using the browser console to mark one browser offline while another does multiple edit operations). But the TODO one is I think much more impactful -- in that probably 90%+ of rerender calls that happen in that code path is a waste of time, because none of the messages that were edited could possibly appear in the relevant view.

@zulipbot claim

Still working on it


Append to an array of objects not works as expected

Describe the bug
Append to an array of objects is not working as expected in YAML parser.
To Reproduce

Go to Append to an array of objects section
Try the given example:

echo 'users:
- name: Tom' | dasel put object -p yaml -s '.users[]' -t string name=Frank
users:
- name: Tom
- name: Frank

I got:

users:
- name: Tom
users[]:
  name: Frank

Expected behavior
users:
- name: Tom
- name: Frank

Desktop (please complete the following information):

OS: macOS
Version: v1.9.1

Additional context
We can add an unit test case for this scenario during fix phase. :)

Hey @Dentrax ,
The issue is the selector. It should be .users.[].
I'll leave this issue open and fix the readme soon

Additionally there is a unit test for this already: https://github.com/TomWright/dasel/blob/bf79564bf82774883d8d06e3524b942b4ff5da4d/internal/command/root_put_test.go#L232

@Dentrax I've updated the readme 👍
Thanks for spotting that!


Support system_accountNextIndex RPC

We currently have an issue  regarding accountNextIndex and the system API link  is provided here. We are currently using substrate-api-client with polkadot-v0.9.39-tag-v0.7.0, which does not have the system_accountNextIndex RPC. So, I would like to ask, do you have any plans to include this RPC in which version? Thank you!

Hey @zTgx
I introduced the new function in this PR: https://github.com/scs/substrate-api-client/pull/573/files, so it should be available in the next version (e.g. polkadot v0.9.43 hopefully)
But since you're using quite an outdated version, you have two options:

update to a newer version. Check out https://github.com/scs/substrate-api-client#example-upgrades-from-older-to-newer-versions for an example upgrade (and the necessary changes involved) in the Integritee worker. If you experience problems with that, feel free to ask right away. I'm sure other projects will profit from this as well.
Implement the api function for the respective branch yourselves. While we don't update old versions, a PR (given it is backward compatible) on the respective branch will be accepted. Introducing a function in this file should suffice. I imagine something like this could work:

pub fn system_account_next_index(account_id: AccountId32) -> Value {
	json_req("system_accountNextIndex", vec![to_value(account_id).unwrap()], 1)
}

I hope this helps you :)

Thank you for your reply. It has been very helpful to me.


bitmovin:encodes audio only when a track is available

Ticket: https://jira.nyt.net/browse/MULT-456
Proof it works: https://dashboard.bitmovin.com/encoding/encodings/5440df77-c306-4480-87e6-f157e25bf966

Codecov Report

Merging #193 into master will increase coverage by <.01%.
The diff coverage is 100%.

@@            Coverage Diff             @@
##           master     #193      +/-   ##
==========================================
+ Coverage   78.73%   78.74%   +<.01%
==========================================
  Files          29       29
  Lines        2878     2879       +1
==========================================
+ Hits         2266     2267       +1
  Misses        363      363
  Partials      249      249

Impacted Files
Coverage Δ

provider/bitmovin/bitmovin.go
64.96% <100%> (+0.04%)
:arrow_up:

Continue to review full report at Codecov.

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


Layout on collection view is small

https://beta.kodadot.xyz/en/rmrk/collection/58805bce8156c8b76e-3VB0P

How it looks on production rn
https://kodadot.xyz/rmrk/collection/58805bce8156c8b76e-3VB0P

closed in #1403


Include the GAMS version of the transport tutorial

Essentially the same as #101, but with GAMS/gamsapi instead of linopy.
This PR is based on top of that branch, too, and actually adds only five commits. Two of those are the content of #107, so won't need to remain in here, either.
Hence: When reviewing/looking at the code, please focus on the new files in tutorial/transport/.
Please note: there is no test yet, but the values resulting from running the tutorial are correct. I'll add tests soon.

This PR now includes exhaustive tests of the newly added code. The main thing I would like to improve for them is how paths are handled, but this will have to wait until we finalize a location for the gams/solve-related code.
The tests are currently failing because I didn't adapt the workflow file to install GAMS. This might also be influenced by where the solve-code ends up living; if it's not in this repo, we don't need to configure a secret holding a license here, etc. You can still convince yourself that the tests are running by checking out this branch locally on a system that has GAMS installed.


Clarification on MPos config change

[Enter feedback here]
Regarding this section:
https://docs.microsoft.com/en-us/dynamics365/commerce/dev-itpro/retail-POS-activation-changes#update-the-modern-pos-configuration
Do you need to execute that for EVERY Mpos deployment? There must be a way to automate this or make it part of the build?

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

ID: 9cde75a6-0a4d-8405-4b6d-f7e3cfd33094
Version Independent ID: fa2a94bb-7a6f-1ca4-ce74-8bcd8a6929f7
Content: Device activation of a customized Modern POS - Commerce | Dynamics 365
Content Source: articles/commerce/dev-itpro/retail-POS-activation-changes.md
Service: dynamics-365-retail
Product: ****
Technology: ****
GitHub Login: @jashanno
Microsoft Alias: jashanno

Thank you for your comment. @jashanno can you please take a look?

Thank you for your comment. @jashanno can you please take a look?

BUG 546038 created to track this issue.

BUG 546038 created to track this issue.

This content has been updated.


[Bug]: Conversation Titles Generated in Incorrect Language

What happened?
Occasionally, the titles of conversations are automatically generated in Spanish, despite the conversations being conducted entirely in English. This inconsistent behavior does not align with the language used within the chat sessions and occurs unpredictably. When the issue manifests, it leads to confusion and a disjointed user experience. Ideally, conversation titles should accurately reflect the language predominantly used within the conversation, or at least adhere to the user's default or selected language preferences
Steps to Reproduce
Please note that this issue occurs intermittently and may not be reproducible in every instance of conversation title generation.
Engage in a chat conversation entirely in English (or in a language other than Spanish).
Complete the conversation and allow the system to generate a title for it.
Observe the title of the conversation, noting any instances where it is generated in Spanish, despite the chat being in English.
What browsers are you seeing the problem on?
Chrome
Relevant log output
No response
Screenshots
No response
Code of Conduct

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

Happened to me too. I can reproduce by just writing „hey“

@ndrsfel @Fakamoto I can’t reproduce it. What model are you using for generating the title? (I tried 10 times with gpt-4-turbo and gpt-3.5-turbo, everything seems to be working correctly)


Implement cassandra-journal.max-result-size via Paging

Atm a LIMIT query is used. We could use cassandra paging fetch-size introduced in C* 2.0:
http://datastax.github.io/java-driver/2.1.7/features/paging/
This is used in the C* Spark Connector when bringing a large number of rows into Spark from C*.
It would remove one of the cases in the RowIterator, we're already doing synchronous queries so this would be almost transparent (call to next() would just block). You can also query the paging state to see how many rows can be taken without blocking / get a future for when more rows are available.
WDYT?

After reading the docs again, +1 to use the fetch-size on the driver (and simplify RowIterator).
The current implementation came from a misunderstanding on my side: I thought the server always limits the size of a result set (using a default value if none is given) so that clients need to query for more results once they've iterated over a previous query. I thought that LIMIT is independent of the driver's fetch-size but they seem to be same. I somehow missed in the docs that the server doesn't limit the size of a result set at all. Is my understanding correct?

You were right that LIMIT is independent of fetch size and that the server by default will return all the rows.
LIMIT is mainly used for manual paging (like we are now) or getting top N results, and will result in you needing to issue another query based on the last row of the previous query.
Prior to 2.0 if you didn't specify a LIMIT (paging didn't exist) you would get OutOfMemory in either the coordinator or your app as C* just brought back all the rows. I deleted so much code when paging was added.
I believe the driver sets a default fetch-size and without a LIMIT all the rows will come back (and if you read them all into memory you of course still risk a OOM).
To add confusion cqlsh adds a 1000 LIMIT to all your queries tho this may have been changed to use fetch-size as I see cqlsh has a less like interface for large results now. I need to confirm this.
TLDR we can remove LIMIT and just rely on fetch-size

OK, sound good.


Fix matcher ordering

Further research indicates that we had it the wrong way around.

Does this mean true > false or false > true?

true > false


Add check_pub_error macro

Public errors are part of the public API, as such we need to be careful not to change them. One thing that is hard to notice is adding/removing Send/Sync.
Add a macro that asserts that an error type implements Send, Sync and std::error::Error (feature guarded on test and feature = "std").
Based on idea by @Kixunil: https://github.com/rust-bitcoin/rust-bitcoin/pull/1127#discussion_r932115136
Notes since first raising PR

All the release job discussion below is resolved now.
Please do not merge, if this gets a concept ack I need to go manually through the whole codebase and check that no new error types were added since I first raised this.

I'm not sure why the release job cargo publish -p bitcoin --dry-run  fails to find the new macro?

All the force pushes are me rebasing on #1742 trying to get it past CI.

assert Debug is implemented

We should just check for std::error::Error on std.

Hmm, shitty.
So @tcharding the reason CI is failing is that cargo publish tries to use the version of internals that's already on crates.io. So if we add literally anything to internals ... or to hashes ... then the release job will fail.
On the one hand, this is exactly what we want to happen (it's telling us that we can't release bitcoin without releasing internals fist). But on the other hand, we're about 48 hours into this release and we're already getting a failure from the CI job, so I guess we've gotta figure out how to get it to be yellow instead of red :)

@tcharding could you try adding a commit which does that, to see if it makes CI pass?
I think that wrapping the publish checks in if git diff --quiet */Cargo.toml; then ... fi will do it.

Spent more time playing with bash than I wanted to, will try again tomorrow.

Now uses suggestion by @sanket1729 to use a function instead of a trait. I also checked that the macro is used for all errors (I grepped for std::error::Error so ironically if any error types are missing this impl then I'll have missed them).

I'm a little surprised that this works now without the functions being pub

I'm a little surprised that this works now without the functions being pub

I was surprise also, I tried to work out why it works and I cannot. (Also the comment on dead_code is wrong, will fix it and force push.)

We should understand why this actually works with privately scoped helper functions before merging this.

Face palm - thanks @Kixunil, consider me schooled.

Oof, ditto.

I could not get it to work with functions, reverted to using traits.

Now I'm worried again that the impls are not actually taking effect when this macro is called from the downstream bitcoin crate. I think so because the #[cfg(test)] is in the macro so it should apply to the calling crate.
BTW @tcharding it occurs to me that to get privacy, the macro should define a whole #[cfg(test)] mod internals_trait_checks { ... } and put everything in there, the traits and their impls.

I had another go, note bitcoin::string::Error has a generic on it that is now correctly handled. Changes in internals::error will need total re-review please.

Changes in force push:

Use #[cfg(trait_checks)] instead of feature
Check for Display/Debug for all builds

Changes in force push:

Changed cfg option to be check_traits (instead of trait_checks) so its a verb in line with "bench" and "bitcoin_fuzz".
Changed CI to explicitly call cargo build with RUSTFLAGS set instead of setting for all builds.

ooo, I had missed all the public errors that were structs (as opposed to enums). Now included.

Sweeet, macro finds to unusual error types, they were added in commit: 1a2cf2681 Implement consensus encoding adapter for serde by you @Kixunil. Are we happy with DecodeError and DecodeInitError not implementing the usual traits?
I've added FIXME to mark the two errors.

Good question, IIRC those errors are meant to be converted to serde errors. But adding the impls wouldn't be too bad. I think we should check Send + Sync at least.

I elected to implement Display and std::error::Error for both types, added as an initial patch.

I rebased this one, but to do the rebase properly I have to go through the whole codebase and check no new errors were introduced since I last did this. I can't be bothered doing that. Can we just agree that this PR might miss adding the macro to some errors, and keep an eye out?

Honestly now I'm a little tempted to scrap this PR in favor of just using some creative greping on the output of #1880, which would be resilient against new errors being introduced.

That's not a bad idea because it would put further "coding policy" things into the same place instead of having a bunch of macros that one must remember to call (assuming we come up with more things like that introduced here).

Draft until #1880 resolves.

Looks like we are going to use cargo public-api to solve this problem.
ref: https://github.com/rust-bitcoin/hex-conservative/pull/34

@tcharding it'd still be nice to have some tool to check that the API is good in the first place (e.g. an error type implements std::error::Error). cargo public-api helps with the biggest footguns though.

@Kixunil right -- after bringing in cargo public-api we had a vague plan to write some shell scripts (or Perl or whatever) that would run in CI and do sanity checks like "if a type has Error in its name then it impls std::error::Error".
Unfortunately every specific rule we've thought of has had a bunch of exceptions :) but if you have ones in mind it'd be awesome to start doing it. Maybe in hex-conservative first where we have a much smaller API.


Fix ids of custom links

The ids shouldn't come from the links but from the labels.
http://forge.prestashop.com/browse/BOOM-1855
http://forge.prestashop.com/browse/BOOM-1916

Thank you @antoin-m 🔎


Alternative payment

@djade007 I want to make payment with other options like mobile money enabled. How should i go around it. Thank you

Is this for web or mobile app?

Is this for web or mobile app?

mobile app

Have you tried this plugin: https://pub.dev/packages/flutter_paystack?

Mobile app
Sent from Yahoo Mail for iPhone
On Wednesday, April 21, 2021, 1:43 PM, Afeez Olajide @.***> wrote:
Is this for web or mobile app?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or unsubscribe.

https://pub.dev/packages/flutter_paystack

Well i have to migrate to null safety first and i have well over 20 packages which is not on null safety it will cause a lot of errors in the app which is not an ideal solution.
i tried https://pub.dev/packages/paystack_manager but the problem is routing back to homepage after successful transaction.

You will need to use an old version of plugin.
You can include the exact version in your pubspec
Don't use this ❌
flutter_paystack: ^1.0.4+1
Use this instead ✅
flutter_paystack: 1.0.4+1


Tzdybal/light stub

Resolves https://github.com/rollkit/rollkit/issues/673.

Codecov Report
Base: 55.15% // Head: 55.03% // Decreases project coverage by -0.12% :warning:

Coverage data is based on head (8b300ea) compared to base (b82de97).
Patch coverage: 0.00% of modified lines in pull request are covered.

: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
Additional details and impacted files
@@            Coverage Diff             @@
##             main     #724      +/-   ##
==========================================
- Coverage   55.15%   55.03%   -0.12%
==========================================
  Files          52       52
  Lines        9755     9816      +61
==========================================
+ Hits         5380     5402      +22
- Misses       3577     3623      +46
+ Partials      798      791       -7

Impacted Files
Coverage Δ

node/light.go
0.00% <0.00%> (ø)

node/node.go
52.38% <0.00%> (-26.20%)
:arrow_down:

state/executor.go
65.45% <0.00%> (+0.72%)
:arrow_up:

block/manager.go
65.90% <0.00%> (+2.95%)
:arrow_up:

types/validation.go
51.16% <0.00%> (+13.95%)
:arrow_up:

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

:umbrella: View full report at Codecov.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.


Connected Channel has ref to Channelz

If a server sends a GOAWAY, the grpc_subchannel object can be destroyed before client_channelz is able to intercept trailing metadata.
ConnectedSubchannel needs to hold a ref to channelz object so we can still do that bookkeeping on the GOAWAY-ed call, before the channelz objects is destroyed

****************************************************************

libgrpc.so

     VM SIZE                                                                FILE SIZE
 ++++++++++++++ GROWING                                                  ++++++++++++++
  +0.0%     +64 [None]                                                   +3.00Ki  +0.0%
  +4.1%    +288 src/core/ext/filters/client_channel/subchannel.cc           +288  +4.1%
       +15%    +128 on_subchannel_connected                                     +128   +15%
      [NEW]    +126 grpc_core::ConnectedSubchannel::ConnectedSubchannel         +126  [NEW]
      +539%    +124 grpc_core::ConnectedSubchannel::~ConnectedSubchannel        +124  +539%
      +2.1%      +6 [Unmapped]                                                    +6  +2.1%

  +0.0%    +352 TOTAL                                                    +3.28Ki  +0.0%

****************************************************************

libgrpc++.so

     VM SIZE        FILE SIZE
 ++++++++++++++  ++++++++++++++

  [ = ]       0        0  [ = ]

[trickle] No significant performance differences

Objective-C binary sizes
*****************STATIC******************
  New size                      Old size
 1,966,158      Total (>)      1,965,918

 No significant differences in binary sizes

***************FRAMEWORKS****************
  New size                      Old size
10,892,200      Total (>)     10,891,791

 No significant differences in binary sizes

****************************************************************

libgrpc.so

     VM SIZE                                                                FILE SIZE
 ++++++++++++++ GROWING                                                  ++++++++++++++
  +0.0%     +80 [None]                                                   +3.12Ki  +0.0%
  +3.9%    +272 src/core/ext/filters/client_channel/subchannel.cc           +272  +3.9%
       +15%    +128 on_subchannel_connected                                     +128   +15%
      +539%    +124 grpc_core::ConnectedSubchannel::~ConnectedSubchannel        +124  +539%
      [NEW]    +108 grpc_core::ConnectedSubchannel::ConnectedSubchannel         +108  [NEW]
      +2.8%      +8 [Unmapped]                                                    +8  +2.8%

  +0.0%    +352 TOTAL                                                    +3.38Ki  +0.0%

****************************************************************

libgrpc++.so

     VM SIZE        FILE SIZE
 ++++++++++++++  ++++++++++++++

  [ = ]       0        0  [ = ]

[trickle] No significant performance differences

Objective-C binary sizes
*****************STATIC******************
  New size                      Old size
 1,966,074      Total (>)      1,965,918

 No significant differences in binary sizes

***************FRAMEWORKS****************
  New size                      Old size
10,892,199      Total (>)     10,891,800

 No significant differences in binary sizes

[microbenchmarks] No significant performance differences

****************************************************************

libgrpc.so

     VM SIZE                                                                                FILE SIZE
 ++++++++++++++ GROWING                                                                              ++++++++++++++
  +7.8%    +552 src/core/ext/filters/client_channel/subchannel.cc                                       +552  +7.8%
      [NEW]    +414 recv_trailing_metadata_ready_channelz                                                   +414  [NEW]
      +151%    +127 grpc_subchannel_call_process_op                                                         +127  +151%
      +2.3%      +8 grpc_core::ConnectedSubchannel::CreateCall                                                +8  +2.3%
      +1.0%      +3 [Unmapped]                                                                                +3  +1.0%

 -------------- SHRINKING                                                                            --------------
  -2.6%    -928 src/core/ext/filters/client_channel/client_channel.cc                                   -928  -2.6%
      [DEL]    -498 recv_trailing_metadata_ready_channelz                                                   -498  [DEL]
      [DEL]    -367 add_closure_for_subchannel_batch(grpc_call_element*, grpc_transport_stream_op_batch*    -367  [DEL]
     -23.5%    -312 pending_batches_resume                                                                  -312 -23.5%
      [DEL]    -250 maybe_clear_pending_batch(grpc_call_element*, pending_batch*) [clone .isra.11]          -250  [DEL]
      [DEL]    -197 add_retriable_send_message_op(grpc_call_element*, subchannel_call_retry_state*, subc    -197  [DEL]
      [DEL]     -47 get_call_status(grpc_call_element*, grpc_metadata_batch*, grpc_error*, grpc_status_c     -47  [DEL]
      -5.8%     -36 recv_trailing_metadata_ready                                                             -36  -5.8%
      -8.6%     -35 [Unmapped]                                                                               -35  -8.6%
      -4.1%     -16 invoke_recv_initial_metadata_callback                                                    -16  -4.1%
  -0.0%    -184 [None]                                                                                -280  -0.0%

  -0.0%    -560 TOTAL                                                                                -656  -0.0%

****************************************************************

libgrpc++.so

     VM SIZE        FILE SIZE
 ++++++++++++++  ++++++++++++++

  [ = ]       0        0  [ = ]

Good call. I updated the code to intercept trailing in subchannel.cc instead of client_channel.cc. Seems much cleaner.
As far as the follow up, I am inclined to keep as is. AKA, the subchannel is the logical connection to a backend, not the actual connection. So if a connection breaks and reconnects, it will maintain the call count.
What do you think @carl-mastrangelo ?

I also incorporated the fix from #16829 into this, so I will close the other

[trickle] No significant performance differences

****************************************************************

libgrpc.so

     VM SIZE                                                                                FILE SIZE
 ++++++++++++++ GROWING                                                                              ++++++++++++++
   +12%    +840 src/core/ext/filters/client_channel/subchannel.cc                                       +840   +12%
      [NEW]    +414 recv_trailing_metadata_ready_channelz                                                   +414  [NEW]
       +15%    +128 on_subchannel_connected                                                                 +128   +15%
      +151%    +127 grpc_subchannel_call_process_op                                                         +127  +151%
      [NEW]    +126 grpc_core::ConnectedSubchannel::ConnectedSubchannel                                     +126  [NEW]
      +539%    +124 grpc_core::ConnectedSubchannel::~ConnectedSubchannel                                    +124  +539%
      +3.1%      +9 [Unmapped]                                                                                +9  +3.1%
      +2.3%      +8 grpc_core::ConnectedSubchannel::CreateCall                                                +8  +2.3%

 -------------- SHRINKING                                                                            --------------
  -2.6%    -928 src/core/ext/filters/client_channel/client_channel.cc                                   -928  -2.6%
      [DEL]    -498 recv_trailing_metadata_ready_channelz                                                   -498  [DEL]
      [DEL]    -367 add_closure_for_subchannel_batch(grpc_call_element*, grpc_transport_stream_op_batch*    -367  [DEL]
     -23.5%    -312 pending_batches_resume                                                                  -312 -23.5%
      [DEL]    -250 maybe_clear_pending_batch(grpc_call_element*, pending_batch*) [clone .isra.11]          -250  [DEL]
      [DEL]    -197 add_retriable_send_message_op(grpc_call_element*, subchannel_call_retry_state*, subc    -197  [DEL]
      [DEL]     -47 get_call_status(grpc_call_element*, grpc_metadata_batch*, grpc_error*, grpc_status_c     -47  [DEL]
      -5.8%     -36 recv_trailing_metadata_ready                                                             -36  -5.8%
      -8.6%     -35 [Unmapped]                                                                               -35  -8.6%
      -4.1%     -16 invoke_recv_initial_metadata_callback                                                    -16  -4.1%

 -+-+-+-+-+-+-+ MIXED                                                                                +-+-+-+-+-+-+-
  -0.0%    -120 [None]                                                                               +2.73Ki  +0.0%

  -0.0%    -208 TOTAL                                                                                +2.65Ki  +0.0%

****************************************************************

libgrpc++.so

     VM SIZE        FILE SIZE
 ++++++++++++++  ++++++++++++++

  [ = ]       0        0  [ = ]

[trickle] No significant performance differences

Objective-C binary sizes
*****************STATIC******************
  New size                      Old size
 1,965,674      Total (<)      1,965,918

 No significant differences in binary sizes

***************FRAMEWORKS****************
  New size                      Old size
10,891,493      Total (<)     10,891,795

 No significant differences in binary sizes

[microbenchmarks] Performance differences noted:
Benchmark           cpu_time    real_time
------------------  ----------  -----------
BM_SliceFromStatic  +6%         +6%

****************************************************************

libgrpc.so

     VM SIZE                                                                                FILE SIZE
 ++++++++++++++ GROWING                                                                              ++++++++++++++
   +12%    +824 src/core/ext/filters/client_channel/subchannel.cc                                       +824   +12%
      [NEW]    +414 recv_trailing_metadata_ready_channelz                                                   +414  [NEW]
       +15%    +128 on_subchannel_connected                                                                 +128   +15%
      +151%    +127 grpc_subchannel_call_process_op                                                         +127  +151%
      +539%    +124 grpc_core::ConnectedSubchannel::~ConnectedSubchannel                                    +124  +539%
      [NEW]    +108 grpc_core::ConnectedSubchannel::ConnectedSubchannel                                     +108  [NEW]
      +3.8%     +11 [Unmapped]                                                                               +11  +3.8%
      +2.3%      +8 grpc_core::ConnectedSubchannel::CreateCall                                                +8  +2.3%

 -------------- SHRINKING                                                                            --------------
  -2.6%    -928 src/core/ext/filters/client_channel/client_channel.cc                                   -928  -2.6%
      [DEL]    -498 recv_trailing_metadata_ready_channelz                                                   -498  [DEL]
      [DEL]    -367 add_closure_for_subchannel_batch(grpc_call_element*, grpc_transport_stream_op_batch*    -367  [DEL]
     -23.5%    -312 pending_batches_resume                                                                  -312 -23.5%
      [DEL]    -250 maybe_clear_pending_batch(grpc_call_element*, pending_batch*) [clone .isra.11]          -250  [DEL]
      [DEL]    -197 add_retriable_send_message_op(grpc_call_element*, subchannel_call_retry_state*, subc    -197  [DEL]
      [DEL]     -47 get_call_status(grpc_call_element*, grpc_metadata_batch*, grpc_error*, grpc_status_c     -47  [DEL]
      -5.8%     -36 recv_trailing_metadata_ready                                                             -36  -5.8%
      -8.6%     -35 [Unmapped]                                                                               -35  -8.6%
      -4.1%     -16 invoke_recv_initial_metadata_callback                                                    -16  -4.1%

 -+-+-+-+-+-+-+ MIXED                                                                                +-+-+-+-+-+-+-
  -0.0%    -104 [None]                                                                               +2.85Ki  +0.0%

  -0.0%    -208 TOTAL                                                                                +2.75Ki  +0.0%

****************************************************************

libgrpc++.so

     VM SIZE        FILE SIZE
 ++++++++++++++  ++++++++++++++

  [ = ]       0        0  [ = ]

[trickle] No significant performance differences

Objective-C binary sizes
*****************STATIC******************
  New size                      Old size
 1,965,914      Total (<)      1,965,918

 No significant differences in binary sizes

***************FRAMEWORKS****************
  New size                      Old size
10,891,891      Total (>)     10,891,792

 No significant differences in binary sizes

do we want all of the stats to be shown as the same subchannel or different subchannels?

Is it possible to represent multiple sockets being associated with a single subchannel?  If it would be hard, then it seems like a separate subchannel would be right.  After a GOAWAY, logically a subchannel cannot be "load balanced" over, which is the current definition IIRC.  Updating counter in separate subchannels  might be more logical though.  If you knew which subchannel a call was associated with, the id wouldn't change.

[microbenchmarks] No significant performance differences

Objective-C binary sizes
*****************STATIC******************
  New size                      Old size
 1,965,830      Total (<)      1,965,918

 No significant differences in binary sizes

***************FRAMEWORKS****************
  New size                      Old size
10,891,894      Total (>)     10,891,797

 No significant differences in binary sizes

[microbenchmarks] No significant performance differences

****************************************************************

libgrpc.so

     VM SIZE                                                                                FILE SIZE
 ++++++++++++++ GROWING                                                                              ++++++++++++++
   +12%    +824 src/core/ext/filters/client_channel/subchannel.cc                                       +824   +12%
      [NEW]    +414 recv_trailing_metadata_ready                                                            +414  [NEW]
       +15%    +128 on_subchannel_connected                                                                 +128   +15%
      +151%    +127 grpc_subchannel_call_process_op                                                         +127  +151%
      +539%    +124 grpc_core::ConnectedSubchannel::~ConnectedSubchannel                                    +124  +539%
      [NEW]    +108 grpc_core::ConnectedSubchannel::ConnectedSubchannel                                     +108  [NEW]
      +3.8%     +11 [Unmapped]                                                                               +11  +3.8%
      +2.3%      +8 grpc_core::ConnectedSubchannel::CreateCall                                                +8  +2.3%

 -------------- SHRINKING                                                                            --------------
  -2.6%    -928 src/core/ext/filters/client_channel/client_channel.cc                                   -928  -2.6%
      [DEL]    -498 recv_trailing_metadata_ready_channelz                                                   -498  [DEL]
      [DEL]    -367 add_closure_for_subchannel_batch(grpc_call_element*, grpc_transport_stream_op_batch*    -367  [DEL]
     -23.5%    -312 pending_batches_resume                                                                  -312 -23.5%
      [DEL]    -250 maybe_clear_pending_batch(grpc_call_element*, pending_batch*) [clone .isra.11]          -250  [DEL]
      [DEL]    -197 add_retriable_send_message_op(grpc_call_element*, subchannel_call_retry_state*, subc    -197  [DEL]
      [DEL]     -47 get_call_status(grpc_call_element*, grpc_metadata_batch*, grpc_error*, grpc_status_c     -47  [DEL]
      -5.8%     -36 recv_trailing_metadata_ready                                                             -36  -5.8%
      -8.6%     -35 [Unmapped]                                                                               -35  -8.6%
      -4.1%     -16 invoke_recv_initial_metadata_callback                                                    -16  -4.1%

 -+-+-+-+-+-+-+ MIXED                                                                                +-+-+-+-+-+-+-
  -0.0%    -104 [None]                                                                               +2.78Ki  +0.0%

  -0.0%    -208 TOTAL                                                                                +2.68Ki  +0.0%

****************************************************************

libgrpc++.so

     VM SIZE        FILE SIZE
 ++++++++++++++  ++++++++++++++

  [ = ]       0        0  [ = ]

****************************************************************

libgrpc.so

     VM SIZE                                                                                FILE SIZE
 ++++++++++++++ GROWING                                                                              ++++++++++++++
  +7.8%    +552 src/core/ext/filters/client_channel/subchannel.cc                                       +552  +7.8%
      [NEW]    +414 recv_trailing_metadata_ready                                                            +414  [NEW]
      +151%    +127 grpc_subchannel_call_process_op                                                         +127  +151%
      +2.3%      +8 grpc_core::ConnectedSubchannel::CreateCall                                                +8  +2.3%
      +1.0%      +3 [Unmapped]                                                                                +3  +1.0%

 -------------- SHRINKING                                                                            --------------
  -2.6%    -928 src/core/ext/filters/client_channel/client_channel.cc                                   -928  -2.6%
      [DEL]    -498 recv_trailing_metadata_ready_channelz                                                   -498  [DEL]
      [DEL]    -367 add_closure_for_subchannel_batch(grpc_call_element*, grpc_transport_stream_op_batch*    -367  [DEL]
     -23.5%    -312 pending_batches_resume                                                                  -312 -23.5%
      [DEL]    -250 maybe_clear_pending_batch(grpc_call_element*, pending_batch*) [clone .isra.11]          -250  [DEL]
      [DEL]    -197 add_retriable_send_message_op(grpc_call_element*, subchannel_call_retry_state*, subc    -197  [DEL]
      [DEL]     -47 get_call_status(grpc_call_element*, grpc_metadata_batch*, grpc_error*, grpc_status_c     -47  [DEL]
      -5.8%     -36 recv_trailing_metadata_ready                                                             -36  -5.8%
      -8.6%     -35 [Unmapped]                                                                               -35  -8.6%
      -4.1%     -16 invoke_recv_initial_metadata_callback                                                    -16  -4.1%
  -0.0%    -184 [None]                                                                                -360  -0.0%

  -0.0%    -560 TOTAL                                                                                -736  -0.0%

****************************************************************

libgrpc++.so

     VM SIZE        FILE SIZE
 ++++++++++++++  ++++++++++++++

  [ = ]       0        0  [ = ]

[trickle] No significant performance differences

Objective-C binary sizes
*****************STATIC******************
  New size                      Old size
 1,965,814      Total (<)      1,965,918

 No significant differences in binary sizes

***************FRAMEWORKS****************
  New size                      Old size
10,891,880      Total (>)     10,891,794

 No significant differences in binary sizes

[microbenchmarks] No significant performance differences

Objective-C binary sizes
*****************STATIC******************
  New size                      Old size
 1,965,658      Total (<)      1,965,918

 No significant differences in binary sizes

***************FRAMEWORKS****************
  New size                      Old size
10,891,474      Total (<)     10,891,788

 No significant differences in binary sizes

****************************************************************

libgrpc.so

     VM SIZE                                                                                FILE SIZE
 ++++++++++++++ GROWING                                                                              ++++++++++++++
   +11%    +744 src/core/ext/filters/client_channel/subchannel.cc                                       +744   +11%
      [NEW]    +414 recv_trailing_metadata_ready                                                            +414  [NEW]
       +15%    +128 on_subchannel_connected                                                                 +128   +15%
      +151%    +127 grpc_subchannel_call_process_op                                                         +127  +151%
      [NEW]    +108 grpc_core::ConnectedSubchannel::ConnectedSubchannel                                     +108  [NEW]
      +217%     +50 grpc_core::ConnectedSubchannel::~ConnectedSubchannel                                     +50  +217%
      +2.3%      +8 grpc_core::ConnectedSubchannel::CreateCall                                                +8  +2.3%
      +1.7%      +5 [Unmapped]                                                                                +5  +1.7%

 -------------- SHRINKING                                                                            --------------
  -2.6%    -928 src/core/ext/filters/client_channel/client_channel.cc                                   -928  -2.6%
      [DEL]    -498 recv_trailing_metadata_ready_channelz                                                   -498  [DEL]
      [DEL]    -367 add_closure_for_subchannel_batch(grpc_call_element*, grpc_transport_stream_op_batch*    -367  [DEL]
     -23.5%    -312 pending_batches_resume                                                                  -312 -23.5%
      [DEL]    -250 maybe_clear_pending_batch(grpc_call_element*, pending_batch*) [clone .isra.11]          -250  [DEL]
      [DEL]    -197 add_retriable_send_message_op(grpc_call_element*, subchannel_call_retry_state*, subc    -197  [DEL]
      [DEL]     -47 get_call_status(grpc_call_element*, grpc_metadata_batch*, grpc_error*, grpc_status_c     -47  [DEL]
      -5.8%     -36 recv_trailing_metadata_ready                                                             -36  -5.8%
      -8.6%     -35 [Unmapped]                                                                               -35  -8.6%
      -4.1%     -16 invoke_recv_initial_metadata_callback                                                    -16  -4.1%

 -+-+-+-+-+-+-+ MIXED                                                                                +-+-+-+-+-+-+-
  -0.0%    -144 [None]                                                                               +2.29Ki  +0.0%

  -0.0%    -328 TOTAL                                                                                +2.11Ki  +0.0%

****************************************************************

libgrpc++.so

     VM SIZE        FILE SIZE
 ++++++++++++++  ++++++++++++++

  [ = ]       0        0  [ = ]

[trickle] No significant performance differences

Objective-C binary sizes
*****************STATIC******************
  New size                      Old size
 1,965,794      Total (<)      1,965,918

 No significant differences in binary sizes

***************FRAMEWORKS****************
  New size                      Old size
10,891,877      Total (>)     10,891,797

 No significant differences in binary sizes

[microbenchmarks] No significant performance differences


lib.customisation: Refactor nested set access & avoid some allocations

Description of changes

Things done

Built on platform(s)

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

For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] Tested, as applicable:

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

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

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[ ] Fits CONTRIBUTING.md.

Priorities
Add a :+1: reaction to pull requests you find important.

I originally had a third commit on top of this PR that looked like:
From ee5b0e7be869b4b23623591d324931b542883231 Mon Sep 17 00:00:00 2001
From: adisbladis<EMAIL_ADDRESS>Date: Mon, 27 Nov 2023 12:35:13 +1300
Subject: [PATCH] lib.customisation: Avoid allocating intermediate lists/attrs

---
 lib/customisation.nix | 13 +++++++++----
 1 file changed, 9 insertions(+), 4 deletions(-)

diff --git a/lib/customisation.nix b/lib/customisation.nix
index dec1ab9f4faa..d13a7c873e0a 100644
--- a/lib/customisation.nix
+++ b/lib/customisation.nix
@@ -161,10 +161,15 @@ rec {
       # a list of argument names that the function requires, but
       # wouldn't be passed to it
       missingArgs =
-        # Filter out arguments that have a default value
-        (filterAttrs (name: value: ! value)
-        # Filter out arguments that would be passed
-        (removeAttrs fargs (attrNames allArgs)));
+        filterAttrs
+        (
+          name: value:
+          # Filter out arguments that would be passed
+          ! allArgs ? ${name}
+          # Filter out arguments that have a default value
+          && ! value
+        )
+        fargs;

       # Get a list of suggested argument names for a given missing one
       getSuggestions = arg: pipe (autoArgs // args) [
--
2.42.0

but that generated a slowdown because of the extra filterAttrs iteration.
In this case it is actually faster to chain a removeAttrs & filterAttrs together.


async client: add hash_policy option

Signed-off-by: Kuat Yessenov<EMAIL_ADDRESS>Description:
Add hash policy to the async client. This is needed to support consistent hash load balancing for external requests originating from the proxy (e.g. telemetry, ext authz, WASM, etc).
PR moves hash policy implementation to http namespace with no functional changes.
/cc @mandarjog
Risk Level: low
Testing: unit test
Docs Changes: none
Release Notes: none
Fixes #4899

Friendly ping.

Ping?

Whoops sorry, this one fell through the cracks last week. I'll review by tomorrow.

@junr03 @goaway please review. Thank you.

The failing test looks like a random chance (birthday paradox?)
Can someone retrigger it?

/retest

/retest

This is finally de-flaked!
@junr03 do you mind taking a look?

LGTM, can you merge master to pick latest CI change?

@lizan Ping?

@kyessenov can you merge master?

@lizan Done master merge.


Python 3

Add support for Python 3. Currently i have a problem with hmac

I will add support for Python 3.


fix(bing): increase timeout to prevent timeout error

Increase the timeout for the Web Socket from a default of 5 seconds to 20 seconds.
The error will only really occur on peak times, but this fix will prevent any timeout error.
Will fix errors mentioned in #328 and #338.

Thank you for the pull request!


[WIP] 2.0

Todo:

[x] import cov-core into repository
[x] run tests against cov-core master, too
[x] PEP8, run flake8 against all projects
[x] use data_suffix=True instead of building it manually
[x] allow to specify data_file (https://github.com/schlamar/cov-core/issues/4)
[x] better way to get coverage data from xdist slaves (e.g. transmit content of coverage data file) there is probably no better way
[x] test COVERAGE_FILE environment variable
[x] allow source from coveragerc (https://github.com/schlamar/pytest-cov/pull/21)
[x] fail under (#31)
[ ] cmd API: providing only --cov-source without --cov should enable the plugin, too
[ ] update README (new cmd API + deprecation note)
[x] test COVERAGE_FILE env variable
[ ] CHANGELOG(s)
[ ] update classifiers in setup.py
[ ] rename repository to py-cov and update URL in projects

Ideas:

use coverage.py's way of measuring subprocesses (http://nedbatchelder.com/code/coverage/subprocess.html)
single item which will break backwards compatibility, so no.

Hi! Just wondering if there's plans to publish the 2.0 branch to pypi in any nearest future?

If someone is willing to resolve the remaining issues. I have no time right now for them.

We really need the --cov-min option, so we will have a look.


Add useful troubleshooting information to the log collector

Add vmststat and network information to the ecs-log-collector script
The vmststat output will allow troubleshooting if the Instance running the ECS tasks is facing I/O issues, useful to quickly check if the issue is because the EBS volume is running out IOPS
Network status will allow us to check if there is something wrong with the network interfaces or even if there was a change in the OS route table which is affecting docker.

Is this gonna get merged?


[Request] Provide a core version for CDN to be used in browser

Currently highlight.min.js is about 120Kb, which is not bad, but I often only need the support for only a few (most likely to be no more than three) languages on a page. I wonder if you'd consider providing a bare minimal core version on CDN, and users can selectively load the languages they need. This is possible for ES6 modules:
import hljs from 'highlight.js/lib/core';

and it will be nice to be able to do this in browser, too:
<!-- load the core -->
<script src="https://cdn.jsdelivr.net/gh/highlightjs/cdn-release/build/core.min.js"></script>

<!-- then load languages we need -->
<script src="https://cdn.jsdelivr.net/gh/highlightjs/cdn-release/build/languages/c.min.js"></script>
<script src="https://cdn.jsdelivr.net/gh/highlightjs/cdn-release/build/languages/go.min.js"></script>
<script src="https://cdn.jsdelivr.net/gh/highlightjs/cdn-release/build/languages/latex.min.js"></script>

Thanks!

Pretty sure we already do this:

https://github.com/highlightjs/cdn-release/blob/11-stable/build/es/core.js
https://github.com/highlightjs/cdn-release/blob/11-stable/build/es

Yes, I was aware of the core module, but I meant a script that could be loaded in browser via <script src=""> instead of
<script type="module">
import hljs from<EMAIL_ADDRESS></script>

The module won't work:
<script<EMAIL_ADDRESS></script>

I know that highlight.min.js was built via node tools/build.js :common, and my request was to build a core version without :common languages and release it to CDN.

And of course you can build your own version easily enough with how every many (or few) languages you want... I think the version we currently ship is a great mix for many at a very low cost - only 40kb gzipped.
I'm lost though.  We ship core in both ESM (ES modules) and CJS (ILM) versions, I'm not sure exactly what you're asking for here.

Sorry about the confusion. Yes, I know I can build my own version, and I was hoping for an "official" release.
Let me try to clarify what I was asking for. First, this is what we typically do:
<script src="build/highlight.min.js"></script>

<!-- then load extra languages we need, e.g., latex, which is not in :common -->
<script src="build/languages/latex.min.js"></script>

highlight.min.js contains 30+ common languages, most of which I rarely need. What I wish for is a core.min.js that contains no languages at all, so that I can load any specific languages I need:
<script src="build/core.min.js"></script>

<!-- then load specific languages we need -->
<script src="build/languages/c.min.js"></script>
<script src="build/languages/latex.min.js"></script>

I don't have much expertise on JavaScript, so please forgive my ignorance. If this core version is provided, I can use jsdelivr's combine feature to combine the core with the few extra language files, and the result would be super lightweight (although I agree the current highlight.min.js is relatively lightweight, as I mentioned in my first post).
Again, I don't know much about tools for building JavaScript, and my gut feeling is that this task could be done by adding a line after: https://github.com/highlightjs/highlight.js/blob/14aa378de464e0d0ffe41aa0415bb28ac188ac59/tools/build_cdn.js#L56
something like this?
  await buildCore("core", [], { minify: options.minify, format: "cjs" });

Yeah, this older usage (CJS/ILM) is what we're moving away from - in favor of ES6 everywhere.  Simply use the new ES6 code (with modules) and you already have everything you need with existing builds.
At the moment we have no plans to expand the scope of the CJS library.  I may go away entirely with version 12 and those wanting to stay on CJS a bit longer would keep using version 11.

Thanks for sharing the possible roadmap! I don't know your motivation to drop the support for CJS, but the old usage is critical to me. This made me take a look at Prism for the first time, although I've heard about it for a long time. I was happy to find out that it has exactly what I asked for in this issue:
<script<EMAIL_ADDRESS>
And the core is tiny. I'll take a closer look in the next few days.
I have been a happy highlight.js user for over a decade, and I truly appreciate the contribution from all authors/maintainers/contributors!

but the old usage is critical to me

Why?

This made me take a look at Prism for the first time

Prism is great, but they are also going ES6 (and dropping support for older browsers) with the next release IIRC - though I'm not sure about their plans to continue to publish older CJS builds...

I don't know your motivation to drop the support for CJS

Same old reasons: ongoing development and support costs are higher supporting multiple versions of things.

We haven't supported IE and other old browsers for some time.
We officially support only green-field browsers and Node

all these environments well-support ES6 modules in 2023...

Just played around with this briefly, using rollup one can generate CJS versions of ES modules super trivially:
rollup -f iife -i build/es/core.js -o core.cjs.js --name hljs

Why?

Maybe it's my ignorance, but to my knowledge, modules must be defined in external files. My use case is to make an html file self-contained (which can be easily shared and viewed offline) and not rely on external files, which means all JS code must be embedded in the html file. With the good old CJS, this is quite trivial to achieve---simply read the external JS code into the <script> tag. With ES6 modules, this doesn't seem straightforward to me, i.e., how to convert import foo from "bar.js" into self-contained JS code that can be embedded directly in <script>? Maybe there are special tools and I don't know.

Just played around with this briefly, using rollup one can generate CJS versions of ES modules super trivially:

Thanks! I was aware of tools like rollup and have used it a couple of times before. Indeed it is trivially easy. Exactly because of that, I was asking for the "official" support. I understand that maintaining multiple versions of things brings complexities, but in this case, I don't see a high support cost (the only risk I could see is that rollup might die someday and you'll be in trouble, but I feel that's quite unlikely).

Prism is great, but they are also going ES6 (and dropping support for older browsers) with the next release IIRC - though I'm not sure about their plans to continue to publish older CJS builds...

I'm always in favor of dropping support for older browsers. I don't care about older browsers. If they are going to drop CJS builds, too, I guess the only way I could move forward is to build them by myself. I hope not to do that, but a last resort is better than none.

use case is to make an html file self-contained

This is an edge case already (yet readily solved with a tool such as rollup).

I don't see a high support cost

This is either a tip of the iceberg problem or else a "how high is too high"...  We currently maintain (and test) 3 different builds of the project, we force 3rd party authors to worry about multiple build types.  We must maintain documentation for require and import, etc... it's been quite painful trying to figure out the "best" way to ship a combined CJS + ES6 library...   there are all sorts of small things that add up.  This is all effort and complexity that we would rather not maintain - IF it can be avoided.
Many libraries went ES6 only a year or so ago - we purposely held out then... but now it's time to take the leap.  Those wanting CJS can easily use Highlight.js 11 a while longer, or just run us thru a build tool such a rollup to generate legacy output.

Many thanks for the explanation! That makes sense (and also resonates with me as an open-source developer).


Navigation to symbols declared in dart:html library broken

Reproducible since SDK 1.18 and up to the latest 1.20-dev.10.1 if summaries are enabled.
Simple single-file project:
import "dart:html";
main() {
  querySelector("");
}

Analysis Server gives navigation info for querySelector reference. Target file is SDK/lib/html/dartium/html_dartium.dart, but target offset/line/column (1406076/43434/9) is incorrect, there's some unrelated stuff at this offset in html_dartium.dart.
BUT querySelector function declaration in SDK/lib/html/dart2js/html_dart2js.dart file is exactly at this offset!
Also Analysis Server gives no highlighting and navigation info for the  html_dartium.dart file itself. Let me know if it should be tracked separately.
Also if you open html_dartium.dart file in the editor Analysis Server throws an error:
Dart analysis server, SDK version 1.20.0-dev.10.1, server version 1.17.0, error: Failed to handle completion domain request: {clientRequestTime:<PHONE_NUMBER>778, params: {file: C:\dart_projects\untitled\bin\main.dart, offset: 44}, method: completion.getSuggestions, id: 51}
AnalysisException: failed to resolve expression
Caused by Mismatch in DeclarationResolver while resolving C:\dart\dart-dev-channel\lib\html\dartium\html_dartium.dart
Could not find element with name "_window" at 2194
Path to root: DeclaredSimpleIdentifier, VariableDeclarationImpl, VariableDeclarationListImpl, TopLevelVariableDeclarationImpl, CompilationUnitImpl
#0      RecursiveAstVisitor&ExistingElementResolver._mismatch (package:analyzer/src/generated/resolver.dart:3464)
#1      DeclarationResolver._findWithNameAndOffset (package:analyzer/src/generated/resolver.dart:2833)
#2      DeclarationResolver._findIdentifier (package:analyzer/src/generated/resolver.dart:2791)
#3      DeclarationResolver.visitVariableDeclaration (package:analyzer/src/generated/resolver.dart:2746)
#4      VariableDeclarationImpl.accept (package:analyzer/src/dart/ast/ast.dart:10773)
#5      NodeListImpl.accept (package:analyzer/src/dart/ast/ast.dart:7743)
#6      VariableDeclarationListImpl.visitChildren (package:analyzer/src/dart/ast/ast.dart:10871)
#7      RecursiveAstVisitor.visitVariableDeclarationList (package:analyzer/dart/ast/visitor.dart:1960)
#8      DeclarationResolver.visitVariableDeclarationList (package:analyzer/src/generated/resolver.dart:2763)
#9      VariableDeclarationListImpl.accept (package:analyzer/src/dart/ast/ast.dart:10865)
#10     TopLevelVariableDeclarationImpl.visitChildren (package:analyzer/src/dart/ast/ast.dart:10064)
#11     RecursiveAstVisitor.visitTopLevelVariableDeclaration (package:analyzer/dart/ast/visitor.dart:1918)
#12     DeclarationResolver.visitTopLevelVariableDeclaration (package:analyzer/src/generated/resolver.dart:2698)
#13     TopLevelVariableDeclarationImpl.accept (package:analyzer/src/dart/ast/ast.dart:10059)
#14     NodeListImpl.accept (package:analyzer/src/dart/ast/ast.dart:7743)
#15     CompilationUnitImpl.visitChildren (package:analyzer/src/dart/ast/ast.dart:2452)
#16     RecursiveAstVisitor.visitCompilationUnit (package:analyzer/dart/ast/visitor.dart:1449)
#17     CompilationUnitImpl.accept (package:analyzer/src/dart/ast/ast.dart:2445)
#18     DeclarationResolver.resolve (package:analyzer/src/generated/resolver.dart:2328)
#19     BuildCompilationUnitElementTask.internalPerform (package:analyzer/src/task/dart.dart:1080)
#20     AnalysisTask._safelyPerform (package:analyzer/task/model.dart:339)
#21     AnalysisTask.perform (package:analyzer/task/model.dart:238)
#22     AnalysisDriver.performWorkItem (package:analyzer/src/task/driver.dart:284)
#23     AnalysisDriver.performAnalysisTask (package:analyzer/src/task/driver.dart:255)
#24     AnalysisContextImpl.performAnalysisTask.<anonymous closure> (package:analyzer/src/context/context.dart:1184)
#25     _PerformanceTagImpl.makeCurrentWhile (package:analyzer/src/generated/utilities_general.dart:212)
#26     AnalysisContextImpl.performAnalysisTask (package:analyzer/src/context/context.dart:1182)
#27     PerformAnalysisOperation.perform (package:analysis_server/src/operation/operation_analysis.dart:362)
#28     AnalysisServer.performOperation (package:analysis_server/src/analysis_server.dart:894)
#29     Future.Future.<anonymous closure> (dart:async/future.dart:118)
#30     _rootRun (dart:async/zone.dart:1146)
#31     _CustomZone.run (dart:async/zone.dart:1026)
#32     _CustomZone.runGuarded (dart:async/zone.dart:924)
#33     _CustomZone.bindCallback.<anonymous closure> (dart:async/zone.dart:951)
#34     _rootRun (dart:async/zone.dart:1150)
#35     _CustomZone.run (dart:async/zone.dart:1026)
#36     _CustomZone.runGuarded (dart:async/zone.dart:924)
#37     _CustomZone.bindCallback.<anonymous closure> (dart:async/zone.dart:951)
#38     Timer._createTimer.<anonymous closure> (dart:async-patch/timer_patch.dart:16)
#39     _Timer._runTimers (dart:isolate-patch/timer_impl.dart:385)
#40     _Timer._handleMessage (dart:isolate-patch/timer_impl.dart:414)
#41     _RawReceivePortImpl._handleMessage (dart:isolate-patch/isolate_patch.dart:148)

@bwilkerson Is it just a P2? Navigation and highlighting are the most important features of the Analysis Server.

Some would argue that code completion is the most important feature. That aside, we tend to reserve P1 for issues that cause server to be unusable (such as crashes).

@scheglov

https://codereview.chromium.org/2404903002

https://github.com/dart-lang/sdk/commit/1fc611fe2ce575476bb205f80a8b78b692f68d6d


Support multiline strings

Is your feature request related to a problem? Please describe

The feel-scala engine, used in Zeebe, supports multiline strings. They can just be declared with double quotes, similar to single-line strings. However, the FEEL editor marks those multiline strings as erroneous and does not support syntax highlighting for them (it expects strings to end latest at the end of line). This misleads users thinking that multiline strings are not supported.

A few APIs expect unescaped line break characters for text bodies (instead of "/n" or "/r/n", such as the Github issue API. Multiline strings are mandatory here to serve those APIs with multiline text bodies.
Describe the solution you'd like

The parser recognizes multiline strings correctly and the editor applies correct syntax highlighting, without throwing an error.
Describe alternatives you've considered

Additional context

Oops, created it with the wrong account.

As long as we have it reported 😄

We'd need to verify against the DMN FEEL spec if multi-line strings are a thing. If that is the case this must be fixed in our parse tooling.

So if I read this correctly a a String is defined as a list of character without vertical Space

and vertical Space is Line Feed, Line Tab, Form Feed, Carriage Return

So Multi-Line Strings are not part of the Spec

Closing this as multi-line strings are not covered by the BPMN spec (cf. https://github.com/bpmn-io/feel-editor/issues/17#issuecomment-1255869673, double check).


Regression when migrating to SharedCredentialsFiles field

What happened?
When we are initializing our Provider we've been using SharedCredentialsFile. We wanted to upgrade from 4.9 -> 5.11.0 and we've noticed that the field is deprecated and we should move to use SharedCredentialsFiles when we tried to use this field it seems that it's being completely ignored and not used at all.
Errors we're seeing are:
  aws:sqs:Queue (diskanalyzer-scans-dlq):
    error: unable to validate AWS credentials. Make sure you have:

         • Set your AWS region, e.g. `pulumi config set aws:region us-west-2`
         • Configured your AWS credentials as per https://pulumi.io/install/aws.html
         You can also set these via cli using `aws configure`.

When we use the old field things seem to work fine.
Steps to reproduce
Use SharedCredentialsFile
Expected Behavior
AWS provider should use appropriate provider file
Actual Behavior
Seems that it's not being used at all
Output of pulumi about
❯ pulumi about
CLI
Version      3.26.1
Go Version   go1.17.8
Go Compiler  gc

Host
OS       darwin
Version  12.5.1
Arch     arm64

Backend
Name     Yarins-MacBook-Pro-4.local
URL      file:///Users/yarin/.pulumi-state
User     yarin

Additional context
Using automation api to invoke pulumi
Contributing
Vote on this issue by adding a 👍 reaction.
To contribute a fix for this issue, leave a comment (and link to your pull request, if you've opened one already).

Hi @yarinm
My apologies for this - you can skip this credentials validation check by using pulumi config set aws:skipCredentialsValidation true
I will ensure we get this working as expected now
Paul

Hey @stack72 even when we set skipCredentialsValidation it fails, it doesn't seem to use the new field for credential files


build: include --nobest while upgrading the devel container packages

On occasion there are inconsistencies in the CentOS or Ceph RPM
repositories. This can cause dnf update to fail when there are
conflicting versions of a package. By adding the --nobest option,
packages can get upgraded to an older version, but not the latest.
Signed-off-by: Niels de Vos<EMAIL_ADDRESS>

Maybe we should take this opportunity to make it like:
RUN dnf -y--nobest update \
      && dnf -y install \
    git \
    make \
    gcc \
    librados-devel \
    libcephfs-devel \
    librbd-devel \
    && dnf clean all \
    && rm -rf /var/cache/yum \
    && true

Maybe we should take this opportunity to make it like:
RUN dnf -y --nobest update \
      && dnf -y install \
    git \
    make \
    gcc \
    librados-devel \
    libcephfs-devel \
    librbd-devel \
    && dnf clean all \
    && rm -rf /var/cache/yum \
    && true

The current extra indention is added as the packages are part of the dnf -y install command. All stand-alone commands start with an indention and &&, so I think it is nicely aligned already.

@mergifyio queue


Real-time facades make raw calls to storage_path() instead of using the Cache abstraction

Laravel Version: 7.24.0
PHP Version: 7.4.9
Database Driver & Version: none

Description:
Unfortunately it seems like the facade cache doesn't make use of the Cache abstraction and makes raw calls to storage_path() instead, as seen https://github.com/laravel/framework/blob/c2f2867cb1c835fd32c91bc9a772c3ec1ce68894/src/Illuminate/Foundation/AliasLoader.php#L103 and https://github.com/laravel/framework/blob/0b12ef19623c40e22eff91a4b48cb13b3b415b25/src/Illuminate/Cache/Console/ClearCommand.php#L89
This creates an issue for lambda (and any kind of hardened read-only filesystem with restricted or no write paths) as the default file storage path is not writeable (see brefphp/laravel-bridge#8).
While changing the default storage path would fix my specific issue, it comes at the cost of allowing other stuff fail silently, as noted by @mnapoli on https://github.com/brefphp/laravel-bridge/pull/9#issuecomment-672684462
Steps To Reproduce:

Use a real-time facade

Use a real-time facade

Could you link us to what that is?

Use a real-time facade

Could you link us to what that is?

You mean this https://laravel.com/docs/7.x/facades#real-time-facades ?

Vapor takes care of this by tweaking the storage path environment variables I believe.

Vapor takes care of this by tweaking the storage path environment variables I believe.

Seeing as Real-Time Facades are the only thing not making use of the cache API I would say it's better to fix it so we can use redis and other cache backends instead of doing this workaround.

👍  using the cache API sounds like a more generic solution, is there a reason to favor not using the cache API?


Storing a File type object in store doesn't save it entirely

I'm trying to upload a blob/file type object with the following information

But when I save/store this in redux the only thing that gets saved is the preview property.
Is there  a way to get the whole blob/file to be saved in redux store/state?

You should only keep serializable objects in your store. In particular with Files, since they behave quite differently from normal objects.


multipliedBy with centerY/top

New Issue Checklist

[x] I have looked at the Documentation
[x] I have read the F.A.Q.

Issue Info

Info
Value

Platform
ios

Platform Version
9.3

SnapKit Version
0.21.1

Integration Method
carthage

Issue Description
Maybe I just have the wrong expectation - but when I do
make.centerY.equalTo(contentView.snp_top).multipliedBy(0.5)

both view still keep a constant distance to each other. In fact this seems to give the same result:
make.centerY.equalTo(contentView.snp_top)

Am I using the API right?
Or is this a general thing about autolayout that I am missing?

@tcurdt this is an Auto Layout thing, multiplier only works when going to a size constraint. So you could do make.centerY.equalTo(contentView.snp_height).multipliedBy(0.5) I believe (Im 99% sure that works but Auto Layout may complain there too)

Unfortunately it's also impossible for me to prevent the autocomplete from showing up.

Bummer. Thanks for the clarification.


[MINOR][SS][DOCS] Adapt multiple watermark policy comment to the reality

What changes were proposed in this pull request?
Previous comment was true for Apache Spark 2.3.0. The 2.4.0 release brought multiple watermark policy and therefore stating that the 'min' is always chosen is misleading.
This PR updates the comments about multiple watermark policy. They aren't true anymore since in case of multiple watermarks, we can configure which one will be applied to the query. This change was brought with Apache Spark 2.4.0 release.
Why are the changes needed?
It introduces some confusion about the real execution of the commented code.
Does this PR introduce any user-facing change?
No.
How was this patch tested?
The tests weren't added because the change is only about the documentation level. I affirm that the contribution is my original work and that I license the work to the project under the project's open source license.

Can one of the admins verify this patch?

Can one of the admins verify this patch?

Thank you for your first contribution, @bartosz25 . I updated your PR title a little.

ok to test

Thank you @dongjoon-hyun

Test build #110925 has started for PR 25832 at commit cec8296.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder-K8s/16040/
Test PASSed.

Test build #110925 has finished for PR 25832 at commit cec8296.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/110925/
Test PASSed.


Support HTTP/2

As pointed out in the README, Gorouter does not support HTTP/2.
This means as a CF app developer, I am unable to leverage the significant benefits of the new protocol version. Likewise, any CF component whose communication paths pass through the Gorouter may not benefit from HTTP/2 either. By Gorouter not supporting HTTP/2, for example, both app developers and CF components cannot use gRPC, which is increasingly becoming the standard for microservice development.
/cc @cloudfoundry/cf-loggregator

gRPC support is one of the most commonly requested features even from our customers. Sure, they can use TCP routing but then they lose a whole lot of the gorouter out-of-the-box experience (path/hostname routing, logging, TLS termination, ...)

Also, from what I understand, TCP routing is not enabled on all CF installations. That means CF components (such as loggregator) that need to work in every environment can not rely on TCP routing.

Now since node 8 is out, which has support for HTTP/2. We were planning to use it on our CF installations. This has a lot of good features that could be utilized for better UI experiences. Has this been considered as part of development for future quarters?

Closing this issue, we will keep the community updated via cf-dev as we build out the new routing subsystem. Proposal can be found here https://docs.google.com/document/d/1LgLY0g39fzpg1_4zTckbH1mOuuSKGvYwp2tkakoe9ys/edit


Uncaught NotFoundError in utils.py line 7480

Aider version: 0.56.0
Python version: 3.12.3
Platform: Linux-6.8.0-41-generic-x86_64-with-glibc2.39
Python implementation: CPython
Virtual environment: Yes
OS: Linux 6.8.0-41-generic (64bit)
Git version: git version 2.43.0
An uncaught exception occurred:
Traceback (most recent call last):
  File "vertex_httpx.py", line 1481, in completion
    response.raise_for_status()
  File "_models.py", line 763, in raise_for_status
    raise HTTPStatusError(message, request=request, response=self)
httpx.HTTPStatusError: Client error '404 Not Found' for url 'https://generativelanguage.googleapis.com/v1beta/models/gemini-1.5:generateContent?key=AIzaSyAJdEpOLj80WvggpYByemvYBXJVrk50730'
For more information check: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/404

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "main.py", line 2006, in completion
    response = vertex_chat_completion.completion(  # type: ignore
               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "vertex_httpx.py", line 1484, in completion
    raise VertexAIError(status_code=error_code, message=err.response.text)
litellm.llms.vertex_httpx.VertexAIError: {
  "error": {
    "code": 404,
    "message": "models/gemini-1.5 is not found for API version v1beta, or is not supported for generateContent. Call ListModels to see the list of available models and their supported methods.",
    "status": "NOT_FOUND"
  }
}

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "aider", line 8, in <module>
    sys.exit(main())
             ^^^^^^
  File "main.py", line 698, in main
    coder.run()
  File "base_coder.py", line 735, in run
    self.run_one(user_message, preproc)
  File "base_coder.py", line 778, in run_one
    list(self.send_message(message))
  File "base_coder.py", line 1202, in send_message
    saved_message = self.auto_commit(edited)
                    ^^^^^^^^^^^^^^^^^^^^^^^^
  File "base_coder.py", line 1885, in auto_commit
    res = self.repo.commit(fnames=edited, context=context, aider_edits=True)
          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "repo.py", line 102, in commit
    commit_message = self.get_commit_message(diffs, context)
                     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "repo.py", line 187, in get_commit_message
    commit_message = simple_send_with_retries(
                     ^^^^^^^^^^^^^^^^^^^^^^^^^
  File "sendchat.py", line 44, in wrapper
    return decorated_func(*args, **kwargs)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "_sync.py", line 105, in retry
    ret = target(*args, **kwargs)
          ^^^^^^^^^^^^^^^^^^^^^^^
  File "sendchat.py", line 106, in simple_send_with_retries
    _hash, response = send_completion(**kwargs)
                      ^^^^^^^^^^^^^^^^^^^^^^^^^
  File "sendchat.py", line 86, in send_completion
    res = litellm.completion(**kwargs)
          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "utils.py", line 1078, in wrapper
    raise e
  File "utils.py", line 966, in wrapper
    result = original_function(*args, **kwargs)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "main.py", line 2766, in completion
    raise exception_type(
          ^^^^^^^^^^^^^^^
  File "utils.py", line 8438, in exception_type
    raise e
  File "utils.py", line 7480, in exception_type
    raise NotFoundError(
litellm.exceptions.NotFoundError: litellm.NotFoundError: VertexAIException - {
  "error": {
    "code": 404,
    "message": "models/gemini-1.5 is not found for API version v1beta, or is not supported for generateContent. Call ListModels to see the list of available models and their supported methods.",
    "status": "NOT_FOUND"
  }
}

Thanks for trying aider and filing this issue.
It looks like you have specified an invalid vertex LLM model?
When reporting problems, it is very helpful if you can provide:

Aider version
LLM model you are using
A description of what you were doing when the error happened.

Including the “announcement” lines that aider prints at startup is an easy way to share some of this helpful info.
Aider v0.37.1-dev
Models: gpt-4o with diff edit format, weak model gpt-3.5-turbo
Git repo: .git with 243 files
Repo-map: using 1024 tokens

I'm going to close this issue for now, but feel free to add a comment here and I will re-open. Or feel free to file a new issue any time.


Outdated user- sign-in page (compared to new ADFS 5.0 Paginated sign-in)

Is this approach still applicable once switched to paginated sign-in? if not what options do we have?

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

ID: a2c2dc96-10bc-9afe-905e-7873377cdb16
Version Independent ID: 2c2c76d8-9a59-6c6a-4890-d48a15315a63
Content: AD FS user sign-in customization
Content Source: WindowsServerDocs/identity/ad-fs/operations/AD-FS-user-sign-in-customization.md
Product: windows-server-threshold
GitHub Login: @billmath
Microsoft Alias: billmath

Windows Server 2019 has been out for a couple months now, how about updating ADFS documentation? Everything seems horribly out of date and still references 2016, including this. Also, why isn't there some sort of "upgrade theme" wizard? Seems like we have to start largely from scratch.

i am stuck on Copywriter Page

Thanks for your dedication to our documentation. If we have been unable to review your issue in a timely manner, we sincerely apologize for the delayed response. We have captured the informtion you have provided for review. We are closing this issue for now, but if you feel that it's still a concern, please respond and let us know. If you determine another possible update to our documentation, please don't hesitate to reach out again. #please-close


⚠ Bofrost.de has degraded performance

In ac750b1, Bofrost.de (https://www.bofrost.de) experienced degraded performance:

HTTP code: 200
Response time: 1207 ms

Resolved: Bofrost.de performance has improved in 87743ba after 27 minutes.


Get our websockets working on the front end

have done as much as possible without socket server to test on

Okey dokey this done 'kay. (Well I've got connection between client and server, It's not actually working as the product is intended to).


[Docs] Update broken links

Fixed links to the docs around from/into and reasons to avoid/use
Thanks for the great work on bon!
Also added a step using https://github.com/UmbrellaDocs/action-linkspector to detect issue moving forward on PRs

Thank you for the PR!
I thought Vitepress already detects broken anchors in URLs because it definitely has an inbuilt link checker, but turns out it's not so advanced yet https://github.com/vuejs/vitepress/issues/646.
I've run the CI and turns out linkspector doesn't detect the broken links. A kind person shared their custom script that detects broken links in https://github.com/vuejs/vitepress/issues/646#issuecomment-1722916907. I'll use that instead.


around_validation error for Rails4.1.0beta

Hello!
I have following problem:
Page.last.to_draft
  Page Load (0.2ms)  SELECT "pages".* FROM "pages" ORDER BY "pages"."id" DESC LIMIT 1
   (0.1ms)  begin transaction
   (0.1ms)  rollback transaction
NoMethodError: protected method `around_validation' called for #<StateMachine::Machine:0x00000004382b98>

bin/rails --version
Rails 4.1.0.beta

Maybe it's will be interesting for somebody.
Thank you!

+1

Thank you @the-teacher for the fix

If it has not come to your attention yet, there is a maintained fork of this project by @seuros,
which is probably a better solution than to monkeypatch this abandoned project.
https://github.com/state-machines/state_machines

Thank You!

On Apr 12, 2015, at 12:15 PM, Niels Hoffmann<EMAIL_ADDRESS>wrote:
If it has not come to your attention yet, there is a maintained fork of this project by @seuros,
which is probably a better solution than to monkeypatch this abandoned project.
https://github.com/state-machines/state_machines
—
Reply to this email directly or view it on GitHub.

thank you @seuros and @nhoffmann, just saved my bacon! :-)

+1

+1

@keithgordon :
that i would like to do, but the fact is that i not see how to install and use this state_machines instead of the state_machine from rails-4.2.
The documentation is really big and full of data (to much maybe in one time ?) and then it's confused for me (i'm not an expert of rails too...).
Could you please be more explicit about "how to not use monkypatch (but really helpfull and simple) and use actives_machine" ?
Thanks again for help.

@the-teacher :
thanks for your patch. It was really simple to apply and offer a real solution in case of use your (really good) gems files.

word to the wise, while its great that somebody is supporting state_machine, it is not 100% the same behavior as the old state_machine gem... I suspect there were bugs in the old version that have been fixed.  At any rate, you might find during the upgrade the quickest fix is the monkey patch.

+1

+1

+1

Thanks @the-teacher, and @gingermusketeer!