Error: failed to load state at height 0; version mismatch on immutable IAVL tree; version does not exist. Version has either been pruned, or is for a future block height (latest height: 0): invalid request

I am working with Cosmos testnet node v12 via Cosmos Proto SDK in the following way:
let client = TendermintClient::ServiceClient::connect("node URL".to_string()).await;

Crate version: cosmos-sdk-proto = "0.19.0"
Additionally, I have tried to use the latest version from GitHub.
As a result, I received the following error:
 failed to load state at height 0; version mismatch on immutable IAVL tree; version does not exist. Version has either been pruned, or is for a future block height (latest height: 0): invalid request

I have done the following tests via the HTTP endpoints:
$ curl http://<node URL>:1317/blocks/latest

The highest block is 17835358:
{
  "block_id": {
    "hash": "1C84CE097EF655A0B5BB3F874C3B4B748D7F653292B50F68836F56B3556F86D8",
    "parts": {
      "total": 1,
      "hash": "40595178B93B553764F73A852C6F837653C7CE4712891D9948AA96BE5784D946"
    }
  },
  "block": {
    "header": {
      "version": {
        "block": "11"
      },
      "chain_id": "theta-testnet-001",
      "height": "17835358",
      "time": "2023-09-10T11:11:51.486101076Z",
      "last_block_id": {
        "hash": "1026E539C882C1C5E8B3C8262CD09D8205C5FC9BB3E76830CB5C8CA1E1E89D32",
        "parts": {
          "total": 1,
          "hash": "98483DD43E00E1993942937A04FF24926C04678D2851006096071B52B41144B8"
        }
      },
      "last_commit_hash": "345CC7546EDBBA9DAB2F89A297BC6593E90291BCA12A17B08095025FF3DAE93B",
      "data_hash": "E3B0C44298FC1C149AFBF4C8996FB92427AE41E4649B934CA495991B7852B855",
      "validators_hash": "EF9F456A7562650B06F360C4423EC38A5A88E232BC19B632EB20C4E62D07FA2C",
      "next_validators_hash": "EF9F456A7562650B06F360C4423EC38A5A88E232BC19B632EB20C4E62D07FA2C",
      "consensus_hash": "80364965B7C2CC9DE961C0998B47A7F93F1970077EB882E0ED1C3822408888C7",
      "app_hash": "EF19B35D697CC7C5D4F65578A5FC10F441966244D91A87CD64C46E83ACA3A8A7",
      "last_results_hash": "E3B0C44298FC1C149AFBF4C8996FB92427AE41E4649B934CA495991B7852B855",
      "evidence_hash": "E3B0C44298FC1C149AFBF4C8996FB92427AE41E4649B934CA495991B7852B855",
      "proposer_address": "30DA2AC9B9A34BCA21B3514CBDB1A9E6DE3CEAE0"
    },
    "data": {
      "txs": []
    },
    "evidence": {
      "evidence": []
    },
    "last_commit": {
      "height": "17835357",
      "round": 0,
      "block_id": {
        "hash": "1026E539C882C1C5E8B3C8262CD09D8205C5FC9BB3E76830CB5C8CA1E1E89D32",
        "parts": {
          "total": 1,
          "hash": "98483DD43E00E1993942937A04FF24926C04678D2851006096071B52B41144B8"
        }
      },
      "signatures": [
        {
          "block_id_flag": 2,
          "validator_address": "A8A7A64D1F8FFAF2A5332177F777A5816036D65A",
          "timestamp": "2023-09-10T11:11:51.480508253Z",
          "signature": "Et25pdAwE4N0qEoaMP9gusc6b2Hh0suw5+pYVlnqEOxBwQQaLCpqHPeGozT6cS0XRsUXdrEspDipBuXP/abBAg=="
        },
        {
          "block_id_flag": 2,
          "validator_address": "83FA417ADBD2DE24C0FD587F09109FE5F31788DA",
          "timestamp": "2023-09-10T11:11:51.510903479Z",
          "signature": "7xKNfw9Hz1eD2VQxUWaFZLG6pJcZX15MSKF32qBgR5nshXoag7p6dB194m3kCqXui5f/ZJkdBjVl/NzdH3j6Cw=="
        },
        {
          "block_id_flag": 2,
          "validator_address": "30DA2AC9B9A34BCA21B3514CBDB1A9E6DE3CEAE0",
          "timestamp": "2023-09-10T11:11:51.486101076Z",
          "signature": "XBE5v2dGdOENtzASgZnv9+Iq5x9qeg009F/t1tsmwovxxlYB3aM/SL3wYg2SH105/a2QoIf+LnHNWbBjK2VlAw=="
        },
        {
          "block_id_flag": 2,
          "validator_address": "7B8D7A34EC3EB1179F14FDDE3F10C22928775D38",
          "timestamp": "2023-09-10T11:11:51.528125793Z",
          "signature": "KjjGttiMdltymmEMe9oBAFFmCaKTVYRsYwmRz752cbqvyMzfclWqIFJh3RUoYne/EtUT4RRgfDN2geqAJP4ZCQ=="
        },
        {
          "block_id_flag": 2,
          "validator_address": "1CED30733D1625C89AB698677606D0E37B3676A9",
          "timestamp": "2023-09-10T11:11:51.616524987Z",
          "signature": "6HB268//T2M2B+3GNDeFUOYjZS6Lj9msp9eGMOQmsFcrigVeYzp6xdNC3agQXY2u6YIMVzgN8v+FnZSHv3moCQ=="
        },
        {
          "block_id_flag": 2,
          "validator_address": "05420F030B0EA20194743831CDAE841E0FDFABA2",
          "timestamp": "2023-09-10T11:11:51.559455148Z",
          "signature": "juOheG9tG4mnYtCMNZY0QfDk9GpFmV8no78Z17zS20eG4faBXjG11z2uGGxFkfqIPWpk79Cra604NxFwkx9jBQ=="
        },
        {
          "block_id_flag": 2,
          "validator_address": "2418CCDD5A1BA729C8CF82DD0D0732FFF9626D15",
          "timestamp": "2023-09-10T11:11:51.559756921Z",
          "signature": "4RAnrnGOXgZ9tpTyxsgMk+bWRLpMzOotMQfjVJXF6js7C3vXL1jyK0FRoasEkzDoBXTt2GoKdpP8X+r0F14FCA=="
        },
        {
          "block_id_flag": 2,
          "validator_address": "633706FA3A3029E68D72EC24E1B6B50E69533DD2",
          "timestamp": "2023-09-10T11:11:51.553779196Z",
          "signature": "OKwNaTvc//mtPjwV7vLikjzt+K7/zycZRmV3oKPHGtjAH5Ml7QVSJs9m7r1F7yHvVnYA4TO+mGtvV6Xbci15AA=="
        },
        {
          "block_id_flag": 2,
          "validator_address": "B901B7216B7F010BB97E44AAB7611457222CB62B",
          "timestamp": "2023-09-10T11:11:51.564632013Z",
          "signature": "rmjn/4MakUNvenMmHGz8/AACMOfX/kYu6vEPyCsljEwOZsLH+2Is2kij+Z9ZXqJudOHz+KhxCuH9oNRvRYwIDQ=="
        },
        {
          "block_id_flag": 2,
          "validator_address": "73B97484A5803BDEF3305C1D73E25516C5A6CD20",
          "timestamp": "2023-09-10T11:11:51.784492325Z",
          "signature": "HxPU2szNsvTkqzQJmA3Cn8k7qT7FMhixxpq0JkrJCEGeU1hqzH9KfqDJBJ7GcCOkxWmHaCMM7d+yizGCZY2ABw=="
        },
        {
          "block_id_flag": 2,
          "validator_address": "AE8F583288A168D56720EA6695A3AE9ABB8735CD",
          "timestamp": "2023-09-10T11:11:51.590510753Z",
          "signature": "qimZST+mvTxdXYgLQZ6yVK5ZUmpHFHbCPONB2bunVPgnaP8DHFt6nK9PSHns8JOtvDgGRKazju36hzRCASPsBg=="
        },
        {
          "block_id_flag": 2,
          "validator_address": "279ADBE5F6292E740201C1AA3E90E1B10755F33F",
          "timestamp": "2023-09-10T11:11:51.691327072Z",
          "signature": "Y7zRDzB6EkUSy2QtVa0WmyS0jUUtl0oY71uxrvBoGq1mkxrcBlRMRpfvwZkZF1H91wSjmu7iOQh1M/cwoUr6BA=="
        },
        {
          "block_id_flag": 2,
          "validator_address": "B48DB62D3F7CE8A366DE5F35E97116229DA9E0FE",
          "timestamp": "2023-09-10T11:11:51.609904327Z",
          "signature": "yeH8fdREyLkSU8r7S9VR9i1caE1/aAUB/7FZtLWQAgMr87qNpE8USLZpBOY3HQ7f5S2FOdvf72o4U3xR+f4ACg=="
        },
        {
          "block_id_flag": 2,
          "validator_address": "E715907C51B5D4BC822C076171285BBBC7330C4A",
          "timestamp": "2023-09-10T11:11:51.690572098Z",
          "signature": "j38VIBj2g0vKLNQTXZouOu2a/W4kDBW4musyE1bQgsb62EVQ+mTl3oT4WuNcmxmZNgh0ePdto34xwsrTQxD2Cg=="
        },
        {
          "block_id_flag": 3,
          "validator_address": "5B92AF91E119622313E36EAF8B268C6461156C6A",
          "timestamp": "2023-09-10T11:11:51.758123578Z",
          "signature": "v2TBGA0RWz+xLug7wL51xqY21ogPlNjCzHo5d4UJWo9bSWU6XmqjVauWwe2fYaxloaUm++qaOa+lGB2BsDJpAQ=="
        },
        {
          "block_id_flag": 2,
          "validator_address": "AB3CACE07B6C6ED42C362CDA8AEC0A435190E699",
          "timestamp": "2023-09-10T11:11:51.711147149Z",
          "signature": "eepRF8kUcFYnsZfV1KAfMzitNYapGqL9Ad5jOuHvXrRKQOpZJTSuk37kZ4oHmMbY5UPkqhF8cNyYj8Xo1C9wCQ=="
        },
        {
          "block_id_flag": 2,
          "validator_address": "4D0682A3C9B277EBFEE8EF46B6B2BAF51EDD0884",
          "timestamp": "2023-09-10T11:11:51.65980505Z",
          "signature": "AcNvb7x3uKQnthRphuOBfMD5ZckZMz7pRPVphajjaSKmCsH8pVGpUS32aDbaMWnR33fDoCQGJ62H6klv+wtEAA=="
        },
        {
          "block_id_flag": 2,
          "validator_address": "707FC53A6E0E7FCE73C2F54B4E58C9ABB97421F9",
          "timestamp": "2023-09-10T11:11:51.560316795Z",
          "signature": "aCVQDGbe4Egz7zkjA1QlOOLxAIgZgJjuu8vNGsK6do3U9Aj8OW/LZqcBbu5PG+qRjQ0i5rVoASMDuQglX9rKAA=="
        },
        {
          "block_id_flag": 2,
          "validator_address": "A9C22C9BD2A6EA10A6754D547EED96777AAD815A",
          "timestamp": "2023-09-10T11:11:51.62296154Z",
          "signature": "ikXtt/YVjKt5aG5LbPbiTSrYAg6K5EVg28+AfxYixMpldRSkWecGiQEovi4xgHjc9emuG9cW8B5zWXE/smsADQ=="
        },
        {
          "block_id_flag": 2,
          "validator_address": "7102C702289FBED97CC87943CD342D56E597D66C",
          "timestamp": "2023-09-10T11:11:51.608489777Z",
          "signature": "sbA4dv0c6SPofc9RP8B2FAkH3331eiCEEatkcuu91vzC3NWY9m4dE4kl6Wy5t8Qfa1IGY73lTgxGm3bOnx9DAQ=="
        },
        {
          "block_id_flag": 2,
          "validator_address": "727110CF1E0238DE0D15A4FC6E8F88590293D91D",
          "timestamp": "2023-09-10T11:11:51.686902029Z",
          "signature": "v/r/WK8tWl5/B3LoluFQwfnni7YibH/fC0j6YMvdcGbz7FljZCI7ELjhELKIRdAins0knTuo6f3Lr7A6gWw8Dw=="
        },
        {
          "block_id_flag": 2,
          "validator_address": "A01BDC129A5D16A071D8C39BEA0BD296CDCEFC03",
          "timestamp": "2023-09-10T11:11:51.603973903Z",
          "signature": "XF/uI2U4+db3JVDRFy7ZfXyeYYvQQRc1yKQc9F/Zb4/hymBpMqR+PJ7UTO44aD2ZZqBRUCmttmrCG+NbyGauCg=="
        },
        {
          "block_id_flag": 2,
          "validator_address": "B97904E1431DBC2CDF58670F9067EE0936C38197",
          "timestamp": "2023-09-10T11:11:51.813795221Z",
          "signature": "HHyRRES2MYYErgvzCbOhEA8AoSCeB7ppgOe2OGMRdJCnPnHl0R8q+boFY8PWysR6LcAoYw0P5PTqUYOLq7ifBg=="
        }
      ]
    }
  }
}

Offhand I don't know why you'd be getting that error, but note the error is coming out of CometBFT/Tendermint, so it's really more a question for them.
ServiceClient is just an autogenerated wrapper for a gRPC service, so if it isn't working for you, there's not a lot we can do about that on this side of things.
Are you getting that error just trying to connect, or are you making some kind of request?
The first block is usually 1, not 0, so perhaps you're requesting a block that doesn't exist?


ISSUE 555 : Expose an option to disable canonical check while adding a new schema version

#555

@joylyn I merged the changes for UI from HDF3.2 to master. Can you double check if the UI changes all are in place?

@raju-saravanan I could not build these changes in my environment. Can you confirm whether you could build this PR in your environment?
@kamalcph Can you also build/verify these changes?

@satishd: I was able to build the PR. @kamalcph and @joylyn Can you guys confirm as well?

I'm able to build this PR.

@satishd: Please confirm if you are able to build this PR, after your confirmation I will merge this PR.

@raju-saravanan I am not able to commit as the permissions seem to be revoked for me. You can merge these changes.
@vijayk Can you add admin permissions for me on this project as I am a committer on this project? thanks.

@satishd : Will merge the PR.


[suggestion] add ore processing mod priorities/ CT support for ore processing

Many mods (nuclearcraft, gregtech, and many more) usually have a mod priority list of mods to support for ore outputs when processing materials. This also includes minecraft as well. If you can provide a way to have the outputs be different than just say, thermal foundation materials, that would be nice to have in the config rather than just having to manually change all of the ore processing recipes...
EDIT: actually i dont even see CT support for the ore processing, so this would be a REALLY essential thing to have...
If you can do 1.12 as well as 15 that would be greatly appreciated

:wave: Sorry but Industrial Foregoing has ended support for version 1.12. I'm closing this issue as it will no longer be updated for that version. Thanks for playing with the mod.


webhook  calling

How to call the webhook
i have enable the webhook , and given the url (localhost:5555/auto) select the post method . when this action triggered , this service is not going to hit .
what should i do

This is a Docker thing, localhost is inside the Docker container. So assuming you have some other service running locally on your machine you can't access it via localhost you would've to add it to the Docker network or change the Docker network to use the host network.
To test and make sure everything is working, try an external service like https://api.chucknorris.io

https://stackoverflow.com/questions/24319662/from-inside-of-a-docker-container-how-do-i-connect-to-the-localhost-of-the-mach

Question answered


fix(iteration): iteration get disappear on collapsing and expanding t…

…he side panel
Fix: https://openshift.io/openshiftio/openshiftio/plan/detail/1697

@vikram-raj fabric8/fabric8-ui:SNAPSHOT-PR-2332-1 is deployed and available for testing at https://fabric8-ui-fabric8-ui-pr-2332-fabric8-planner.badger.fabric8.io


Use shader's Cargo.toml to get spirv-builder version and toolchain

We can still override the version and toolchain with CLI args. This
commit just changes the defaults.
I feel like there could be a lot of edge cases for this implementation.
So I consider it more of a first draft.
Notable changes:

Spirv renamed to SpirvCli.
New impl SpirvSource that does all the shader crate querying.
CLI args change: --spirv-builder is now split into
--spirv-builder-source and --spirv-builder-version.
--shader-crate now lives on the install subcommand, which
because it is inherited by build (where it was originally), means it
doesn't make much of a difference.
The full build test now has a teardown function making it idempotent.
Cache folder structure now has sub folders for spirv-builder-cli's
and rust-gpu repos.
spirv-crate-template is updated to Git with revision 82a0f69
because "0.9" doesn't seem to compile on Windows.

Things to consider:

Can we remove TARGET_SPECS now, because we have a copy of the
rust-gpu repo, we can get them from there instead?
What's the UX expectations for changing spirv-std versions or
overriding rust-gpu versions and toolchain? I think in most cases
spirv-builder-cli rebuilds should occur because the changes will
cause cache directory changes. But I think it'd be good to at least
manually test this.
Should the main build test be moved out into an integrations tests
folder?
I'd still like to test each spirv-builder-cli feature, ie:
spirv-builder-pre-cli and spirv-builder-0_10. We're currently only
testing spirv-builder-pre-cli.

So the CI tests have highlighted the curious case of not being able to compile a shader that exists in workspace whose root Cargo.lock has a different version from the shader's. It's curious because I don't have any idea whey spirv-builder-cli is even looking outside the shader crate that it's building?
I hadn't realised that you were manually compiling the shader-crate-template in the Github Action workflow. I had to disable that to get CI to pass on Linux and OSX. The Rust tests are actually testing the same build anyway, and they achieve that by copying shader-crate-template outside of the workspace to avoid the error I mention.
The windows error though is still a mystery, maybe it's because of parentheses in the path. I'll keep looking into it.

I've fixed everything from your review comments but the Windows build is still failing. The only clue I can see from the logs is this:
C:\Users\runneradmin\.cargo\registry\src\index.crates.io-6f17d22bba15001f\spirv-tools-sys-0.8.0\spirv-tools\source\opt\fold_spec_constant_op_and_composite_pass.cpp : fatal error C1083: Cannot open compiler generated file: '': Invalid argument
So it's failing to build spirv-tools-sys which I can't think why would have changed in this PR.
But let me answer some of your questions anyway.

At least there shouldn't be any significant network activity after the first build and the cache is warm. I wouldn't be surprise if at least some network activity happens, but like you suggest, that would have probably always been the case. I seem to remember you have to set things up with cargo vendor to have true network-less builds.
The only extra thing we're caching is the rust-gpu repo.
cargo tree runs in milliseconds. So by far the biggest difference is the clone of the rust-gpu repo.

We just need to figure out this Windows error and then I think this is g2g 🚀 .
@tombh don't hesitate to thrash against CI on this ;)

Hehe sure, thanks, I won't hesitate. I'll get my thinking cap on 🤔

I have some changes incoming, but I can't seem to push them. I'm not sure if my workflow is borked or if there's a permission error or what.

You want to push them onto this branch? I'm not sure that's a good idea, I do a lot of force pushing, so I could well overwrite any changes you push. I think a better idea is to make a PR against this PR. There's a nice feature in Github where you can change the underlying base branch for a PR, see here:

Well I figured it out!

Those are some nice changes!
Though I'd prefer they were in their own branch. It's not so easy to pull in your changes into my local branch, I have to git stash, git checkout to a shared commit etc. And I generally try to strive for linear history, so I often git push --force my commits without thinking about it. I could easily overwrite your changes. And I see that Clippy is complaining, so maybe you'll have some more commits to push, so I don't want to be pushing whilst you still might be pushing. It all gets a bit complicated.
It's easy enough to make a PR targeting another PR, and then I can merge your changes into my PR as and when they're ready, without us stepping on each other's toes ❤

FWIW jj is git-compatible and really helps with handling linear histories and juggling changes. Might be worth looking at.

Yeah jj is great, even Steve Klabnik is into it, he wrote a nice intro,

I'll open up another PR into yours, @tombh 👍

It's easy enough to make a PR targeting another PR

Is the method you're suggesting for me to fork your fork and then create a PR into your branch at your fork? Because I can't select your branch as the base for my changes in this repo.

See my additional changes above @tombh ^

Looks like currently on my branch (#28), spirv-tools-sys is failing to build on Windows.

Don't worry, you got your point across, and I agree. I was recently contributing to a project and in that project, committing to the PR branch directly was their practice and I was surprised it worked. I decided I'd give it a try. Really I just wish I could make a PR into your PR without having to fork your fork. It would be nice to keep all the discussion here instead of another related PR 🤷 .


update's nModified is incorrect in some cases

@GinGin3203 added two test cases at #546 that pass with MongoDB, but fail with FerretDB. We should fix those issues.

@GinGin3203 wanna take it?

@AlekSi yep, you can assign me 👍🏻


Rebuild image to pickup latest packages

Need to rebuild the image due to a vuln detected in a installed package
Refs:

https://github.com/stolostron/backlog/issues/22083

Signed-off-by: Gus Parvin<EMAIL_ADDRESS>

/cherry-pick release-2.5


[ADAP-887] [Feature] Support directly specifying the GCP project for python models

Is this your first time submitting a feature request?

[X] I have read the expectations for open source contributors
[X] I have searched the existing issues, and I could not find an existing issue for this feature
[X] I am requesting a straightforward extension of existing dbt-bigquery functionality, rather than a Big Idea better suited to a discussion

Describe the feature
Some customers have Dataproc clusters in GCP projects that are neither:

The GCP project where models are written to (i.e. the project / database config).
The GCP project where billing is attributed to (i.e. the execution_project config).

This means that if we have something like:

GCP Project project-analytics.

All models must are written to this project.

GCP Project project-billing.
GCP Project project-dataproc-clusters.

This is where Dataproc cluster my-dataproc-cluster is.

And we have a dbt-bigquery setup like:
# ~/.dbt/profiles.yml
default:
  target: bq
  outputs:
    bq:
      type: bigquery
      method: service-account
      project: project-analytics
      dataset: project-analytics
      execution_project: project-billing
      dataproc_region: us-central1
      dataproc_cluster_name: my-dataproc-cluster
      gcs_bucket: my-gcs-bucket
...

Then our Python model:
# models/foo.py
def model(dbt, session):
    dbt.config(submission_method="cluster")
    data = [{"id": 1}]
    return session.createDataFrame(data)

Will be submitted to the dataproc cluster my-dataproc-cluster in GCP project project-billing (which is not where the cluster actually is) due to:
https://github.com/dbt-labs/dbt-bigquery/blob/ffe2175440e263e71f122a0b707b51ba2dfeeb54/dbt/adapters/bigquery/python_submissions.py#L98-L104
Would be ideal to be able to change the GCP project via a config where the dataproc cluster actually is - perhaps:
# models/foo.py
def model(dbt, session):
    dbt.config(submission_method="cluster", dataproc_cluster_project="project-dataproc-clusters")
    data = [{"id": 1}]
    return session.createDataFrame(data)

Describe alternatives you've considered
Don't think there is any beyond changing execution_project from project-billing to project-dataproc-clusters which of course changes the billing for SQL models - which we do not want.
Who will this benefit?
Users who have dataproc clusters in projects different to the output project / execution project.
Are you interested in contributing this feature?
No response
Anything else?
No response

Thanks for explaining this so well @jeremyyeo 🏆
I'm going to mark this as help_wanted for an interested community member to pick up.

Acceptance criteria
With the following project files, the python model will run in the project-dataproc-clusters project (from dataproc_cluster_project).
# ~/.dbt/profiles.yml
default:
  target: bq
  outputs:
    bq:
      type: bigquery
      method: service-account
      dataset: project-analytics

      # Note three different project names here:
      project: project-analytics
      execution_project: project-billing
      dataproc_cluster_project: project-dataproc-clusters

      dataproc_region: us-central1
      dataproc_cluster_name: my-dataproc-cluster
      gcs_bucket: my-gcs-bucket
...

# models/foo.py
def model(dbt, session):
    dbt.config(submission_method="cluster")
    data = [{"id": 1}]
    return session.createDataFrame(data)

And if models/foo.py is modified like the following, then it will run in the project-dataproc-clusters-2 project:
# models/foo.py
def model(dbt, session):
    dbt.config(submission_method="cluster", dataproc_cluster_project="project-dataproc-clusters-2")
    data = [{"id": 1}]
    return session.createDataFrame(data)

If dataproc_cluster_project is not defined in profiles.yml or within the .py config, then it its value should default to project-billing (the execution_project).


AssertionError when using jinja2

from django.template.backends.django import Template as Template2
assert isinstance(template, Template2)

We need to remove that assert probably. There is no common base class for django and jinja2. Maybe check the class name? Seems icky.

This has become obsolete.


[Tutorials] Reduce the cluster size for the SGD + PEFT notebook

Description
Reduce the ratio of synthetic samples to lower API calls.
Reduce the cluster size for Sem Dedupe.

[X] I am familiar with the Contributing Guide.
[X] New or Existing tests cover these changes.
[X] The documentation is up to date with these changes.

@VibhuJawa @avem-nv continuing the conversation from earlier, what do you think of this? As far as I understand the algorithm, we should set the number of clusters equal to 1 for this small of a dataset (12,224 samples).

@VibhuJawa @avem-nv continuing the conversation from earlier, what do you think of this? As far as I understand the algorithm, we should set the number of clusters equal to 1 for this small of a dataset (12,224 samples). Let me know what y'all think.

I think we can reduce it to lesser number of clusters for sure.
I think the only thing to keep in mind that we are doing
O(n**2) computations for similarity matrices IIRC so maybe just move it to 10 to keep it reasonable  for folks  who might experiment with more data.  1 works too, no strong opinion.


Add valgrind to analyze target

Make failure prints more uniform

Valgrind installed by compiling from source. Do this to get a version which behaves as expected (i.e. does not print LEAK SUMMARY when no leaks detected).

Closes: #6


Modify update script to update matrix

Now that there is a matrix from #28, we should modify the update script so that the matrix is kept up-to-date.
CC @basnijholt

I am on it!
Any idea why only one image is pushed though?

I think it's because #28 didn't update the tags according to the base image, so I think the second-built image clobbered the first-built. We should fix that... :grin:

I do not understand the tagging very well.
I opened https://github.com/mamba-org/micromamba-devcontainer/pull/31 which updates the image tags correctly.

Ya, the combined workings of docker/metadata-action and docker/docker-push-action are pretty opaque.
type=sha,enable=true,prefix=git- means f"git-{short_sha}" and type=raw,value=latest means "latest", and those get referenced for the push via tags: ${{ steps.meta.outputs.tags }}.
What would you like to be the tag of the cuda image?

OK I see!
What about https://github.com/mamba-org/micromamba-devcontainer/pull/32?


Fix total number of workers

As a follow up to #104.
By tainting the master node we allow it to be used as a worker. This is how quorum is reached for the previous implementation. Therefore the minimum could be 1 master and 2 workers still.
Ideally I'd like to keep the amount of resource usage to a minimum. So should we:

Revert to the 1 master (tainted) + 2 workers by default*
Require 1 master, 3 workers, and stop tainting the master
Leave it as is effectively having 4 workers

We could also add an option to taint the master.

I think I would go for 2) which imho is the "standard" for most users.
Tainting the master should be an option but not the default, because this is no the default for k8s either.
For the story, I had to adjust number of workers because ceph would not health_ok on default setup with only 2 workers and consequently only 2 OSD.


Issues identified by Max Neal and John G: Problem with EnergyDiff

This issue describes more detail about the second part of #22.
Consider the unit test:
TEST_F(EnergyDiffTests, NernstExample) {
    RDF rdf;
    Editor editor = rdf.toEditor(
            SBMLFactory::getSBML(SBML_NERNST_POTENTIAL), false, false); // contains the nernst potential sbml model from the supplementary

    EnergyDiff physicalForce = editor.newEnergyDiff();
    physicalForce
            .about("NernstPotential", MODEL_URI) // OR LOCAL_URI? My other tests seem to indicate that this should be LOCAL?
            .addSource("Ca_ex", MODEL_URI)
            .addSink("Ca_cty", MODEL_URI)
            .hasProperty("OPB:OPB1234");
    editor.addEnergyDiff(physicalForce);

    std::string expected = "@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .\n"
                           "@prefix bqbiol: <http://biomodels.net/biology-qualifiers/> .\n"
                           "@prefix semsim: <http://bime.uw.edu/semsim/> .\n"
                           "@prefix OMEXlib: <http://omex-library.org/> .\n"
                           "@prefix local: <http://omex-library.org/NewOmex.omex/NewModel.rdf#> .\n"
                           "\n"
                           "local:EnergyDiffProperty0000\n" ---> note: this is created by the call to hasProperty. Users can override the default with whatever they link. Also, in SBML, this should be local, right?
                           "    bqbiol:isPropertyOf <http://omex-library.org/NewOmex.omex/NewModel.xml#NernstPotential> ;\n" --> Note: in sbml, this should be a parameter, right?
                           "    bqbiol:isVersionOf <https://identifiers.org/OPB:OPB1234> .\n"
                           "\n"
                           "local:SinkParticipant0000\n"
                           "    semsim:hasPhysicalEntityReference <http://omex-library.org/NewOmex.omex/NewModel.xml#Ca_cty> .\n"
                           "\n"
                           "local:SourceParticipant0000\n"
                           "    semsim:hasPhysicalEntityReference <http://omex-library.org/NewOmex.omex/NewModel.xml#Ca_ex> .\n"
                           "\n"
                           "<http://omex-library.org/NewOmex.omex/NewModel.xml#NernstPotential>\n"
                           "    semsim:hasSinkParticipant local:SinkParticipant0000 ;\n"
                           "    semsim:hasSourceParticipant local:SourceParticipant0000 .";
    ASSERT_TRUE(RDF::equals(&rdf, expected)); // This passes
}

What you have in the unit test above isn't quite right because we treat the Nernst potential voltage as the property, whereas your code below has it as having a source and a sink, and you've labeled something else as a property ("EnergyDiffProperty0000").
The simplistic view of Nernst potentials is to say that it is something that has sources and sinks, as well as a voltage. But this is inconsistent with other properties like mass, volume, flow rate or temperature. For all properties, we say that they are a property of something. For mass and volume, these are simply properties of physical entities. Voltages are much trickier -- the Nernst potential is related to three physical entities: The two pools of ions and the membrane that divides them. So that's why we create the abstract notion of a "membrane potential" and say that the Nernst potential is a property of that potential.  (This membrane potential is a local entity, with no connection to the SBML code.) Then, it's this potential that has sources and sinks, not directly the Nernst voltage. It is this membrane potential that "isVersionOf" the OPB class of energy differential.
To spell out the consequences of the above, the std::string expected is currently:
// Current expected value of the test
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix bqbiol: <http://biomodels.net/biology-qualifiers/> .
@prefix semsim: <http://bime.uw.edu/semsim/> .
@prefix OMEXlib: <http://omex-library.org/> .
@prefix local: <http://omex-library.org/NewOmex.omex/NewModel.rdf#> .

<http://omex-library.org/NewOmex.omex/NewModel.xml#NernstPotential>
    semsim:hasSinkParticipant local:SinkParticipant0000 ;
    semsim:hasSourceParticipant local:SourceParticipant0000 .

local:EnergyDiffProperty0000
    bqbiol:isPropertyOf <http://omex-library.org/NewOmex.omex/NewModel.xml#NernstPotential> ;
    bqbiol:isVersionOf <https://identifiers.org/OPB:OPB1234> .

local:SourceParticipant0000
    semsim:hasPhysicalEntityReference <http://omex-library.org/NewOmex.omex/NewModel.xml#Ca_ex> .

local:SinkParticipant0000
    semsim:hasPhysicalEntityReference <http://omex-library.org/NewOmex.omex/NewModel.xml#Ca_cty> .

while it should actually be
// Desired expected value of the test
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix bqbiol: <http://biomodels.net/biology-qualifiers/> .
@prefix semsim: <http://bime.uw.edu/semsim/> .
@prefix OMEXlib: <http://omex-library.org/> .
@prefix local: <http://omex-library.org/NewOmex.omex/NewModel.rdf#> .

<http://omex-library.org/NewOmex.omex/NewModel.xml#NernstPotential>
    Bqbiol:isPropertyOf local:MembranePot0000 ;
    bqbiol:isVersionOf <https://identifiers.org/OPB:OPB_01581> .

local:MembranePot0000
    semsim:hasSourceParticipant local:SourceParticipant0000 ;
    semsim:hasSinkParticipant local:SinkParticipant0000 .

local:SourceParticipant0000
   semsim:hasPhysicalEntityReference <http://omex-library.org/NewOmex.omex/NewModel.xml#Ca_ex> .

local:SinkParticipant0000
   semsim:hasPhysicalEntityReference <http://omex-library.org/NewOmex.omex/NewModel.xml#Ca_cyt> .

I think that the issue we have is in the use of EnergyDiff rather than the implementation. The test quoted in this thread was copied directly from the supplementary content example for EnergyDiff in sbml. This was written by somebody other than the primary developer and it seems they have fallen into an (easy-to-fall-into) trap. Before explaining, I'll this is what the test (and supplementary content example) should look like:

TEST_F(EnergyDiffTests, NernstExample) {
    RDF rdf;
    Editor editor = rdf.toEditor(
            SBMLFactory::getSBML(SBML_NERNST_POTENTIAL), false, false);

    EnergyDiff physicalForce = editor.newEnergyDiff();
    physicalForce
            .about("MembranePot0000", LOCAL_URI)
            .addSource("Ca_ex", MODEL_URI)
            .addSink("Ca_cyt", MODEL_URI)
            .hasProperty("NernstPotential", MODEL_URI, "OPB:OPB_01581");
    editor.addEnergyDiff(physicalForce);

    std::string expected = "@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .\n"
                           "@prefix bqbiol: <http://biomodels.net/biology-qualifiers/> .\n"
                           "@prefix semsim: <http://bime.uw.edu/semsim/> .\n"
                           "@prefix OMEXlib: <http://omex-library.org/> .\n"
                           "@prefix local: <http://omex-library.org/NewOmex.omex/NewModel.rdf#> .\n"
                           "\n"
                           "<http://omex-library.org/NewOmex.omex/NewModel.xml#NernstPotential>\n"
                           "    bqbiol:isPropertyOf local:MembranePot0000 ;\n"
                           "    bqbiol:isVersionOf <https://identifiers.org/OPB:OPB_01581> .\n"
                           "\n"
                           "local:MembranePot0000\n"
                           "    semsim:hasSourceParticipant local:SourceParticipant0000 ;\n"
                           "    semsim:hasSinkParticipant local:SinkParticipant0000 .\n"
                           "\n"
                           "local:SourceParticipant0000\n"
                           "   semsim:hasPhysicalEntityReference <http://omex-library.org/NewOmex.omex/NewModel.xml#Ca_ex> .\n"
                           "\n"
                           "local:SinkParticipant0000\n"
                           "   semsim:hasPhysicalEntityReference <http://omex-library.org/NewOmex.omex/NewModel.xml#Ca_cyt> .";
    ASSERT_TRUE(RDF::equals(&rdf, expected));
}

This test passes in libOmexMeta v1.2.0. There are two differences, the first is that the call to about needs to be tagged with LOCAL_URI so that the MembranePot is created as a local uri. The second is that the call to hasProperty uses the "full" overload version:
    .hasProperty("NernstPotential",                        MODEL_URI,                                  "OPB:OPB_01581");
                                ^^^                                             ^^^                                                    ^^^
That is:               about uri for the property    The uri type for the property about       The value of isVersionOf

This interface was necessary to support both sbml and cellml.
The biggest problem here is that the documentation is not clear enough, which will be the subject of another issue.

I think that the issue we have is in the use of EnergyDiff rather than the implementation. The test quoted in this thread was copied directly from the supplementary content example for EnergyDiff in sbml. This was written by somebody other than the primary developer and it seems they have fallen into an (easy-to-fall-into) trap. Before explaining, I'll this is what the test (and supplementary content example) should look like:

TEST_F(EnergyDiffTests, NernstExample) {
    RDF rdf;
    Editor editor = rdf.toEditor(
            SBMLFactory::getSBML(SBML_NERNST_POTENTIAL), false, false);

    EnergyDiff physicalForce = editor.newEnergyDiff();
    physicalForce
            .about("MembranePot0000", LOCAL_URI)
            .addSource("Ca_ex", MODEL_URI)
            .addSink("Ca_cyt", MODEL_URI)
            .hasProperty("NernstPotential", MODEL_URI, "OPB:OPB_01581");
    editor.addEnergyDiff(physicalForce);

    std::string expected = "@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .\n"
                           "@prefix bqbiol: <http://biomodels.net/biology-qualifiers/> .\n"
                           "@prefix semsim: <http://bime.uw.edu/semsim/> .\n"
                           "@prefix OMEXlib: <http://omex-library.org/> .\n"
                           "@prefix local: <http://omex-library.org/NewOmex.omex/NewModel.rdf#> .\n"
                           "\n"
                           "<http://omex-library.org/NewOmex.omex/NewModel.xml#NernstPotential>\n"
                           "    bqbiol:isPropertyOf local:MembranePot0000 ;\n"
                           "    bqbiol:isVersionOf <https://identifiers.org/OPB:OPB_01581> .\n"
                           "\n"
                           "local:MembranePot0000\n"
                           "    semsim:hasSourceParticipant local:SourceParticipant0000 ;\n"
                           "    semsim:hasSinkParticipant local:SinkParticipant0000 .\n"
                           "\n"
                           "local:SourceParticipant0000\n"
                           "   semsim:hasPhysicalEntityReference <http://omex-library.org/NewOmex.omex/NewModel.xml#Ca_ex> .\n"
                           "\n"
                           "local:SinkParticipant0000\n"
                           "   semsim:hasPhysicalEntityReference <http://omex-library.org/NewOmex.omex/NewModel.xml#Ca_cyt> .";
    ASSERT_TRUE(RDF::equals(&rdf, expected));
}

This test passes in libOmexMeta v1.2.0. There are two differences, the first is that the call to about needs to be tagged with LOCAL_URI so that the MembranePot is created as a local uri. The second is that the call to hasProperty uses the "full" overload version:
    .hasProperty("NernstPotential",                        MODEL_URI,                                  "OPB:OPB_01581");
                                ^^^                                             ^^^                                                    ^^^
That is:               about uri for the property    The uri type for the property about       The value of isVersionOf

This interface was necessary to support both sbml and cellml.
The biggest problem here is that the documentation is not clear enough, which will be the subject of another issue.

Given that this was a usage problem and not a bug I'm closing this issue. (Feel free to reopen if you feel I am mistaken).

Given that this was a usage problem and not a bug I'm closing this issue. (Feel free to reopen if you feel I am mistaken).


Cannot read properties of undefined (reading 'nonce')

In my esbuild.js file I have the following config:
    plugins: [
      sassPlugin.sassPlugin({
        filter: /\.module\.css$/,
        nonce: "window.__esbuild_nonce__",
        type: "style",
        async transform(source, resolveDir, filePath) {
          // Transform TailwindCSS
          const transformed = await postcss(
            autoprefixer,
            tailwindcss(path.resolve(__dirname, "./tailwind.config.js"))
          ).process(source, { from: filePath });

          // Run CSS modules transformer
          const result = sassPlugin.postcssModules({});
          return result(transformed.css, resolveDir);
        },
      }),
    ],

When I run this I get the following output:
NODE_ENV=development node esbuild.js
✘ [ERROR] [plugin sass-plugin] Cannot read properties of undefined (reading 'nonce')

    src/components/organisms/MiniTab/index.tsx:2:19:
      2 │ import styles from "./index.module.css";
        ╵                    ~~~~~~~~~~~~~~~~~~~~

Build failed with 1 error:
src/components/organisms/MiniTab/index.tsx:2:19: ERROR: [plugin: sass-plugin] Cannot read properties of undefined (reading 'nonce')

The only solution I have found is to replace this line:
    return {
-     contents: `${makeModule(css, 'style', this.nonce)}export default ${cssModule};`,
+     contents: `${makeModule(css, 'style', '')}export default ${cssModule};`,
      loader: 'js'
    }

My understanding is that this is undefined inside the postcssModules function.
I'm running node v18.3.0 on macOS 12.4
Please can you advise as to how I can remove my hacky solution?

I've fixed my issue.
I noticed here that the options are being bound to the transform function, so I've updated my function to bind accordingly:
        async transform(source, resolveDir, filePath) {
          // Transform Tailwind CSS
          const transformed = await postcss(
            autoprefixer,
            tailwindcss(path.resolve(__dirname, "./tailwind.config.js"))
          ).process(source, { from: filePath });

          // Run CSS modules transformer
-         const result = sassPlugin.postcssModules({});
+         const result = sassPlugin.postcssModules({}).bind(this);
          return result(transformed.css, resolveDir);
        },

Thank you @alexbilbie ... you have the right attitude! Keep up and sorry for replying so late


Overload next to not require passing () for Void types.

This should fix #171.

Codecov Report

Merging #173 into master will decrease coverage by 0.06%.
The diff coverage is 0%.

@@            Coverage Diff             @@
##           master     #173      +/-   ##
==========================================
- Coverage   66.36%   66.29%   -0.07%
==========================================
  Files          20       20
  Lines        2087     2089       +2
==========================================
  Hits         1385     1385
- Misses        702      704       +2

Impacted Files
Coverage Δ

Sources/Observer.swift
62.06% <0%> (-4.6%)
:arrow_down:

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 72e5cf7...43d4d68. Read the comment docs.


reconcile _pydantic_core.pyi against the Rust implementation

Change Summary
This patch corrects a number of mismatches between _pydantic_core.pyi and the underlying Rust implementation. For a little spot of consistency I also ran ssort on the file, to get consistent order for __init__, properties etc.
There were a few arguments TimeDeltaMode, BytesMode and ErrorMode where the .pyi did not allow None, but the underlying Rust implementation did. I've modified the Rust implementation to not accept None in these cases. I trialled two different strategies to do this, as two separate commits:

For TimeDeltaMode and BytesMode, I made the function argument the actual value, and implemented Default and FromPyObject for these types. This has the advantage of keeping the default consistent everywhere but was a bigger diff.
For ErrorMode, I just modified the function to take &str and set the default argument to be "python". This was a smaller diff but risks the default for error_mode changing elsewhere and not updating at this function call.

I think better to be consistent so I'd like the reviewer to take a look at the last two commits and express a preference. I slightly prefer the first option (implement Default and FromPyObject for the modes), however can be persuaded the other way for simplicity if preferred.
Once agreed I'll throw away one of the two commits and implement all three in the same way.
Related issue number
N/A
Checklist

[ ] Unit tests for the changes exist
[ ] Documentation reflects the changes where applicable
[ ] Pydantic tests pass with this pydantic-core (except for expected changes)
[ ] My PR is ready to review, please add a comment including the phrase "please review" to assign reviewers

Selected Reviewer: @samuelcolvin

please review

Decided to use string defaults for all three.


Detect canvas links that include dashes

This PR adds support for canvas video links with dashes in the filename.
Example song: https://open.spotify.com/track/4esxro8J1rbsalCPb0yrgC?si=82rTqJQ8TyWmxt0SQqrqqw
Associated canvas: https://canvaz.scdn.co/upload/artist/7yxi31szvlbwvKq9dYOmFI/video/606438b3-a9fe-4a88-8162-0bafd90cb2e6.cnvs.mp4

I found that there are a few other canvas URI formats. Added support & examples in 298a6f3.

Nice! Thanks for this PR!

Absolutely! Thank you for all of your work on this extension! I'm loving canvas on the desktop 😄

Good news: this is no longer needed as I've rewritten it to fully send/receive binary data from the endpoint.
Also supports the new UI / Spicetify-CLI 2.0.0.
Check it out: 19719f3076c1452208b0f73293e29b43c5d372a4

Awesome work!! I haven't tried spicetify-cli 2.0.0 yet, looks like I'll have a bit of theming to do when the new UI arrives.


[FirebaseAuth]: Unhandled Exception: type 'List<Object?>' is not a subtype of type 'PigeonUserInfo' in type cast

Is there an existing issue for this?

[x] I have searched the existing issues.

Which plugins are affected?
Auth
Which platforms are affected?
Android
Description
Signing in with google throws an exception.
Reproducing the issue
try {
      final googleAccount = await _googleSignIn?.signIn();
      final googleAuth = await googleAccount?.authentication;
      final googleCredential = GoogleAuthProvider.credential(
        accessToken: googleAuth?.accessToken,
        idToken: googleAuth?.idToken,
      );
      await FirebaseAuth.instance.signInWithCredential(googleCredential);
    } catch (error, st) {
      print(err);
      print(st);
    }

Firebase Core version
^3.3.0
Flutter Version
3.22.2
Relevant Log Output
I/flutter (11591): type 'List<Object?>' is not a subtype of type 'PigeonUserDetails?' in type cast
I/flutter (11591): #0      PigeonUserCredential.decode (package:firebase_auth_platform_interface/src/pigeon/messages.pigeon.dart:432:23)
I/flutter (11591): #1      _FirebaseAuthHostApiCodec.readValueOfType (package:firebase_auth_platform_interface/src/pigeon/messages.pigeon.dart:830:37)
I/flutter (11591): #2      StandardMessageCodec.readValue (package:flutter/src/services/message_codecs.dart:477:12)
I/flutter (11591): #3      StandardMessageCodec.readValueOfType (package:flutter/src/services/message_codecs.dart:522:23)
I/flutter (11591): #4      _FirebaseAuthHostApiCodec.readValueOfType (package:firebase_auth_platform_interface/src/pigeon/messages.pigeon.dart:840:22)
I/flutter (11591): #5      StandardMessageCodec.readValue (package:flutter/src/services/message_codecs.dart:477:12)
I/flutter (11591): #6      StandardMessageCodec.decodeMessage (package:flutter/src/services/message_codecs.dart:341:28)
I/flutter (11591): #7      BasicMessageChannel.send (package:flutter/src/services/platform_channel.dart:218:18)
I/flutter (11591): <asynchronous suspension>
I/flutter (11591): #8      FirebaseAuthHostApi.signInWithCredential (package:firebase_auth_platform_interface/src/pigeon/messages.pigeon.dart:1

Flutter dependencies

cloud_firestore 5.2.1 [cloud_firestore_platform_interface cloud_firestore_web collection firebase_core firebase_core_platform_interface flutter meta]
firebase_analytics 11.2.1 [firebase_analytics_platform_interface firebase_analytics_web firebase_core firebase_core_platform_interface flutter]
firebase_auth 5.1.4 [firebase_auth_platform_interface firebase_auth_web firebase_core firebase_core_platform_interface flutter meta]
firebase_core 3.3.0 [firebase_core_platform_interface firebase_core_web flutter meta]
firebase_crashlytics 4.0.4 [firebase_core firebase_core_platform_interface firebase_crashlytics_platform_interface flutter stack_trace]
google_sign_in 6.2.1 [flutter google_sign_in_android google_sign_in_ios google_sign_in_platform_interface google_sign_in_web]

Additional context and comments
Also reproducible with versions:

cloud_firestore 4.15.6 [cloud_firestore_platform_interface cloud_firestore_web collection firebase_core firebase_core_platform_interface flutter meta]
firebase_analytics 10.10.7 [firebase_analytics_platform_interface firebase_analytics_web firebase_core firebase_core_platform_interface flutter]
firebase_auth 4.17.7 [firebase_auth_platform_interface firebase_auth_web firebase_core firebase_core_platform_interface flutter meta]
firebase_core 2.32.0 [firebase_core_platform_interface firebase_core_web flutter meta]
firebase_crashlytics 3.5.7 [firebase_core firebase_core_platform_interface firebase_crashlytics_platform_interface flutter stack_trace]
google_sign_in 6.2.1 [flutter google_sign_in_android google_sign_in_ios google_sign_in_platform_interface google_sign_in_web]

Hi @myproblemchild,  I'm unable to reproduce this issue. Kindly provide a full sample github repo reproducing this issue.

@SelaseKay thanks for taking a look. I created a minimal project (https://github.com/myproblemchild/flutter-firebase-auth) but I can't reproduce a bug there.
At the same time, after uninstalling and installing the apk of my main app in the emulator, the bug is now gone. It might be that I haven't cleared the cache properly before (I'm still puzzled a little bit because I've done flutter clean and rebuild many times).


Generic params from impl dont have 'async_trait lifetime

I tried to produce a MRE:
#[async_trait]
pub trait MapInto<T>: Future {
    async fn map_into(self) -> T
        where Self: Sized;
}

#[async_trait]
impl<F, T> MapInto<T> for F
    where F: ?Sized,
          F: Future + Send,
          T: From<F::Output>,
{
    async fn map_into(self) -> T
        where Self: Sized,
    {
        self.await.into()
    }
}

error:

error[E0309]: the parameter type `T` may not live long enough
   --> src/future.rs:116:1
    |
116 | #[async_trait]
    | ^^^^^^^^^^^^^^
117 | impl<F, T> MapInto<T> for F
    |         - help: consider adding an explicit lifetime bound `T: 'async_trait`...
    |

A fix for me: T: 'static, in impl block. Is it a bug?

Thanks! I don't know how to fix this best, since I don't want to infer overly restrictive bounds by default -- it's always possible for the user of the macro to add extra bounds as necessary, but there isn't a good way for them to subtract bounds that aren't right. I found that inferring _: 'async_trait for every generic parameter on the impl block tends to be too restrictive.
I would recommend adding your own T: 'async_trait bound (not T: 'static) when you see a compiler error like that one.
#[async_trait]
pub trait MapInto<T>: Future {
    async fn map_into(self) -> T
    where
        Self: Sized,
        T: 'async_trait;
}

#[async_trait]
impl<F, T> MapInto<T> for F
where
    F: ?Sized + Future + Send,
    T: From<F::Output>,
{
    async fn map_into(self) -> T
    where
        Self: Sized,
        T: 'async_trait,
    {
        self.await.into()
    }
}

That bound basically means "T lives \"long enough\"". To explain the underlying lifetime logic a bit:

The caller of an async trait method gets to choose any lifetime to use as 'async_trait for that call;

We require the caller of the async trait method to guarantee that all arguments they pass outlive 'async_trait;

In return, we require that the implementer of the async trait method guarantee that the returned future outlives 'async_trait.

So for example, if the caller wants to get back a 'static future, then they must pass in arguments that are all 'static. This system reflects rustc's lifetime rules for return position impl Trait and async fn.

I would recommend adding your own T: 'async_trait bound (not T: 'static) when you see a compiler error like that one.

Then I will have to add a lot of T: 'async_trait, E: 'async_trait into my methods =)

FWIW, here is a more minimal example:
#[async_trait::async_trait]
pub trait Trait<T> {
    async fn foo() {
        ()
    }
}

Seeing as such a trivial example already fails the T: 'async_trait bound… I'd be curious in which cases the bound would not be required?

FYI: currently, it seems functions that return impl traits capture all generic type parameters in function's generics, whether they are actually used or not. (probably related to rfc1951)
For example:
pub trait Trait<T> {
    fn method<'lt>() -> Box<dyn ::core::fmt::Debug + 'lt>;
}

impl<T> Trait<T> for usize {
    fn method<'lt>() -> Box<dyn ::core::fmt::Debug + 'lt> {
        fn __method<'lt, T>() -> impl ::core::fmt::Debug + 'lt {}
        Box::new(__method::<T>())
        //~^ ERROR the parameter type `T` may not live long enough
    }
}

playground
In the current implementation of async-trait, the generated freestanding function's generics is impl's generics + method's generics, so it seems that all generic type parameters actually require (at least 'async_trait) lifetime bounds.
Also, this seems to be specific to generic type parameters of functions that return impl traits, for example, it doesn't apply to lifetime definitions of functions that return impl traits or generic type parameters of functions that return normal values.
(I wrote this comment because I wasn't sure if https://github.com/dtolnay/async-trait/issues/8#issuecomment-514812245 was written with this in mind. I'm sorry if I misread your comment.)

I'm having a similar issue, but unfortunately this isn't as easily fixable:
#[async_trait]
trait Trait {
    async fn func(&self);
}

struct Struct<R>(R);

#[async_trait]
impl<R: Deref<Target = Option<T>> + Send + Sync, T: Send + Sync> Trait for Struct<R> {
    async fn func(&self) {
        //               ^ [rustc E0309] [E] the parameter type `R2` may not live long enough
    }
}

I can't add 'async_trait to T because it doesn't exist at the item scope yet, and I don't want to have to make T: 'static. Is there there a fix for this?

@Koxiaet A workaround that I know is adding lifetime to trait: playground

I'm getting the same error, but with default impl directly in declaration:
#[async_trait]
trait Trait <T: Send>: Struct {
    async fn assoc_func<U>(n: Vec<T>) -> CustomResult<'_, Vec<U>> {
        call_async_func().await
    }
}

Produces:
error[E0309]: the parameter type `T` may not live long enough
  --> src/model/mod.rs:84:113
   |
83 |   trait Trait<T: Send>: Struct {
   |               -------- help: consider adding an explicit lifetime bound...: `T: 'async_trait +`
84 |       async fn assoc_func<U>(n: Vec<T>) -> CustomResult<'_, Vec<U>> {
   |  ___________________________________________________________________^
85 | |         call_async_func().await
86 | |     }
   | |_____^ ...so that the type `impl core::future::future::Future` will meet its required lifetime bounds

Addind 'async_trait lifetime to trait:
#[async_trait]
trait Trait <T: 'async_trait + Send>: Struct {
    async fn assoc_func<U>(n: Vec<T>) -> CustomResult<'_, Vec<U>> {
        call_async_func().await
    }
}

Results in:
error[E0261]: use of undeclared lifetime name `'async_trait`
  --> src/model/mod.rs:83:28
   |
83 | pub trait Trait<T: 'async_trait + Send>: Struct{
   |                 -  ^^^^^^^^^^^^ undeclared lifetime
   |                 |
   |                 help: consider introducing lifetime `'async_trait` here: `'async_trait,`

@dtolnay: I think this issue has been fixed by https://github.com/dtolnay/async-trait/pull/143: playground

Nice!

Sadly, I'm still getting this issue, in a more complicated case (playground link, MRE below). The provided workaround of adding 'async_trait works just fine.
It seems to be some more complex interaction of types, because removing the _output parameter, or removing the default implementation both get rid of the error.
use async_trait::async_trait;
use tokio::sync::mpsc;

#[async_trait]
trait InputStage<StageOutput>: Sized
where
    StageOutput: Send,
{
    async fn run(
        mut self,
        _output: mpsc::Sender<StageOutput>,
    )
    //where StageOutput: 'async_trait,
    {

    }
}


Converting null properties into empty objects?

Thanks for cool library, it's proving very useful so far. I have noticed that null responses are being converted into empty objects - is it intentional? For example, if my query is:
query {
  post (id: 123) {
    id
    name
  }
}

and there is no post with that ID, my graphql correctly returns:
data: {
  post: null
}

But relate injects props as {} rather than null, which is unexpected.

Got to fix that indeed, well spotted!


Prevent processors from resetting when no handlers support replay

Added checks for annotated handlers to mark "resetSupported" as false when all handlers of an annotated class disallow replay.

This one was stale for a while, but I believe it's worth adding to 4.9.

15556.884.3481
---Original---
From: "Allard @.>
Date: Wed, Oct 4, 2023 18:54 PM
To: @.>;
Cc: @.***>;
Subject: Re: [AxonFramework/AxonFramework] Prevent processors from resettingwhen no handlers support replay (PR #2769)
This one was stale for a while, but I believe it's worth adding to 4.9.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.Message ID: @.***>


How to recreate this sample.

Would it be possible to add a "How to recreate this sample" section in the README.md like some of the other repos have?

The sample is quiet old and targets AAD v1.0 and thus enhancements are limited.
I'd suggest you generate a new VS.NET MVC project and use a folder diff tool to list the additions. Hint, there aren't a lot really..

Alternatively you could have a look at https://github.com/Azure-Samples/active-directory-aspnetcore-webapp-openidconnect-v2, which explains the creation steps.


Feat : added square & diamond shape

latest PR in response to #10 (closed) one.
Snapshot :

@mohittk , there are only few formatting issues that you may want to fix: https://app.netlify.com/sites/awesomeshapes/deploys/62088a6aa604bac7f265bd6f

UI looks good to me. Looks fine in the mobile version too. In future when the website will be ready, we will improve mobile version further.

@all-contributors please add @mohittk for code,design and ideas

UI looks good to me. Looks fine in the mobile version too. In future when the website will be ready, we will improve mobile version further.

Yes! I saw it yesterday, it looked cool without any distortion.

https://github.com/all-contributors please add @mohittk for code and design

@all-contributors please add @mohittk for code and design


NegateProcessor initialisation still not right

There is still an issue with the NegateProcessor initialisation.
In mediascape this show by sometimes getting the dialog about the null reference.
It's clearer when building for Android: there you always get an error at startup.
I think the issue is with the order Awake() is called for the objects in the scenes: if the VRTInitializer one is called first everything is fine (because it loads the NegateProcessor singleton), but if the "whatever object it is that parses the input actions" one is called first we have the problem.

This issue may be related (but I'm not sure): https://forum.unity.com/threads/new-input-system-processors-not-appearing-always.911015/

Hmm. And there may also be an issue in that the NegateProcessor factory function is only defined in the editor...

It turns out the NegateProcessor wasn't involved, probably: it is now gone but the problem persists.
We should debug this on @ashutosh3308 's laptop: it shows the problem most often (2 out of 3 runs, even in the login manager).
It seems that if we disable P_Self_Login and only enable it after playback has started we don't see the problem.
The problem is most likely in the initialisation order, with some part A of the event system being initialised either before or after part B, and that order determining whether it works or fails.
We should enable full stack traces, that should show us how we get to the problem spot.
We could then look at Project Settings -> Script Execution Order and see if we can somehow influence the order.

We should also check whether the (outdated, disabled) InputSystemUIInputModule have any influence (i.e. does the problem disappear for @ashutosh3308 when we remove them).
We could also temporarily put log statements into Awake and OnEnable of the InputSystem and XRUIInputModule classes.

Putting prints in there doesn't work: the files are somehow overwritten?
But I put breakpoints in the relevant OnEnable() methods, and on my machine (where things work fine) the order is

XRUIInputModule
XRInteractionManager
InputActionManager
EventSystem
XROrigin
PlayerControllerSelf.Awake
PlayerControllerSelf.OnEnable
PlayerControllerSelf.Start

Repeating on Ashu's machine.
First finding is that the order (above) there is the same, but we do get the exception.
Added a breakpoint to XRBaseController.OnEnable().
Notice that this triggers very early (at least for some comtrollers).

It appears that there's another way to get this problem, and it is probably the main reason we're sometimes seeing this problem in Mediascape.
When we enable the exception breakpoint at the place stated above (in ApplyProcessors) the stack shows we're coming from ActionBasedContinuousMoveProvider.ReadInput(), trying to read the value of the m_LeftHandMoveAction.
The game object involved is Player/Locomotion System/Move Turn VR Controllers.

For completeness: the commit above (non-reference actions) is what causes the problem. Possibly having something to do with the way we switch scenes.


Add instructions for obtaining known-working versions of SteamVR

OSVR-Docs's Configuring/HTC-Vive currently[1] gives the date and branch number of a known-good SteamVR release, but no hints on how to obtain it.  Here is a start at that.
Known-good versions can be obtained using SteamCMD.  Installation should be straightforward.  Then:
login <YOUR-STEAM-NAME>   # and enter password, and Guard.
app_info_request 250820
app_license_request 250820
download_depot<PHONE_NUMBER>21<PHONE_NUMBER>231862464
quit

Notes: That's download_depot <appid> <depotid> <target manifestid>.  The SteamVR appid is 250820.  SteamVR's OpenVR Win32 depotid is 250821, and OpenVR Linux depotid is 25083.   The currently recommended 2016 July 5 release has a MANIFESTID in the Win32 depot of<PHONE_NUMBER>231862464, obtained from here. For linux, that would be download_depot<PHONE_NUMBER>23<PHONE_NUMBER>149741279.
I am insufficiently familiar with OSVR-Vive to know where those downloaded files should then be copied.
A last thought.  My experience of the last few months suggests that "typically the driver is only compatible with the latest stable release of SteamVR" is too optimistic.  At least on linux, driver_lighthouse.so on SteamVR stable seems to only rarely be compatible with Valve's public OpenVR openvr_driver.h.  For instance, it hasn't been this month.
Thanks for your work.
[1] https://github.com/OSVR/OSVR-Docs/blob/6582b5cc8e15e2678047169461d0d03df4f9aa01/Configuring/HTC-Vive.md

I now have a little script, who's core is
export HOME=$tmpdir
(cd $tmpdir && ./steamcmd.sh +login $username +app_license_request $appid +download_depot $appid $depotid $manifestid +quit) || exit 1

But I'm finding the downloaded files are truncated, despite steamcmd's claims of success, and the lack of errors in the logs.  Even if I Steam>bVerifyAllDownloads "1".
So this approach does not yet seem to be viable.

Thanks for looking into this. I had also tried steamcmd for some time but found it either insufficient or downloading way too much for my tastes. I personally had been using a locally modified version of https://github.com/SteamRE/DepotDownloader to manually download the client runtimes for each platform and a script based on this https://gist.github.com/rpavlik/aeeab316d1f85e2efddd64db58741b2f to grep for the "interface strings" that indicate Valve-induced breakage.
You can just change the path in the openvrpaths file (on Linux, think it's in ~/.config/openvr/) to point to where you put the corrected runtime version - OSVR-Vive parses that file, just as SteamVR's vrpathreg tool does.  If you'd be willing to update or improve the documentation in any way, that would be greatly appreciated.
(Sorry - I personally no longer have a Vive, so I haven't had as much need or motivation to work on this driver and keep it up to date with Valve's release-break cycle.  The "only compatible with latest stable release" statement replaced an older one from a time when they went a long time without breaking APIs and even steamvr betas interchangeable, to when they presumably went into public release mode in which every beta is incompatible with the latest stable because it introduces new interface versions not found in the "openvr" headers, and each stable typically has a major interface change, so a driver is only compatible with a single stable release of SteamVR. This is also around when they started obscuring/"encrypting" the older releases making it harder to downgrade - impossible using Steam directly, have to use something like steamdb or another tool to look at the history of the stable manifests)
For what it's worth, based on my DepotDownloader snapshots, it looks like the change between<PHONE_NUMBER> and the previous<PHONE_NUMBER>, at least on linux, is that IVRSettings_001 became IVRSettings_002 - I haven't checked the public headers to see if they've made that public change available as well, but that's a fairly ancilliary class. I suspect we should actually be able to support both of those at once.

PS. I believe, of course, that since steamdb and DepotDownloader use the same backend library, one could construct a tool based on DepotDownloader or the underlying SteamKit - cross-platform using Mono - to automatically go "back in time" to retrieve a designated stable and OSVR-Vive compatible version of SteamVR, but given that they've "encrypted" the older manifests, I suspect Valve would not look kindly on the community doing that. Perhaps @VRguy has a better idea for collaboration with Valve to support OSVR-Vive since they are an OSVR partner, after all - there was an OSVR-related "beta" (actually old version) of SteamVR for some time for this driver as well as its logical counterpart, SteamVR-OSVR (for using OSVR-supported devices with SteamVR apps), perhaps collaboration to make an OSVR-Vive compatible "beta" channel in SteamVR?

I had also tried steamcmd for some time but found it either insufficient or downloading way too much for my tastes.

Ah, ok.  For my own, linux-only app, I just wrote an end-user install script that downloads and runs steamcmd, to obtain an old version of the SteamVR app's "OpenVR Linux" depot.  It has the two files I needed, driver_lighthouse.so, and libaitcamlib.co.  15 MB.  Thankfully, I didn't need the 1 GB "OpenVR Content" depot.  I'd be done, except steamcmd invariably provides only truncated files, while claiming success.  I can script an untruncator, and provide the tails of the files myself, covered by US fair use.  But that's a lot of yak hair.

Ok, to recap.
Straightforward end-user installation of OSVR-Vive requires either closely tracking SteamVR OpenVR depot versions, or staying with an old known-to-work version.
It's not currently possible to closely track Steams's OpenVR stable versions, because Valve's OpenVR github itself very much does not.
Obtaining old known-good versions is currently non-trivial, because Valve removed that capability from the Steam UI.  It is not known whether this represents a policy obstacle, in addition to being a technical one.
As a technical workaround, DepotDownloader works.  On linux too?  So end users might be provided with a recipe for it, or a containerized app.
Using SteamCMD might be possible, but may be painful, and is currently buggy.
Valve has been supportive of OSVR-Vive in the past.  And might perhaps be again.
Does that sound right?  So, some possibly helpful tasks might include:

Point users at DepotDownloader.
Wait for openvr githup to again sync with SteamVR's OSVR depots, and then try updating OSVR-Vive.  Perhaps in a separate branch.  This is only a temporary fix, as the next SteamVR update, may recreate the problem.
... something else?

Hmm.  My only experience with Valve, has been in the context of VR and Linux.  So my impression is one of a notable lack of transparency and collaboration.  But I imagine this could be an atypical sample.  Is it plausible that Valve might assist with any of this?

Fyi, steamcmd is now available from linux distribution repositories.  And I wrote a node module steamvr-lighthouse-driver-download (which doesn't yet use them).

The current stable release client is the oldest client build any steamvr dependent driver, plugin or app should support.
SteamVR support recommend using steam client beta along with steamvr beta for best Vive performance and SteamVR comparability.
Seeing eighteen month old steam versions as being listed as the recommended for OSVR-Vive just screams something is way wrong here.


Scroll to last message when opening the view

General information

JSQMessagesViewController version: latest 7.3.4
iOS version: 10
Devices/Simulators: 6 plus / 5s / simulators
Reproducible in the demo project? (Yes/No):  No

What happened?
I've added  automaticallyScrollsToMostRecentMessage = true  into viewDidLoad but my collection view is not scrolling to last message (the bottom one)

Workaround: https://github.com/jessesquires/JSQMessagesViewController/issues/780#issuecomment-77236733

I do this in viewWillAppear.  Did load is called after the init.  As such, you are not overriding this value, since it is being reset after to change the value.  By putting it in viewWillAppear, you are change the value after it was reset.
Another value I have used in the past is viewDidAppear, so that you can see it scroll all the way down, but this is not very efficient.  If I recall correctly, I beleive doing it this way required more work tonforxe it to scroll down, since at this point it was already rendered.

Finally I'had to add self.scrollToBottom(animated: true) in the end of getData() method

@chlebta looks like this issue has been fixed. 👍


Rename repository

When I'm working on a new project, I find myself renaming it after I realize what it's really about.  This is a multi-step manual process:

Navigate to the project settings page
Type in the new name
Copy the new Git URL
git remote set-url origin ...

Would be great to have this as a one-liner (with a confirmation) using hub.  My proposal:
$ hub rename new-repo
Are you sure you want to rename this repository [Ny]? y
Your repository can now be found at https://github.com/USER/new-repo.

or with an alias
[alias]
  set-url = remote set-url origin
  rename-repo = "!f() { hub api --flat -XPATCH repos/{owner}/{repo} -f name=$1 | grep .ssh_url | awk '/.ssh_url/ {print $2}' | xargs git set-url; }; f"

so that you run git rename-repo <something>
P.S. thank you to @mislav and GitHub for hub api. It's amazing!

A slight modification to @gko's alias to rename the current directory to match the repo name:
[alias]
  set-url = remote set-url origin
  rename-repo = "!f() { \
          					hub api --flat -XPATCH repos/{owner}/{repo} -f name=$1 | grep .ssh_url | awk '/.ssh_url/ {print $2}' | xargs git set-url ; \
          					mv $(pwd) $(pwd)/../$1 ; \
          }; f "

A slight modification to @gko's alias to rename the current directory to match the repo name:
(note that if your prompt has the current directory in it, the change won't be reflected there unless you cd back into the new dir. Doing so in the alias does not work)
[alias]
   set-url = remote set-url origin
   rename-repo = "!f() { \
                          hub api --flat -XPATCH repos/{owner}/{repo} -f name=$1 | grep .ssh_url | awk '/.ssh_url/ {print $2}' | xargs git set-url ; \
                          mv $(pwd) $(pwd)/../$1 ; \
                       }; f "

Putting this in my .gitconfig gave me a bad config line. I removed the backslashes and put it all on one line, and it worked. Leaving this comment here for posterity's sake


'less -R' error when running 'dcos auth login' on alpine/busybox

Please answer the following questions before submitting your issue. Thanks!
What version of the DCOS CLI are you using (dcos --version)?
rev: b998adc6fbc8b598dc1a84dbb3537d9c16b67e8a
What version of DCOS are you using?
1.7EE
What operating system and version are you using?
CLI is in an alpine:3.3 docker container.
What did you do?
If possible please provide a recipe for reproducing.
Dockerfile:
[...]

# get dcos
RUN git clone --branch master --depth 1 https://github.com/mesosphere/dcos-cli.git \
  && echo DCOS CLI rev: $(git --git-dir=dcos-cli/.git rev-parse HEAD)
WORKDIR /dcos-cli
RUN make env && make packages

WORKDIR /dcos-cli/cli
RUN make env
ENV DCOS_CONFIG=/dcos/dcos.toml
ENV DCOS_PRODUCTION=false
RUN mkdir /dcos && touch $DCOS_CONFIG

WORKDIR /dcos-cli/cli/env/bin
ENV PATH=$PATH:/dcos-cli/cli/env/bin

# Set DCOS url to the contents of this file.
# This must be configured before we start touching package configs.
COPY dcos-url.txt /
RUN dcos config set core.dcos_url $(cat /dcos-url.txt)
RUN dcos config show
# Auth CLI using bootstrap EE credentials
COPY cli-login.expect /
RUN expect /cli-login.expect <username> <password>

cli-login.expect:
#!/usr/bin/env expect -f

set username [lindex $argv 0]
set password [lindex $argv 1]

if { $username == "" || $password == "" } {
  puts "Usage: expect this-script.expect <username> <password>"
  exit 1
}

spawn dcos auth login
expect "username:"
send "$username\n"
expect "password:"
send "$password\n"
expect eof

What did you expect to see?
No errors
What did you see instead?
Step 20 : RUN expect /cli-login.expect <user> <password>
 ---> Running in 4101a6729c41
spawn dcos auth login
host.amazonaws.com's username: <username>
<EMAIL_ADDRESS>password:
[core.dcos_acs_token]: set
less: unrecognized option: R
BusyBox v1.24.1 (2015-12-16 08:00:02 GMT) multi-call binary.

Usage: less [-EIMmNSh~] [FILE]...

View FILE (or stdin) one screenful at a time

	-E	Quit once the end of a file is reached
	-I	Ignore case in all searches
	-M,-m	Display status line with line numbers
		and percentage through the file
	-N	Prefix line number to each line
	-S	Truncate long lines
	-~	Suppress ~s displayed past EOF

I'm guessing the cause is 'pager_command' in emitting.py:L166

Yeah. Looks like not all less are the same. I think -R tells less to interpret tty commands. We can probably just remove that flag let the user set -R if they want to support colors.
@nickbp For now you can bypass this by setting the PAGER environment variable. Let me know if that workaround works for you.

cc @jgehrcke @alberts FYI, on a clever solution to script against DC/OS.


Correcting amplify cloudformation stack drift.

Which Category is your question related to?
Drift Detection in Runtime setting for amplify auto generated Lambda function (UserPoolClientLambda).
Stack is in:
Status
UPDATE_ROLLBACK_FAILED
Status reason
The following resource(s) failed to update: [UserPoolClientLambda].

see further:
The runtime parameter of nodejs6.10 is no longer supported for creating or updating AWS Lambda functions. We recommend you use the new runtime (nodejs12.x) while creating or updating functions. (Service: AWSLambdaInternal; Status Code: 400; Error Code: InvalidParameterValueException; Request ID: bcb35e19-d746-4ddd-8bfa-1d7b6bbb5257)

Amplify CLI Version
❯ amplify -v
4.14.1

What AWS Services are you utilizing?
amplify, cloudformation, lambda
Provide additional details e.g. code snippets
I have updated Cloudformation to set lambda runtime to nodejs12.x
The amplify deployment bucket contains the updated cloudformation.yml with the new runtime setting.
The lamda template viewed on the aws console shows the old setting (node6.10)
Running the Drift Detection I see this:

I cannot change the lambda runtime back to node6.10 on the console as it is no longer supported and therefore not an option.
How can I update the Lambda template to reflect the new runtime: nodejs12.x? Trying to do amplify auth push from the CLI produces error due to: is in UPDATE_ROLLBACK_FAILED state and can not be updated.
This is my staging env, so would like some advice on best way to proceed. I will get the same issue in prod.
I WANT TO AVOID DELETING THE STACK!

@chrisfowler You can update the Cloudformation templates located in amplify/backend directory of your project and run amplify push. You should treat these Cloudformation templates are your source of truth and would overwrite any changes you made on the AWS console.

@kaustavghosh06 I did update amplify/backend cloudformation and did amplify push (see above) but is failing due to 'UPDATE_ROLLBACK_FAILED' status of stack.
Stack update is failing as existing template to the Lambda in question is asking for a runtime that is no longer supported: node6.10.
Can I update the existing template, so the roll-back would ask for node12.x ?

Output below.
Because the rollout is failing, Cloudformation tries to rollback. Bu the Lambda function runtime is set to an unsupported node version (original deployment was over year ago). In short I am blocked to go forward, and blocked to rollback.
Where does amplify pull fetch the cloudformation from? Is this generated on the fly?
~/dev/qi-ui-admin master* 10s
❯ amplify push --force
✔ Successfully pulled backend environment staging from the cloud.

Current Environment: staging

| Category | Resource name   | Operation | Provider plugin   |
| -------- | --------------- | --------- | ----------------- |
| Auth     | cognito62efae15 | Update    | awscloudformation |
| Api      | qiAppSync       | No Change | awscloudformation |
| Hosting  | S3AndCloudFront | No Change | awscloudformation |
? Are you sure you want to continue? Yes

...
⠏ Updating resources in the cloud. This may take a few minutes...

UPDATE_COMPLETE    hostingS3AndCloudFront         AWS::CloudFormation::Stack Wed Apr 01 2020 13:35:27 GMT+0100 (British Summer Time)
UPDATE_IN_PROGRESS hostingS3AndCloudFront         AWS::CloudFormation::Stack Wed Apr 01 2020 13:35:26 GMT+0100 (British Summer Time)
UPDATE_IN_PROGRESS AuthRole                       AWS::IAM::Role             Wed Apr 01 2020 13:35:26 GMT+0100 (British Summer Time)
UPDATE_IN_PROGRESS UnauthRole                     AWS::IAM::Role             Wed Apr 01 2020 13:35:26 GMT+0100 (British Summer Time)
UPDATE_IN_PROGRESS qi-web-platform-xxxxxxxx AWS::CloudFormation::Stack Wed Apr 01 2020 13:35:22 GMT+0100 (British Summer Time) User Initiated
⠏ Updating resources in the cloud. This may take a few minutes...

UPDATE_IN_PROGRESS authcognito62efae15            AWS::CloudFormation::Stack Wed Apr 01 2020 13:35:43 GMT+0100 (British Summer Time)
CREATE_IN_PROGRESS UpdateRolesWithIDPFunctionRole AWS::IAM::Role             Wed Apr 01 2020 13:35:42 GMT+0100 (British Summer Time)
UPDATE_COMPLETE    AuthRole                       AWS::IAM::Role             Wed Apr 01 2020 13:35:41 GMT+0100 (British Summer Time)
UPDATE_COMPLETE    UnauthRole                     AWS::IAM::Role             Wed Apr 01 2020 13:35:40 GMT+0100 (British Summer Time)
⠴ Updating resources in the cloud. This may take a few minutes...

UPDATE_IN_PROGRESS qi-web-platform-xxxxxxx-authcognito62efae15-1FGX3HR4IUXCJ AWS::CloudFormation::Stack Wed Apr 01 2020 13:35:43 GMT+0100 (British Summer Time) User Initiated
⠇ Updating resources in the cloud. This may take a few minutes...

CREATE_IN_PROGRESS UpdateRolesWithIDPFunctionRole AWS::IAM::Role Wed Apr 01 2020 13:35:43 GMT+0100 (British Summer Time) Resource creation Initiated
⠴ Updating resources in the cloud. This may take a few minutes...

UPDATE_COMPLETE    UserPool AWS::Cognito::UserPool Wed Apr 01 2020 13:35:51 GMT+0100 (British Summer Time)
UPDATE_IN_PROGRESS UserPool AWS::Cognito::UserPool Wed Apr 01 2020 13:35:49 GMT+0100 (British Summer Time)
⠴ Updating resources in the cloud. This may take a few minutes...

UPDATE_COMPLETE    UserPoolClientLambda AWS::Lambda::Function Wed Apr 01 2020 13:35:57 GMT+0100 (British Summer Time)
UPDATE_IN_PROGRESS UserPoolClientLambda AWS::Lambda::Function Wed Apr 01 2020 13:35:57 GMT+0100 (British Summer Time)
⠇ Updating resources in the cloud. This may take a few minutes...

CREATE_COMPLETE UpdateRolesWithIDPFunctionRole AWS::IAM::Role Wed Apr 01 2020 13:35:59 GMT+0100 (British Summer Time)
⠦ Updating resources in the cloud. This may take a few minutes...

UPDATE_COMPLETE_CLEANUP_IN_PROGRESS qi-web-platform-xxxxxx-authcognito62efae15-1FGX3HR4IUXCJ AWS::CloudFormation::Stack Wed Apr 01 2020 13:36:09 GMT+0100 (British Summer Time)
⠹ Updating resources in the cloud. This may take a few minutes...

UPDATE_COMPLETE authcognito62efae15 AWS::CloudFormation::Stack Wed Apr 01 2020 13:36:17 GMT+0100 (British Summer Time)
⠙ Updating resources in the cloud. This may take a few minutes...

UPDATE_ROLLBACK_IN_PROGRESS qi-web-platform-xxxxxx AWS::CloudFormation::Stack Wed Apr 01 2020 13:36:21 GMT+0100 (British Summer Time) The following resource(s) failed to update: [apiqiAppSync].
CREATE_COMPLETE             UpdateRolesWithIDPFunction     AWS::Lambda::Function      Wed Apr 01 2020 13:36:20 GMT+0100 (British Summer Time)
UPDATE_FAILED               apiqiAppSync                   AWS::CloudFormation::Stack Wed Apr 01 2020 13:36:20 GMT+0100 (British Summer Time) Parameters: [CreateAPIKey] do not exist in the template
CREATE_IN_PROGRESS          UpdateRolesWithIDPFunction     AWS::Lambda::Function      Wed Apr 01 2020 13:36:19 GMT+0100 (British Summer Time) Resource creation Initiated
CREATE_IN_PROGRESS          UpdateRolesWithIDPFunction     AWS::Lambda::Function      Wed Apr 01 2020 13:36:19 GMT+0100 (British Summer Time)
UPDATE_IN_PROGRESS          apiqiAppSync                   AWS::CloudFormation::Stack Wed Apr 01 2020 13:36:19 GMT+0100 (British Summer Time)
⠹ Updating resources in the cloud. This may take a few minutes...

UPDATE_COMPLETE    hostingS3AndCloudFront AWS::CloudFormation::Stack Wed Apr 01 2020 13:36:29 GMT+0100 (British Summer Time)
UPDATE_IN_PROGRESS hostingS3AndCloudFront AWS::CloudFormation::Stack Wed Apr 01 2020 13:36:29 GMT+0100 (British Summer Time)
UPDATE_IN_PROGRESS UnauthRole             AWS::IAM::Role             Wed Apr 01 2020 13:36:28 GMT+0100 (British Summer Time)
UPDATE_IN_PROGRESS AuthRole               AWS::IAM::Role             Wed Apr 01 2020 13:36:28 GMT+0100 (British Summer Time)
⠙ Updating resources in the cloud. This may take a few minutes...

UPDATE_COMPLETE AuthRole   AWS::IAM::Role Wed Apr 01 2020 13:36:43 GMT+0100 (British Summer Time)
UPDATE_COMPLETE UnauthRole AWS::IAM::Role Wed Apr 01 2020 13:36:43 GMT+0100 (British Summer Time)
⠹ Updating resources in the cloud. This may take a few minutes...

UPDATE_IN_PROGRESS authcognito62efae15 AWS::CloudFormation::Stack Wed Apr 01 2020 13:36:44 GMT+0100 (British Summer Time)
⠙ Updating resources in the cloud. This may take a few minutes...

UPDATE_COMPLETE             UserPool                                                         AWS::Cognito::UserPool     Wed Apr 01 2020 13:36:47 GMT+0100 (British Summer Time)
UPDATE_IN_PROGRESS          UserPool                                                         AWS::Cognito::UserPool     Wed Apr 01 2020 13:36:46 GMT+0100 (British Summer Time)
UPDATE_ROLLBACK_IN_PROGRESS qi-web-platform-xxxxxx-authcognito62efae15-1FGX3HR4IUXCJ AWS::CloudFormation::Stack Wed Apr 01 2020 13:36:44 GMT+0100 (British Summer Time) User Initiated
⠙ Updating resources in the cloud. This may take a few minutes...

UPDATE_ROLLBACK_FAILED qi-web-platform-xxxxxx-authcognito62efae15-1FGX3HR4IUXCJ AWS::CloudFormation::Stack Wed Apr 01 2020 13:36:50 GMT+0100 (British Summer Time) The following resource(s) failed to update: [UserPoolClientLambda].
UPDATE_FAILED          UserPoolClientLambda                                             AWS::Lambda::Function      Wed Apr 01 2020 13:36:50 GMT+0100 (British Summer Time) The runtime parameter of nodejs6.10 is no longer supported for creating or updating AWS Lambda functions. We recommend you use the new runtime (nodejs12.x) while creating or updating functions. (Service: AWSLambdaInternal; Status Code: 400; Error Code: InvalidParameterValueException; Request ID: 21c3afbc-098f-4db6-9012-c61fdadacd6f)
UPDATE_IN_PROGRESS     UserPoolClientLambda                                             AWS::Lambda::Function      Wed Apr 01 2020 13:36:49 GMT+0100 (British Summer Time)
⠹ Updating resources in the cloud. This may take a few minutes...

UPDATE_ROLLBACK_FAILED qi-web-platform-xxxxxx AWS::CloudFormation::Stack Wed Apr 01 2020 13:36:55 GMT+0100 (British Summer Time) The following resource(s) failed to update: [authcognito62efae15, apiqiAppSync].
UPDATE_FAILED          authcognito62efae15            AWS::CloudFormation::Stack Wed Apr 01 2020 13:36:54 GMT+0100 (British Summer Time) Embedded stack arn:aws:cloudformation:eu-west-1:612133432723:stack/qi-web-platform-xxxxxx-authcognito62efae15-1FGX3HR4IUXCJ/76d29bd0-458d-11e9-ab98-0664065f2f2e was not successfully updated. Currently in UPDATE_ROLLBACK_FAILED with reason: The following resource(s) failed to update: [UserPoolClientLambda].
⠏ Updating resources in the cloud. This may take a few minutes...Error updating cloudformation stack
⠦ Updating resources in the cloud. This may take a few minutes...

Following resources failed

Resource Name: qi-web-platform-2019031312391-UserPoolClientLambda-1XS1QEQ4BHWIL (AWS::Lambda::Function)
Event Type: update
Reason: The runtime parameter of nodejs6.10 is no longer supported for creating or updating AWS Lambda functions. We recommend you use the new runtime (nodejs12.x) while creating or updating functions. (Service: AWSLambdaInternal; Status Code: 400; Error Code: InvalidParameterValueException; Request ID: 21c3afbc-098f-4db6-9012-c61fdadacd6f)
URL: https://console.aws.amazon.com/cloudformation/home?region=eu-west-1#/stacks/arn%3Aaws%3Acloudformation%3Aeu-west-1%3A612133432723%3Astack%2Fqi-web-platform-xxxxxx-authcognito62efae15-1FGX3HR4IUXCJ%2F76d29bd0-458d-11e9-ab98-0664065f2f2e/events

✖ An error occurred when pushing the resources to the cloud

Resource is not in the state stackUpdateComplete
An error occured during the push operation: Resource is not in the state stackUpdateComplete

I have managed to clear my blockage. This issue seemed to help, but cannot be clear if it was the solution: Parameters: [CreateAPIKey] do not exist in the template. I also deleted the offending Lambda and recreate separately to amplify, using the expected naming/roles/etc.
I still feel that rolling back a Lambda function to an unsupported runtime, is also an issue/bug that should be looked at...maybe.
Thank you for your time on this!


[11.x] Allow to set a name when registering a blade extension

This change allows to set a name when registering a blade extension, which can be used to override or control extensions added by third party packages.

What is the benefit / use case?

@taylorotwell If packages extending the blade compiler like https://github.com/conedevelopment/blade-filters/blob/master/src/BladeFiltersServiceProvider.php could add a name it would be easy to override the registered callable.

@artrz did you need a new review? Make sure to mark the PR as ready if you need one.

Thanks for the heads-up @driesvints

Thanks for your pull request to Laravel!
Unfortunately, I'm going to delay merging this code for now. To preserve our ability to adequately maintain the framework, we need to be very careful regarding the amount of code we include.
If applicable, please consider releasing your code as a package so that the community can still take advantage of your contributions!


Increase BOOT_PRE_POLL_SLEEP for workers in Production 5 to 25s

What is the problem that this PR is trying to fix?
Precise builds are being requeued a lot and it seems to be caused by the worker attempting to ssh into the instance too soon.
What approach did you choose and why?
This is an attempt to remediate things without adding any invasive changes so close to the holidays. I'd like to see if this improves the requeue rate in Production 5.
How can you test this?
This is the output of make plan (with the user-data removed for better visibility):
An execution plan has been generated and is shown below.
Resource actions are indicated with the following symbols:
  ~ update in-place
-/+ destroy and then create replacement

Terraform will perform the following actions:

-/+ module.gce_project_1.google_compute_firewall.deny_target_ip (new resource required)
      id:                            "deny-target-ip" => <computed> (forces new resource)
      deny.#:                        "3" => "3"
      deny.1367131964.ports.#:       "0" => "0"
      deny.1367131964.protocol:      "icmp" => "icmp"
      deny.1486604749.ports.#:       "0" => "0"
      deny.1486604749.protocol:      "udp" => "udp"
      deny.3848845357.ports.#:       "0" => "0"
      deny.3848845357.protocol:      "tcp" => "tcp"
      destination_ranges.#:          "1" => "1"
      destination_ranges.3294923498: "<IP_ADDRESS>/32" => "<IP_ADDRESS>/32"
      direction:                     "EGRESS" => "EGRESS"
      name:                          "deny-target-ip" => "deny-target-ip"
      network:                       "https://www.googleapis.com/compute/v1/projects/travis-ci-prod-5/global/networks/main" => "main"
      priority:                      "1000" => "0" (forces new resource)
      project:                       "travis-ci-prod-5" => "travis-ci-prod-5"
      self_link:                     "https://www.googleapis.com/compute/v1/projects/travis-ci-prod-5/global/firewalls/deny-target-ip" => <computed>
      source_ranges.#:               "0" => <computed>

  ~ module.gce_project_1.google_compute_instance.bastion-b
      metadata.user-data:            "#cloud-config\n# vim:filetype=yaml ...

  ~ module.gce_project_1.module.gce_worker_a.google_compute_instance.worker_org[0]
      metadata.user-data:            "#cloud-config\n# vim:filetype=yaml ...

  ~ module.gce_project_1.module.gce_worker_a.google_compute_instance.worker_org[1]
      metadata.user-data:            "#cloud-config\n# vim:filetype=yaml ...

-/+ module.gce_project_1.module.gce_worker_a.null_resource.worker_com_validation (new resource required)
      id:                            "2543483969303764883" => <computed> (forces new resource)
      triggers.%:                    "1" => "1"
      triggers.config_signature:     "c5f24072027587b30c81a94d625b9a5d13e1c1648356dc922041bb8d63ce82b0" => "b9eaf49d5ddd31793cacaab93f61bc227a53e9ff1dc7fb1f908665b9442390b3" (forces new resource)

-/+ module.gce_project_1.module.gce_worker_a.null_resource.worker_org_validation (new resource required)
      id:                            "2888779851703429759" => <computed> (forces new resource)
      triggers.%:                    "1" => "1"
      triggers.config_signature:     "36e3ea171c208a42763c60d3cd7ed3689d279af5cfebf4d5ee7cae222c3cbb19" => "8e8f06f163376465ce646649f3cf5f80fd8c30c7e8a79c70677ccd43ccdd2729" (forces new resource)

  ~ module.gce_project_1.module.gce_worker_b.google_compute_instance.worker_org[0]
      metadata.user-data:            "#cloud-config\n# vim:filetype=yaml ...

  ~ module.gce_project_1.module.gce_worker_b.google_compute_instance.worker_org[1]
      metadata.user-data:            "#cloud-config\n# vim:filetype=yaml ...

-/+ module.gce_project_1.module.gce_worker_b.null_resource.worker_com_validation (new resource required)
      id:                            "1629174679522947456" => <computed> (forces new resource)
      triggers.%:                    "1" => "1"
      triggers.config_signature:     "c5f24072027587b30c81a94d625b9a5d13e1c1648356dc922041bb8d63ce82b0" => "b9eaf49d5ddd31793cacaab93f61bc227a53e9ff1dc7fb1f908665b9442390b3" (forces new resource)

-/+ module.gce_project_1.module.gce_worker_b.null_resource.worker_org_validation (new resource required)
      id:                            "5875064014195153601" => <computed> (forces new resource)
      triggers.%:                    "1" => "1"
      triggers.config_signature:     "36e3ea171c208a42763c60d3cd7ed3689d279af5cfebf4d5ee7cae222c3cbb19" => "8e8f06f163376465ce646649f3cf5f80fd8c30c7e8a79c70677ccd43ccdd2729" (forces new resource)

  ~ module.gce_project_1.module.gce_worker_c.google_compute_instance.worker_org[0]
      metadata.user-data:            "#cloud-config\n# vim:filetype=yaml ...

  ~ module.gce_project_1.module.gce_worker_c.google_compute_instance.worker_org[1]
      metadata.user-data:            "#cloud-config\n# vim:filetype=yaml ...

-/+ module.gce_project_1.module.gce_worker_c.null_resource.worker_com_validation (new resource required)
      id:                            "2365087644011957208" => <computed> (forces new resource)
      triggers.%:                    "1" => "1"
      triggers.config_signature:     "c5f24072027587b30c81a94d625b9a5d13e1c1648356dc922041bb8d63ce82b0" => "b9eaf49d5ddd31793cacaab93f61bc227a53e9ff1dc7fb1f908665b9442390b3" (forces new resource)

-/+ module.gce_project_1.module.gce_worker_c.null_resource.worker_org_validation (new resource required)
      id:                            "9026233376377978819" => <computed> (forces new resource)
      triggers.%:                    "1" => "1"
      triggers.config_signature:     "36e3ea171c208a42763c60d3cd7ed3689d279af5cfebf4d5ee7cae222c3cbb19" => "8e8f06f163376465ce646649f3cf5f80fd8c30c7e8a79c70677ccd43ccdd2729" (forces new resource)

  ~ module.gce_project_1.module.gce_worker_f.google_compute_instance.worker_org[0]
      metadata.user-data:            "#cloud-config\n# vim:filetype=yaml ...

  ~ module.gce_project_1.module.gce_worker_f.google_compute_instance.worker_org[1]
      metadata.user-data:            "#cloud-config\n# vim:filetype=yaml ...

-/+ module.gce_project_1.module.gce_worker_f.null_resource.worker_com_validation (new resource required)
      id:                            "7841520030256671828" => <computed> (forces new resource)
      triggers.%:                    "1" => "1"
      triggers.config_signature:     "c5f24072027587b30c81a94d625b9a5d13e1c1648356dc922041bb8d63ce82b0" => "b9eaf49d5ddd31793cacaab93f61bc227a53e9ff1dc7fb1f908665b9442390b3" (forces new resource)

-/+ module.gce_project_1.module.gce_worker_f.null_resource.worker_org_validation (new resource required)
      id:                            "4455472707530178115" => <computed> (forces new resource)
      triggers.%:                    "1" => "1"
      triggers.config_signature:     "36e3ea171c208a42763c60d3cd7ed3689d279af5cfebf4d5ee7cae222c3cbb19" => "8e8f06f163376465ce646649f3cf5f80fd8c30c7e8a79c70677ccd43ccdd2729" (forces new resource)

Plan: 9 to add, 9 to change, 9 to destroy.

What feedback would you like, if any?
Does that plan make sense? I was a bit surprised by the extent of the changes, but I get the same results (with slightly different user-data, which is expected) if I run make plan on master as well.

The module.gce_project_1.google_compute_firewall.deny_target_ip change looks fishy, I think we should update that to be 0 explicitly on our end.
From: https://www.terraform.io/docs/providers/google/r/compute_firewall.html

Defaults to 1000. Firewall resources with lower priority values have higher precedence

The rest looks good!

@igorwwwwwwwwwwwwwwwwwwww it seems we already explicitly set the priority to 0 (https://github.com/travis-infrastructure/terraform-config/blob/master/modules/gce_project/main.tf#L239).
Not sure why that change wasn't applied.

In that case I'd say go for it 👍

Apply complete! Resources: 9 added, 9 changed, 9 destroyed.


Test ORC 1.7.8 RC0

Thank you. All tests passed. On pull requests and On pull request update are only valid in Apache repo.


bugfix: fix the failure of rollbacking back of the delete SQL at AT m…

[x] I have registered the PR changes.

Ⅰ. Describe what this PR did
fix the failure of rollbacking back of the delete SQL at AT mode when using SQLServer
Ⅱ. Does this pull request fix one issue?

fix #6449
Ⅲ. Why don't you add test cases (unit test/integration test)?
Ⅳ. Describe how to verify it
Ⅴ. Special notes for reviews

Thank you for your contributions to Seata. If possible, please send your Dingtalk contact information to my email, and I will invite you to join the Seata developer group.
<EMAIL_ADDRESS>


Error with docker image #7b1c26822d97 (/usr/lib/x86_64-linux-gnu/libsss_nss_idmap.so.0: file to short)

Hi
If I try to start the latest docker Image for microsoft/mssql-server-Linux:

docker run -e 'ACCEPT_EULA=Y' -e 'SA_PASSWORD=P@ssw0rd' -p 1433:1433 -v D:\DATA:/var/opt/mssql -d microsoft/mssql-server-Linux

I got following error:

/opt/mssql/bin/sqlservr: error while loading shared libraries: /usr/lib/x86_64-linux-gnu/libsss_nss_idmap.so.0: file to short

Could anybody help?
Thanks
Joerg

Hi
I could solve this issue with clear all Images from docker