fix: add beer-idev

##Fixes
resolves #1461
Checklist for profile addition

[x] Name the PR fix: add <your-username>.
[x] You've added file named your-username.json in the profiles directory.
[x] You've linked the PR to the correct issue.

Notes

Closing PR due to inactivity. Feel free to raise a new one.


[Feature] Docs: Add a guide for Delivering Remote Images

Feature Request
Is your feature request related to a problem? Please describe.
Delivering Remote Images should describe two ways to handle remote images including the fetch API via:
deliveryType="fetch"

And using auto-upload via URL mapping
How: https://www.youtube.com/watch?v=LJhsn5A0PFE

Hi, I would like to work on this issue

we'll start with the other issue and can work on other issues 1 by 1 unless someone else takes it first. thanks


upload-js-full SDK throws on import: Uncaught TypeError: Object.defineProperty called on non-object

I'm trying to use the upload-js-full SDK in a Next.js 13 application. ("next": "^13.4.2",)
I'm seeing the following error:
Uncaught TypeError: Object.defineProperty called on non-object
    at Function.defineProperty (<anonymous>)
    at __webpack_require__.r (webpack.js?ts=1686572445609:205:21)
    at eval (main.mjs:1:21)
    at<EMAIL_ADDRESS>(manage.js?ts=1686572445609:46870:1)
    at options.factory (webpack.js?ts=1686572445609:661:31)
    at __webpack_require__ (webpack.js?ts=1686572445609:37:33)
    at fn (webpack.js?ts=1686572445609:316:21)
    at eval (upload.ts:8:72)
    at ./src/utils/upload.ts (manage.js?ts=1686572445609:46689:1)
    at options.factory (webpack.js?ts=1686572445609:661:31)
    at __webpack_require__ (webpack.js?ts=1686572445609:37:33)
    at fn (webpack.js?ts=1686572445609:316:21)
    at eval (ManageListing.tsx:18:71)
    at ./src/components/pages/owners/listings/ManageListing.tsx (manage.js?ts=1686572445609:46645:1)
    at options.factory (webpack.js?ts=1686572445609:661:31)
    at __webpack_require__ (webpack.js?ts=1686572445609:37:33)
    at fn (webpack.js?ts=1686572445609:316:21)
    at eval (manage.tsx:8:105)
    at ./src/pages/owners/listings/[id]/manage.tsx (manage.js?ts=1686572445609:46678:1)
    at options.factory (webpack.js?ts=1686572445609:661:31)
    at __webpack_require__ (webpack.js?ts=1686572445609:37:33)
    at fn (webpack.js?ts=1686572445609:316:21)
    at eval (?d8e5:5:16)
    at eval (route-loader.js:230:51)

I may be wrong but it appears to be we webpack error that's happening at the point of importing the dependency. This is a complete blocker for using the SDK.
Any ideas what is causing the issue?
For reference, the minimal upload-js SDK does work as expected, however I need the full SDK as I want access to more SDK actions and want use it on both the client and server.

Thanks for the response!
Just been playing around with some fresh projects. The error I'm seeing is in a project that was initialised from the T3 stack (https://create.t3.gg/).
However, I've just set up a completely fresh Next.js 13 app, AND a fresh T3 app and it got it to work immediately with a really simple example, which is good I suppose!
This index.tsx page works with a completely empty fresh project:
import Head from "next/head";
import { Configuration, UploadManager } from "upload-js-full";

const uploadManager = new UploadManager(
  new Configuration({
    fetchApi: fetch,
    apiKey: "XXXX", // e.g. "secret_xxxxx"
  })
);

export default function Home() {
  const upload = async (file: File) => {
    await uploadManager.upload({
      accountId: "XXXX",
      data: file,
    });
  };

  const onFileChange = async (e: React.ChangeEvent<HTMLInputElement>) => {
    if (!e.target.files) return;

    const file = e.target.files[0];

    if (!file) return;

    await upload(file);
  };

  return (
    <>
      <Head>
        <title>Upload.io PoC</title>
        <meta name="description" content="Generated by create next app" />
        <meta name="viewport" content="width=device-width, initial-scale=1" />
        <link rel="icon" href="/favicon.ico" />
      </Head>
      <main>
        <input type="file" onChange={(e) => void onFileChange(e)} />
      </main>
    </>
  );
}

Therefore even if there is a problem with the upload-js-full library it seems like an edge case.
Perhaps some other dependency my project is interfering somehow. I'll do some more investigation and trial/error and report back.
Any further ideas welcome. I'll provide an example repo if I can replicate it.

Thank you for taking the time to share this: really appreciated!
Also glad you've got it working!
We're still unable to get a basic import working with Next.js 13 on node v16.19.0.
Which version of Node are you using, out of curiosity?

Aha! Problem solved for me!
I noticed a difference is that I'm using pnpm as my package manager in the project with the error. I just created a fresh repo again but this time using pnpm and voila, it causes the error!
From some more testing it seems it was an issue with using a combination of Next.js and pnpm together which has since been fixed in a patch version update to Next.js. Had a quick look through some of the changelog (there's a lot!) but not entirely sure what the actual fix was.
Runtime:
node: 18.12.1
pnpm: 8.6.0

next: 13.4.2 ❌  Fails with Uncaught TypeError: Object.defineProperty called on non-object
next: 13.4.5 ✅  Succeeds!
Sorry for the trouble 😅
Want me to push up a simple working Next.js demo for you still?

Want me to push up a simple working Next.js demo for you still?

Only if it's not too much trouble!
Next.js is obviously a very popular framework, and it's a little troubling for us that the internal demo project we created as part of resolving this ticket doesn't even compile 😅
From what we can tell, our ESM modules look valid and work fine with vanilla Node.js -- in any case -- it'd be a massive help to have your repo to test against 😄

No problem. Here's a link: https://github.com/mbrookson/upload-io-poc
Good luck! 🙌

One thing to note is my example uses the pages router rather than the new app router.
Maybe there's something different about imports with the new one?

We've since been able to reproduce this error.
It's now fixed in<EMAIL_ADDRESS>Thank you so much @mbrookson!


Separation of WPG03?

WPG03 is currently unsupported. It is unlikely that we will invest resources in its further development. This could be a good reason for creation of a separate repository for this module to reduce maintenance costs.

Done -> https://github.com/bip-team/humoto-module-wpg03-collaboration


Used Vault chart incompatible with Kubernetes 1.23+ (or even earlier versions)

Hi,
I'm getting errors when running helm sync as described here: https://jenkins-x.io/v3/admin/platforms/on-premises/vault/
Using kubernetes 1.23.4 the command fails because of chart "vault-instance" using old API "apiextensions.k8s.io/v1beta1"
This output was only possible after updating the chart repository from jx3 to jxgh ("new" github repo)
jxgh  https://jenkins-x-charts.github.io/repo

Adding repo banzaicloud-stable https://kubernetes-charts.banzaicloud.com
"banzaicloud-stable" has been added to your repositories
Adding repo jxgh https://jenkins-x-charts.github.io/repo
"jxgh" has been added to your repositories
Upgrading release=vault-operator, chart=banzaicloud-stable/vault-operator
Upgrading release=vault-instance, chart=jxgh/vault-instance
Release "vault-instance" does not exist. Installing it now.
Release "vault-operator" does not exist. Installing it now.
FAILED RELEASES:
NAME
vault-instance
vault-operator
in ./helmfile.yaml: 2 errors:
err 0: failed processing release vault-instance: command "/usr/sbin/helm" exited with non-zero status:
PATH:
/usr/sbin/helm
ARGS:
0: helm (4 bytes)
1: upgrade (7 bytes)
2: --install (9 bytes)
3: vault-instance (14 bytes)
4: jxgh/vault-instance (19 bytes)
5: --version (9 bytes)
6: 1.0.15 (6 bytes)
7: --create-namespace (18 bytes)
8: --namespace (11 bytes)
9: jx-vault (8 bytes)
10: --reset-values (14 bytes)
11: --history-max (13 bytes)
12: 10 (2 bytes)
ERROR:
exit status 1
EXIT STATUS
1
STDERR:
Error: chart "vault-instance" matching 1.0.15 not found in jxgh index. (try 'helm repo update'): no chart version found for vault-instance-1.0.15
COMBINED OUTPUT:
Release "vault-instance" does not exist. Installing it now.
Error: chart "vault-instance" matching 1.0.15 not found in jxgh index. (try 'helm repo update'): no chart version found for vault-instance-1.0.15
err 1: failed processing release vault-operator: command "/usr/sbin/helm" exited with non-zero status:
PATH:
/usr/sbin/helm
ARGS:
0: helm (4 bytes)
1: upgrade (7 bytes)
2: --install (9 bytes)
3: vault-operator (14 bytes)
4: banzaicloud-stable/vault-operator (33 bytes)
5: --version (9 bytes)
6: 1.10.0 (6 bytes)
7: --create-namespace (18 bytes)
8: --namespace (11 bytes)
9: jx-vault (8 bytes)
10: --reset-values (14 bytes)
11: --history-max (13 bytes)
12: 10 (2 bytes)
ERROR:
exit status 1
EXIT STATUS
1
STDERR:
Error: failed to install CRD crds/crd.yaml: resource mapping not found for name: "vaults.vault.banzaicloud.com" namespace: "" from "": no matches for kind "CustomResourceDefinition" in version "apiextensions.k8s.io/v1beta1"
ensure CRDs are installed first
COMBINED OUTPUT:
Release "vault-operator" does not exist. Installing it now.
Error: failed to install CRD crds/crd.yaml: resource mapping not found for name: "vaults.vault.banzaicloud.com" namespace: "" from "": no matches for kind "CustomResourceDefinition" in version "apiextensions.k8s.io/v1beta1"
ensure CRDs are installed first

With the latest version here vault-instance chart version 1.0.15 is used and oldest available in the new repo is 1.0.20. Latest would be as of 10.11.2022 1.0.27

I had the same issue, and I was able to fix it with the changes in #7


Website comparison out of date with repo

https://github.com/vlang-io/V/blob/master/website/templates/compare.html#L150

Indeed, I have two different repos, I need to merge them into one. Will do asap.

@medvednikov It would be good when you get time to put the website on github so we can monitor changes to the docs etc.

Looks like the website repo is here :-)


Improve counting of free inventory space

Given the player's inventory grid, you can check whether there are any stone/wood/leaves item slots that are not filled, and do a check if you can fill them up with items the drones are clearing.

I could, but the benefit just isn't worth it.  I'd have to look at all the item types in the inventory, and their quantities compared to stack limits, then determine what the target item could give, and calculate if there's room in the inventory.  Almost no would would care about that level of accuracy.  I consider the current inventory controls sufficient.


Client Assertion for OnBehalfOfCredential

closes #43769

API change check
APIView has identified API level changes in this PR and created following API reviews.
Azure.Identity


Updating dotnet pack to use -b instead of -t.

Updating dotnet pack to use -b instead of -t. Also fixed buffer project which had the dotnet commands directly in it and fixing the post compile script for libuv, now that we don't support native commands directly in the scripts

cc @KrzysztofCwalina

looks good


Dev update data

I added a method for updating data.
please review and let me know if there are any issues.

II try to use the method, It's ok. Let's Merge.


[Compute] az vm update: Add parameter --security-type to support VM Gen2 to Trusted Launch conversion

Related command

az vm update
Description

Add parameter --security-type for az vm update command to support VM Gen2 to Trusted Launch conversion
Close: #26387
Testing Guide

History Notes

[Component Name 1] BREAKING CHANGE: az command a: Make some customer-facing breaking change
[Component Name 2] az command b: Add some customer-facing feature

This checklist is used to make sure that common guidelines for a pull request are followed.

[x] The PR title and description has followed the guideline in Submitting Pull Requests.

[x] I adhere to the Command Guidelines.

[ ] I adhere to the Error Handling Guidelines.

Compute


Reauthentication of expired token

Currently the user is expected to recreate a client when a token is expired. However, we have enough information to be able to tell if a token will expire or not. We could either reauthenticate for the user. or give the user some sort of way of doing thing that's less destructive then completely recreating the client.
Here is where exec is happening to get an auth token. The token is being taken from ExecCredentialStatus but expiration_timestamp is ignored.  The token is then just stuffed into the headers.
The question is what should we do. Should we keep track of when the token will expire and if the user is past that timestamp when they use the client, reauthenticate on their behalf? Or do we return some sort of error and then give the user the change to reauthenticate themselves?

Good question. It's a pretty non-trivial thing to solve, and it only matters in the ~/.kube/config setup, and not in the in-cluster setup (which is generally production, but not always). However, if there's a good solution to it, it would be good to do.
IIRC kubectl will do it on the users behalf, then update the local kube config.  Come to think of it, I
think this is a duplicate of #72 and there's useful information if you follow in to #70.

I did some digging here. Go's oauth2 token exposes API calls to determine if the token has expired. client-go will check if the token needs to be refreshed or not. The client auth plugins determine the validity of the token, calling out to external APIs to refresh the token.
Here's the location in Go's oauth2 library the token's validity is calculated: https://github.com/golang/oauth2/blob/bf48bf16ab8d622ce64ec6ce98d2c98f916b6303/token.go#L133-L136
Here's GCP's client auth package for kubectl, where it determines whether kubectl needs to refresh the token or not: https://github.com/kubernetes/client-go/blob/master/plugin/pkg/client/auth/gcp/gcp.go#L214-L230
Azure's client auth package: https://github.com/kubernetes/client-go/blob/d5598eafb022853d7e550f0b801c9b16ba7f0ffe/plugin/pkg/client/auth/azure/azure.go#L205-L217
Exec client auth: https://github.com/kubernetes/client-go/blob/d5598eafb022853d7e550f0b801c9b16ba7f0ffe/plugin/pkg/client/auth/exec/exec.go#L247-L252
oidc: https://github.com/kubernetes/client-go/blob/d5598eafb022853d7e550f0b801c9b16ba7f0ffe/plugin/pkg/client/auth/oidc/oidc.go#L225-L240
The openstack plugin looks to have been converted to an exec plugin, so nothing to see there.
It's interesting to note that each client auth plugin appears to assess the validity of the token independent of each other. This appears to imply that each auth plugin's token validity can differ from provider to provider, though from looking closer at each provider, they all seem to just check the expiry date, so I'm not sure whether this was intentional or just an over-engineered solution in client-go.
In summary, your assessment that client-go will check the token's validity and perform a token refresh on the user's behalf seems correct here. Based on the existing client auth plugins, they all appear to check the validity of the token in the same manner and refresh the token upon request, so it appears that a generic token refresh based on the expiry date should work across all auth providers.
This may also be a duplicate of #84, as it discusses how tokens are refreshed using kubectl's client auth packages.

Thanks for looking into this @bacongobbler that is very helpul. This has now been fixed by @thomastaylor312 and it will be released in the next minor.


css not properly loaded

After build from this commit
https://github.com/BookStackApp/BookStack/commit/c24764018a9684fcf4418b359ddd793bb380063b
I get this css screen

Hi @stkac,
CSS and JS is only built and committed on the release branch.
Details of building the JS & CSS can be found here:
https://github.com/BookStackApp/BookStack#development--testing
Unless you're looking to specifically develop or test, you should remain on the release branch as all others are unstable and could cause you further issues.


Impossible to translate kata

I push the "+ Add New" button, get a new page, push the "Translate this kata" button and get for every try on every kata "Looks like there was a server error! (500)...".

S a m e

Me too

Works now, thanks!


MODCLUSTER-572 Normalize hostnames in MCMP messages

https://issues.jboss.org/browse/MODCLUSTER-572
https://github.com/modcluster/mod_cluster/pull/245

FQDN MUST be processed case-insensitively, but the case SHOULD be preserved, IMHO https://tools.ietf.org/html/rfc4343
e.g. NIC.CZ / nic.cz:
karm@local:~$ dig NIC.CZ
;; QUESTION SECTION:
;NIC.CZ.                IN  A
;; ANSWER SECTION:
NIC.CZ.         1800    IN  A   <IP_ADDRESS>

karm@local:~$ dig nic.cz
;; QUESTION SECTION:
;nic.cz.                IN  A
;; ANSWER SECTION:
nic.cz.         1796    IN  A   <IP_ADDRESS>

Although we might do a conscious decision to disregard it and put everything to lower case...


Fix cycles causing stack overflows

Fixes the bug where cyclical references in the definitions of models would cause stack overflows as both ModelDiff#diff and ModelDiff#convert2ElPropertys would recurse infinitely through the cycle.
This is now mitigated by passing a set containing the models that have already been "visited" in the current branch of the recursion tree. If a model has already been visited, the method will short circuit, and prevent any further traversal of the cycle.
To test that the stack overflows are fixed, I added several cyclical references to the test swagger documents:

Pet.parent references #/definitions/Pet (a self-reference cycle)
The Pet.owner references #/definitions/User, and User.favorite references #/definitions/Pet, creating a cycle between the two.

All tests as written still pass, and upon examination of the swagger, you can see that there are fields from User showing up in the changes to Pets and vice versa, eg:
What's Changed

POST /pet Add a new pet to the store
Parameter
    Add tags //add new query param demo
    Add body.newFeild //a feild demo by sayi
    Add body.category.newCatFeild
    Add body.owner.newUserFeild //a new user feild demo
    Delete body.category.name
    Delete body.owner.phone

LGTM


use node[:platform] instead of os[:family]

I got method_missing error with os function on latest itamae (version 1.2.10), so use node[:platform] and it's working.

Thank you for your contribution. I want to fix this issue.
I confirmed that Specinfra::Helper::Os#os is not available and node[:platform] is available on itamae 1.2.10. So the fix looks good.
But node[:platform] is not available on itamae 1.1.16. I added a depndency of itamae 1.2 in e182a328009c2a2f2630df25be7326f8cfb2ee9e.
Released as v0.3.0 :gem:

:+1:


Expose keyworded arguments for the trans_mat funciton

IMPORTANT: Please search among the Pull request before creating one.
Title
Give more control in the high level transition matrix function
Types of changes

[ ] Bug fix (non-breaking change which fixes an issue)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[x] New feature (non-breaking change which adds functionality)

Description
This exposes some arguments from the underlying kernels in the high level transition matrix funciton
How has this been tested?
Not at all.

@michalk8 we could make this more general and expose kwargs from both the velo kernel and the connectivity kernel, what's your opinion?

I think this is fine. Merging.

Great, thanks for looking into it


Annotation arguments completion

@Table(name="tab")

etc...

On dev branch.
Show list of annotations on complete.
Show list of annotation's fields.


CARDS-1319: The generate_compose_yaml.py script should configure a bind-mount from the cardsinitial container to the local SLING directory

This PR bind-mounts /opt/cards/sling in the CARDS Docker container to compose-cluster/SLING on the host so that configuration settings (such as installed runModes or LDAP settings) survive restarts of the Docker Compose environment.
To test:

Build this branch including the CARDS Docker image (mvn clean install)
cd compose-cluster
python3 generate_compose_yaml.py --oak_filesystem
docker-compose build
docker-compose up -d
Visit http://localhost:8080/ and create some Subjects.
docker-compose down
docker-compose rm
docker volume prune -f
docker-compose up -d
Visit http://localhost:8080/. The previously created Subjects should be present.
docker-compose down
docker-compose rm
docker volume prune -f
./cleanup.sh
python3 generate_compose_yaml.py --oak_filesystem
docker-compose build
docker-compose up -d
Visit http://localhost:8080/. The previously created Subjects should be gone.

This doesn't work for me, the volume doesn't appear to be mounted at all.

@sdumitriu What does the generated docker-compose.yml file look like? When this is running, if you run ls -al SLING, what do you see?

Huh, this is weird. I left the containers running over the weekend, and today when I tried to build a different branch, it complained about many files with missing licenses. Turns out the SLING directory is now showing the proper contents. Is there some kind of delay in propagating the contents to the disk?
Also, the files have root as the owner, so running the cleanup script fails because the current user cannot rm files owned by root.
I'll run some more tests to figure out what the mount status is.

Is there some kind of delay in propagating the contents to the disk?

There shouldn't be any delay - all writes from within the container should immediately be directed to the host file system under this configuration.

Also, the files have root as the owner, so running the cleanup script fails because the current user cannot rm files owned by root.

On this CARDS-1319 branch, the cleanup.sh script deals with this issue by running a Docker container which volume mounts the SLING directory, empties its contents as root, and then, after the container exits, removes the now empty SLING directory.


Fix punishment messages.

http://prntscr.com/69icmh
http://gyazo.com/e2d9b7534dbd6e2456dbd691a36844bb
http://gyazo.com/c13aa7292748a8a2165840857f3159ee

just a heads up, its conventions to put commit messages in the past tense fixed should be fix

@CaptainElliott I already changed the fixed to fix :p

@felipufeliu the correct naming would be "Fix punishment messages"

@felipufeliu Can you make this all one commit instead of four?

@twizmwazin For that, I'd have to close this one and create a new one?

@felipufeliu That works


[FLINK-25575] Add Sink V2 operators and translation

What is the purpose of the change
This PR allows executing Sink V2 and migrates the internal operator representation of Sink V1 to also use the Sink V2 operators. So basically every Sink V1 now runs internally on the Sink V2 infrastructure. Only the GlobalCommitter is currently still missing but it is tracked as a followup in https://issues.apache.org/jira/browse/FLINK-25726.
Brief change log

d45e3a669eece2fc287d454ed4d69a5a34c9dff9 This adds the internal structure send and book keep the Committable Messages it ensures that the operators working with CommittableMessages can ensure exactly-once processing
029d72ebef1e5df84313ea9c23e86ee0ccaecda7 small change to expose the held transformations of the stream environment. It is mainly used later by the SinkTransformationTranslator to ingest newly added transformations to the StreamGraphGenerator
90556071ebceb2a01768bae0db671d2a808f8e23 Batch/Blocking exchanges are now changed by the framework accordingly in Streaming Mode. They only have an effect in Batch Mode.
fa0eaa1541ce6d05fe8460c060c45cb0f6bb196d Adds a simulation adapter to convert Sink V1 to Sink V2.
f799eeea34b4d3c5691cc4b77f5be103ef1c065c Implements the operator logic and adapts the SinkTransformationTranslation. Sorry for that commit it is very huge.

Verifying this change
Added multiple new tests for the new operators and for the adapter simulation. In general, all Sink IT cases also verify that the Sink V2 works.
Does this pull request potentially affect one of the following parts:

Dependencies (does it add or upgrade a dependency): (yes / no)
The public API, i.e., is any changed class annotated with @Public(Evolving): (yes / no)
The serializers: (yes / no / don't know)
The runtime per-record code paths (performance sensitive): (yes / no / don't know)
Anything that affects deployment or recovery: JobManager (and its components), Checkpointing, Kubernetes/Yarn, ZooKeeper: (yes / no / don't know)
The S3 file system connector: (yes / no / don't know)

Documentation

Does this pull request introduce a new feature? (yes / no)
If yes, how is the feature documented? (not applicable / docs / JavaDocs / not documented)

@flinkbot run azure

thanks for your first review @JingGe I have addressed all your comments.

@gaoyunhaii thanks for your review.

I have one major concern regarding currently we might add the expanded transformations to the original environment. This seems to might cause problems if users call execute multiple times with the same env like
DataStream a = ...
DataStream b = ...
b.addSink(new xx());

// The following would first clear all the current
// transformations, but when translating the sink,
// it would add the expanded transformations here.
env.execute()

b.map(...);
// Then here it would execute a graph also with
// a -> some sink transformations
env.execute()

Is it possible we use a separate env for the sink translation ? We could wrap the input transformation with a DataStream in the new environment, and at last we get all the transformations and transform them. We could also disable some methods inside adding topology, like switch runtime mode or configure slot resources.

Maybe I overlooked something but I thought after every StreamExecutionEnvironment#execute the transformations are cleared. [1][2][3]
Regarding your failover region comment https://github.com/apache/flink/pull/18428#discussion_r794246463 (for some reason I cannot answer your comment in the UI...) I assumed that the Batch exchange will never have an effect in streaming mode and therefore we could handle them equally. If that is not the case I also tend to do your suggestion.
[1] https://github.com/apache/flink/blob/1704b1336bcbcdd42405f5e6e3e09c0176925210/flink-streaming-java/src/main/java/org/apache/flink/streaming/api/environment/StreamExecutionEnvironment.java#L2137
[2] https://github.com/apache/flink/blob/1704b1336bcbcdd42405f5e6e3e09c0176925210/flink-streaming-java/src/main/java/org/apache/flink/streaming/api/environment/StreamExecutionEnvironment.java#L2120
[3] https://github.com/apache/flink/blob/1704b1336bcbcdd42405f5e6e3e09c0176925210/flink-streaming-java/src/main/java/org/apache/flink/streaming/api/environment/StreamExecutionEnvironment.java#L1950

@flinkbot run azure

Very thanks @fapaul for the update and explanation!
For the execute method, sorry I has some misunderstandings initially that the clear happens before compile happens, but it should indeed be happen after the generate() is called. However, there seems still cases that the transformation is not cleared, like users call StreamExecutionEnvironment#getExecutionPlan() ?
For the Batch exchange, I think perhaps with branches (namely pass the runtime mode to SinkExpander and avoid create the failover region for streaming mode), we could avoid creating the batch exchange in advance for streaming mode, thus we won't need to rely on the behavior of the blocking edge under streaming mode~?

For the execute method, sorry I has some misunderstandings initially that the clear happens before compile happens, but it should indeed be happen after the generate() is called. However, there seems still cases that the transformation is not cleared, like users call StreamExecutionEnvironment#getExecutionPlan() ?

Afaict getExecutionPlan is only used within tests and it feels to me like it is some part of Flink's legacy and is not used anymore. I will double-check that.

For the Batch exchange, I think perhaps with branches (namely pass the runtime mode to SinkExpander and avoid create the failover region for streaming mode), we could avoid creating the batch exchange in advance for streaming mode, thus we won't need to rely on the behavior of the blocking edge under streaming mode~?

Your suggestion is definitely possible but it does not work for exchanges in the sink topology provided by the user. In this case, I would need to move the current logic from PartitionTransformationTranslator to SinkTransformationTranslator. Perhaps it is a more general issue and the fix should reside in PartitionTransformationTranslator rather than only in the sink translation.
Is there a downside when adding it to the PartitionTransformationTranslator?

@gaoyunhaii Thanks for all your help 🙏  From my perspective the last blocking feature about the parallelism is fixed and in regards to the approaching release of Flink 1.15 do you think we can settle with a solution for the internals or maybe open a ticket to fix it after the feature freeze?
Currently, this PR blocks the migration of the existing sinks inside of Flink that would be great to get it done in 1.15 as well.

Hi Fabian @fapaul ~ Very thanks for the update! As a whole I'm also agree with that we could move some issues to separate PRs to unblock the following tasks, especially those issues only related to the internal implementation.
Currently some main remaining issues from my side are as follows:
1. About setParallelism:
I think the current solution to the setParallelism issue is creative, but since it affects the result of Transformation#getParallelism, I'm a bit concern on if we have enumerate all the cases. Currently there are two possible issues from my side:

The semantics of DataStream#getParallelism is changed: previously it would always not return -1. This might be fixed by return the env's default if the transformation's parallelism is -1.
TableOperatorWrapperGenerator#calcParallelismAndResource might have issues if it deals with both transformations with default parallelism and configured parallelism. Sorry I do not see an easy solution to solve this issue.

I tried to see if we could first workaround this issue, but sorry I still not be able to find solutions.
2. About the repeat transformation
For the repeat transformation problem, I'm a bit hesitate that why we not remove the newly added transformations instead of the SinkTransformation? For example, it is feasible for users to first call getExecutionPlan() and then continue to change the properties of the SinkTransformation...
3. About the commit protocol
Currently I'm a bit concern if we should keep there are only one summary message for each (checkpoint, subtask) pair, or we allow multiple messages but they must have the save total count. The problem here is that if we allow update the total count, the following operators would not have a method to know if it has received all the committables for one checkpoint.
Is it possible for now we first throws exception if the CommitOperator received the repeat summary message, but keeps the current implementation that it is still possible to emit multiple summary message for a single checkpoint? This poses stricter requirements for pre-committer toplogy and post-committer topology, thus it would not cause compatibility problem even we change the behavior afterwards.
Also I have tried to think whether unaligned checkpoint + rescaling might cause problems, but currently I do not find issues.
4. About the PartitionTransformation (Optional)

Your suggestion is definitely possible but it does not work for exchanges in the sink topology provided by the user. In this case, I would need to move the current logic from PartitionTransformationTranslator to SinkTransformationTranslator. Perhaps  it is a more general issue and the fix should reside in PartitionTransformationTranslator rather than only in the sink translation.
Is there a downside when adding it to the PartitionTransformationTranslator?

I think changing the partition type on-the-fly might cover the possible issues on the callers. I think PartitionTransformationTranslator could check and throw exception for impossible cases, but he should not modify it directly. The callers should ensure to avoid the impossible cases. This issue might be postponed since it only related to the implementation for now.

Hi Fabian @fapaul ~ Very thanks for the update! As a whole I'm also agree with that we could move some issues to separate PRs to unblock the following tasks, especially those issues only related to the internal implementation.
Currently some main remaining issues from my side are as follows:
1. About setParallelism:
I think the current solution to the setParallelism issue is creative, but since it affects the result of Transformation#getParallelism, I'm a bit concern on if we have enumerate all the cases. Currently there are two possible issues from my side:

The semantics of DataStream#getParallelism is changed: previously it would always not return -1. This might be fixed by return the env's default if the transformation's parallelism is -1.
TableOperatorWrapperGenerator#calcParallelismAndResource might have issues if it deals with both transformations with default parallelism and configured parallelism. Sorry I do not see an easy solution to solve this issue.

I am not really familiar with this part of the code base but so far I did not see any failing tests regarding the TableOperatorWrapperGenerator can you elaborate a bit more why the current solution may cause problems.

I tried to see if we could first workaround this issue, but sorry I still not be able to find solutions.
2. About the repeat transformation
For the repeat transformation problem, I'm a bit hesitate that why we not remove the newly added transformations instead of the SinkTransformation? For example, it is feasible for users to first call getExecutionPlan() and then continue to change the properties of the SinkTransformation...

Good point I take a look at this tomorrow.

3. About the commit protocol
Currently I'm a bit concern if we should keep there are only one summary message for each (checkpoint, subtask) pair, or we allow multiple messages but they must have the save total count. The problem here is that if we allow update the total count, the following operators would not have a method to know if it has received all the committables for one checkpoint.
Is it possible for now we first throws exception if the CommitOperator received the repeat summary message, but keeps the current implementation that it is still possible to emit multiple summary message for a single checkpoint? This poses stricter requirements for pre-committer toplogy and post-committer topology, thus it would not cause compatibility problem even we change the behavior afterwards.
Also I have tried to think whether unaligned checkpoint + rescaling might cause problems, but currently I do not find issues.

Afaict the motivation to update the commit summary is exactly for unaligned checkpointing. In case the checkpoint barrier overtakes the records we only emit an incomplete summary and later need to emit a new summary with the updated amount of seen records.
In general, I am also open to restricting it in the first version and figuring out the unaligned checkpoint use cases later. WDYT?

4. About the PartitionTransformation (Optional)

Your suggestion is definitely possible but it does not work for exchanges in the sink topology provided by the user. In this case, I would need to move the current logic from PartitionTransformationTranslator to SinkTransformationTranslator. Perhaps  it is a more general issue and the fix should reside in PartitionTransformationTranslator rather than only in the sink translation.
Is there a downside when adding it to the PartitionTransformationTranslator?

I think changing the partition type on-the-fly might cover the possible issues on the callers. I think PartitionTransformationTranslator could check and throw exception for impossible cases, but he should not modify it directly. The callers should ensure to avoid the impossible cases. This issue might be postponed since it only related to the implementation for now.

I think at some point we have to modify the partition transformation. Users might use a partition transformation in their custom sink topologies and they want it to work for batch and streaming mode. So it would be great to allow blocking exchanges in batch and default in streaming mode.
Throwing an exception would mean to either support batch or stream. Overall, I agree we can revisit this topic after this PR.

Hi Fabian~

I am not really familiar with this part of the code base but so far I did not see any failing tests regarding the TableOperatorWrapperGenerator can you elaborate a bit more why the current solution may cause problems.

Sorry I'm also not expert in table / sql , but from the current implementation of TableOperatorWrapperGenerator, it tries to merge multiple transformations into one MultipleInputTransformation, and the parallelism of this one is set with the maximum of all the merged transformations. Previously the transformation might returns env.defaultParallelism in this step, but now it might return -1, suppose we have multiple parallelisms [200, env.default, env.default] and env.default = 300, previously the result would be 300 while now the result becomes 200.

Afaict the motivation to update the commit summary is exactly for unaligned checkpointing. In case the checkpoint barrier overtakes the records we only emit an incomplete summary and later need to emit a new summary with the updated amount of seen records.
In general, I am also open to restricting it in the first version and figuring out the unaligned checkpoint use cases later. WDYT?

I think with unaligned checkpointing we should still be able to keep one summary for each checkpoint: each operator could only emit the summary after checkpoint complete notified & received all the summary from each input subtask? If this is feasible we could force the current implementation of pre-commit topology to follow this pattern, but not provide the same promise (only one summary to the same checkpont) to the post-commit topology, then we would not have compatibility no matter which pattern we want in the future~

For the parallelism issue, is it possible that

Before call pre-committer, first modify the default parallelism of env to -1
After the call finished, change the default parallelism back.

Then we could know if the parallelism is set and we do not need to change the current behavior of the Transformations ?

@gaoyunhaii thanks again for the fruitful discussion. I addressed your concerns

Only handling the parallelism overwrite in the SinkTransformationTranslator and deleted the change to the Transformation
Delete the added transformations from the environment after the expansion is finished. It allows to run getExecutionPlan and execute together and allows further configurations to the sink transformation that still apply to the subtransformations.
For now I disabled the summary updates https://issues.apache.org/jira/browse/FLINK-25920
I left it untouched for now since it also requires followup that is not really related to the Sink

@flinkbot run azure


Vulkan OpImageRead with (Dim = SubpassData) and Coordinate

In Vulkan documentation, I found this.

Let's assume that we are trying to use Vulkan Subpasses to prevent data flushing back into main memory from on-chip memory(TBDR architecture in mobile) when we use GBuffer to do Deferred Rendering(two pass: GBuffer pass, Lighting pass).
Does that mean we can access Gbuffer textures with other pixel coordinates?(typically we can just fetch exactly the same position pixel value.)
If so, can other mobile API(metal/openGLES) do anything same?

In the actual Vulkan standard it says this:

The (u,v) coordinates used for a SubpassData must be the  of a constant vector (0,0), or if a layer coordinate is used, must be a vector that was formed with constant 0 for the u and v components

So no. And no, you can't do this with Metal framebuffer fetch or OpenGL ES framebuffer fetch, either.


autoValue not working when you validate against mongodb collection fields

I am trying to set a value using autoValue based on already stored values I am using meteor <IP_ADDRESS>
This used to work in meteor <IP_ADDRESS>
here is my code:

id: {
type: String,
label: "ID",
autoValue: function() {
var isFirstTime = this.field("profile.isFirstTime").value;
var isApproved = this.field("profile.changesApproved").value;
var value = this.field("profile.unapproved_id").value;
var userId = this.userId;
var user = Meteor.users.findOne({_id: userId});
if (user && user.profile && user.profile.id)
{
return user.profile.id;
}
}
}

I expect value of user.profile.id to be returned since user.profile.id has a value in the users collection but I get a value that is passed from input field. How do I get simple-schema to notice collection values as it used to on meteor <IP_ADDRESS>

Is this still something you need help with? Did you check whether this.userId is set? Can't debug this further unless you post the actual insert/update call you're making.


Automatic Social Account Merging

Is your feature request related to a problem? Please describe.
Automatic Social Account Merging does not occur by default, https://github.com/aws-amplify/amplify-cli/issues/4208 is the original report, but the author closed it after finding their own solution.
Describe the solution you'd like
Automatically merge social accounts based on one of two criteria:

They both define the same email address in their social account metadata.( https://github.com/aws-amplify/amplify-cli/issues/4208 )
Simultaneous Logins. (This was typically called something similar to "Social account linking" in most of the libraries and tools I've used.)

Describe alternatives you've considered
I could build this myself with a bunch of lambdas and other stuff.
Additional context
This sort of functionality is the default in the majority of authentication services I have used. It was genuinely shocking to discover this was not the case while I was searching through the repo's GithHub issues for a different problem and came across #4208. While I'm sure this is primarily a case of terrible default behaviour in the underlying Cognito service, there is a workaround, and from what I can tell, Amplify is trying to be a "we do the boilerplate stuff for you" type of tool, so handling this kind of workaround/boilerplate feels like something Amplify should be doing.

Thanks for the feature request @techdragon we will investigate merging social accounts by default

Any update on this, as we are have deployed our app and currently, this is an issue for us and now we are stuck at login with apple issue. we do have a website so this feature is mandatory because the user logged in with apple cannot use that in web or android, so the user should be able to login using the given email without any issue.

This seems like such a basic problem that I was also kind of shocked to discover it's not supported by default. There are a bunch of other issues and comments on blog posts asking about this as well.
Apparently the workaround is to use AdminLinkProviderForUser in a pre signup trigger to link to an existing user, but it definitely feels like something Amplify should be handling. As it stands, the same person can sign up with email or an identity provider, forget how they signed up, then sign in with a different identity provider and a new account will be created for them.

How to verify an account with many social networks?
Then start a session with the different social networks?
Here is an example with the Badoo Social Network.

Any update on this issue?

The way I'm currently handling this is:
In the PreSignup hook, if event.triggerSource is PreSignUp_ExternalProvider, I look for an existing user with email event.request.userAttributes.email using listUsers. Then:

If there's an existing user, call adminLinkProviderForUser and throw an error LINKED_EXTERNAL_USER: ${providerName}. In the frontend I catch this error and reinitiate the OAuth flow, which will log the user in. Normally the end user won't even realize, unless they're logging in with Google and they're signed in to multiple Google accounts on that browser. In that case they'll see the account selector twice, but this will only happen the first time they try to sign in with Google. I haven't been able to work around this.
If there's no existing user, I create a native user first and then link it with adminLinkProviderForUser. I do this because otherwise there's no way to link an existing user created with an external provider to a new native (email&password) user. So if the user decided to set a password for their account in the future they wouldn't be able to do that. I do this using adminCreateUser with a random temporary password and MessageAction: 'SUPRESS'. After the user is created you need to call adminSetUserPassword with Permanent: true to change the user state from FORCE_CHANGE_PASSWORD to CONFIRMED.  It is extremely helpful. I test it and work well. For others who are interested, below is a sample code of mine used for pre sign up lambda based on @ianmartorell's implementation
const aws = require('aws-sdk');
const { v4: uuidv4 } = require('uuid');

exports.handler = async (event, context, callback) => {
        //  ... skip other codes

	// If trigger source is external provider
	if (event.triggerSource === 'PreSignUp_ExternalProvider') {
		const cognitoProvider = new aws.CognitoIdentityServiceProvider({
			apiVersion: '2016-04-18',
		});

		try {
			// Get user based on email
			const listUserParams = {
				UserPoolId: event.userPoolId,
				AttributesToGet: null, //null returns all attributes
				Filter: `email = \"${event.request.userAttributes.email}\"`,
				Limit: 1,
			};
			const listUsersRes = await cognitoProvider
				.listUsers(listUserParams)
				.promise();

			let destinationAttributeValue;
			// If user not found, create user
			if (listUsersRes.Users.length === 0) {
				console.log('User not found');
				const {
					email = '',
					given_name = '',
					family_name = '',
					picture = '',
					phone_number = '',
				} = event.request.userAttributes;
				const newPassword = uuidv4(); // or use your own implementation
				const newUserParams = {
					UserPoolId: event.userPoolId,
					Username: email || phone_number,
					MessageAction: 'SUPPRESS',
					TemporaryPassword: newPassword,
					UserAttributes: [
						{
							Name: 'email',
							Value: email,
						},
						{
							Name: 'email_verified',
							Value: String(!!email), //auto verify email if provided
						},
						{
							Name: 'given_name',
							Value: given_name,
						},
						{
							Name: 'family_name',
							Value: family_name,
						},
						{
							Name: 'phone_number',
							Value: phone_number,
						},
						{
							Name: 'phone_number_verified',
							Value: String(!!phone_number),
						},
					],
				};

				const newUser = await cognitoProvider
					.adminCreateUser(newUserParams)
					.promise();

				// Confirm new user
				const setPasswordParams = {
					Password: newPassword,
					UserPoolId: event.userPoolId,
					Username: newUser.User.Username,
					Permanent: true,
				};
				await cognitoProvider.adminSetUserPassword(setPasswordParams).promise();

				destinationAttributeValue = newUser.User.Username;
			}
			// If user found, simply set username
			else {
				console.log('User found');
				destinationAttributeValue = listUsersRes.Users[0].Username;
			}

			// Link User
			console.log('Link user');
			let [sourceProviderName, sourceAttributeValue] = event.userName.split(
				'_'
			);
			sourceProviderName =
				sourceProviderName[0].toUpperCase() + sourceProviderName.slice(1);
			const adminLinkParams = {
				DestinationUser: {
					ProviderAttributeValue: destinationAttributeValue,
					ProviderName: 'Cognito',
				},
				SourceUser: {
					ProviderAttributeName: 'Cognito_Subject',
					ProviderAttributeValue: sourceAttributeValue,
					ProviderName: sourceProviderName,
				},
				UserPoolId: event.userPoolId,
			};
			await cognitoProvider.adminLinkProviderForUser(adminLinkParams).promise();

			// Finish linking, throw error to frontent
			callback(new Error(`LINKED_EXTERNAL_USER_${sourceProviderName}`), event);
		} catch (error) {
			callback(error, event);
		}
	}

	callback(null, event);
};

Also make sure to add permission to your pre sign up lambda for ListUsers and other Admins call
    "lambdaexecutionpolicy": {
      ...
      "Properties": {
        ...
        "PolicyDocument": {
          "Version": "2012-10-17",
          "Statement": [
            {
              ...
            },
            {
              "Effect": "Allow",
              "Action": [
                "cognito-idp:ListUsers",
                "cognito-idp:AdminLinkProviderForUser",
                "cognito-idp:AdminCreateUser",
                "cognito-idp:AdminSetUserPassword"
              ],
              "Resource": {
                "Fn::Sub": [
                  "arn:aws:cognito-idp:${region}:${account}:*",
                  {
                    "region": {
                      "Ref": "AWS::Region"
                    },
                    "account": {
                      "Ref": "AWS::AccountId"
                    }
                  }
                ]
              }
            }

@ianmartorell One of the problem I run into is that calling Auth.federatedSignIn overwrites Cognito native user attributes. I wonder if you encounter similar issue. Basically, when I created the native user for a user logged in with Facebook, I set email_verified to true, but when Auth.federatedSignIn is called again, email_verified is set to false because it reloads the attribues from Facebook to Cognito and Facebook doesn't have the email_verified attribute apparently. I just created an issue at Amplify.js: https://github.com/aws-amplify/amplify-js/issues/7300

@xitanggg Glad to hear it works for you too! Oh yes, I have that issue with email_verified as well, I forgot to mention it in my comment. What I do is I automatically confirm and set email_verified to true for every user in the PostAuthentication trigger, if they signed in using an external provider. I can check the code I used if that would be helpful.

@ianmartorell  Thanks for your prompt response. That is actually what I am thinking as well using AdminUpdateUserAttributes.

Yeah it's pretty stupid... Unfortunately I don't think there's any other way. As email_verified comes as false from external providers for some reason, it gets overwritten on every login. It's quite bothersome. Honestly we have to go through so many hoops and hacks to make social login work with Amplify, it's crazy.

I was able to map google's email_verified to cognito and it comes with true. So I only need to do it for facebook. The problem in this case is more in Cognito than Amplify. I am not sure why Cognito is set up to overwrite the attributes https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-user-pools-specifying-attribute-mapping.html. Sad, but I will just move on

Amazon Cognito must be able to update your mapped user pool attributes when users sign in to your application. When a user signs in through an identity provider, Amazon Cognito updates the mapped attributes with the latest information from the identity provider. Amazon Cognito updates each mapped attribute, even if its current value already matches the latest information. If Amazon Cognito can't update the attribute, it throws an error. To ensure that Amazon Cognito can update the attributes, check the following requirements:

When the Pre sign up hook run it will just create the link but then users will have to sign in again in order to complete the process and this run in two steps, how can i sign in user with external provider right after the link is complete?

When the Pre sign up hook run it will just create the link but then users will have to sign in again in order to complete the process and this run in two steps, how can i sign in user with external provider right after the link is complete?

I ran into the same issue and explained my workaround in the first bullet point here: https://github.com/aws-amplify/amplify-cli/issues/4427#issuecomment-718549881.

Can you please be more specific on how you are catching this error on the Frontend? since using the Amplify api will force a redirect and the error wont be presented on the function that triggered the sign in.
Thanks

The exact implementation varies based on the front end framework you use and the error message you throw. The high level idea is that

Once the native user is created and linked with the external provider, it throws an error to the front end. The error appears as a query parameter in the url, like this ?error_description=LINKED_EXTERNAL_USER_{providerName}
You can create something that monitor the url, extract the providerName, and reinitiate the auto sign in for that provider.

In React, I simply create a useEffect hook to do so and use the hook at my redirect page.
import { useState, useEffect } from 'react';
import { useHistory } from 'react-router-dom';
import queryString from 'query-string';
import { Auth } from 'aws-amplify';

const autoExternalSignIn = async (provider) => {
	try {
		await Auth.federatedSignIn({ provider: provider });
	} catch (error) {
		console.log('Error auto sign in: ', error);
	}
};

/**
 * useAutoExternalSignIn hook attempts to auto sign in user after users register
 * an account with Google / Facebook external provider.
 *
 * When user first registers an account using Google / Facebook, a native user is created
 * in AWS Cognito and an error is throwed to the front end when the process is succeeded.
 */

const useAutoExternalSignIn = () => {
	const [numRetry, setNumRetry] = useState(0);
	const history = useHistory();
	const params = queryString.parse(history.location.search);
	const errorDes = params.error_description;
	useEffect(
		() => {
			if (numRetry < 2 && errorDes) {
				if (errorDes.includes('LINKED_EXTERNAL_USER_Facebook')) {
					autoExternalSignIn('Facebook');
					setNumRetry((prev) => prev + 1);
				}
				if (errorDes.includes('LINKED_EXTERNAL_USER_Google')) {
					autoExternalSignIn('Google');
					setNumRetry((prev) => prev + 1);
				}
			}
		},
		// eslint-disable-next-line
		[errorDes]
	);
};

export default useAutoExternalSignIn;

Testing @xitanggg  implementation i sometimes get the following error when first signup with google "Invalid SourceUser: Cognito users with a username/password may not be passed in as a SourceUser, only as a DestinationUser"

@oahmaro Interesting, this is my implementation and I haven't encountered this issue. I am not sure what might cause it but I would suggest console.log various variables in each stage of the code to trace down what might cause it. Would be interested to see what you find out.

@oahmaro I also faced the same issue. But later found out that I already had an account in Cognito with the Google account I'm trying. I tried to signup before setting up the pre signup hook. You'll have to clear them out before trying this.

hi @xitanggg , can you please share your implementation on post authentication trigger to fix facebook signing overriding the email_verified value?
This would help me a lot as i am not familiar with Cognito API

@oahmaro I also faced the same issue. But later found out that I already had an account in Cognito with the Google account I'm trying. I tried to signup before setting up the pre signup hook. You'll have to clear them out before trying this.

Well not really, this issue happens to me even if i don't have any account, i am still investigating the cause

Testing @xitanggg implementation i sometimes get the following error when first signup with google "Invalid SourceUser: Cognito users with a username/password may not be passed in as a SourceUser, only as a DestinationUser"

I was getting this too! It drove me insane for days, I checked the API calls over and over and I was definitely passing Cognito user  as a DestinationUser. In the end it stopped happening, and as weird as it sounds I think it was because I increased the CPU and memory used by the lambda functions. I did it through editing the CloudFormation templates, I can check what I changed exactly in a few hours.

@oahmaro You can verify the email in the pre-signup hook right after linking the accounts like this:
await cognitoProvider
  .adminUpdateUserAttributes({
    UserAttributes: [
      {
        Name: 'email_verified',
        Value: 'true',
      },
    ],
    Username: destinationAttributeValue,
    UserPoolId: event.userPoolId,
  })
  .promise();

To confirm and enable the user account, you can do the following:
await cognitoProvider
  .adminConfirmSignUp({
    Username: destinationAttributeValue,
    UserPoolId: event.userPoolId,
  })
  .promise();

Make sure you set the proper permissions in the cloudformation-template.json:
"Action": [
  "cognito-idp:ListUsers",
  "cognito-idp:AdminLinkProviderForUser",
  "cognito-idp:AdminConfirmSignUp",
  "cognito-idp:AdminUpdateUserAttributes"
],

Testing @xitanggg implementation i sometimes get the following error when first signup with google "Invalid SourceUser: Cognito users with a username/password may not be passed in as a SourceUser, only as a DestinationUser"

I was getting this too! It drove me insane for days, I checked the API calls over and over and I was definitely passing the Cognito user as a DestinationUser. In the end it stopped happening, and as weird as it sounds I think it was because I increased the CPU and memory used by the lambda functions. I did it through editing the CloudFormation templates, I can check what I changed exactly in a few hours.

Hi @ianmartorell this would help a lot. Thanks

Hi @ianmartorell this would help a lot. Thanks

So basically in my PreSignup template I have this:
{
	"Resources": {
		"LambdaFunction": {
			"Properties": {
				"Handler": "index.handler",
				"MemorySize": 2048,   <-- Add this line
			}
		},
	},
}

Note that although this increases memory usage and it sounds like your functions will be more expensive, they actually run a lot faster because CPU speeds are tied to memory size in lambda functions, and the faster they run the cheaper they are. I haven't run actual benchmarks, but the speed increase was reeeally noticeable in my PostAuthentication hook. I used to have to wait a good couple of seconds after logging in, and now it feels instant.

@ianmartorell  this seems to fix the issue, speaking of speed this whole signup trigger takes 15 seconds to sign in user in the first time, and 8 seconds after account is linked, which seems to be long. anyone tested the time it takes?

@ianmartorell this seems to fix the issue, speaking of speed this whole signup trigger takes 15 seconds to sign in user in the first time, and 8 seconds after account is linked, which seems to be long. anyone tested the time it takes?

Actually nevermind my metrics as they are inaccurate, after building my app app it actually was much faster.

Haha, good catch @ianmartorell! I actually suspect memory might be the cause, but wasn't 100% sure. I always have my lambda memory size up, in this case to 512MB "MemorySize": "512", so I never actually encounter what you two encounter, got lucky.
The default lambda memory size is 128MB, which is stupid, because the aws-sdk is 57.9 MB big. I suspect it might run out of memory using it therefore causing the error. Amplify team should consider changing the default memory for lambda function whenever it uses the aws-sdk.
@oahmaro my users are coming from google provider and they got mapped correctly, so I haven't written the code to overwrite facebook provider yet (at least not now, may be I will in the next month or so). The Cognito API isn't too difficult to understand. You just need to spend some time reading the docs. As mentioned, AdminUpdateUserAttributes would do the trick, make sure to set proper permission as well.

@palpatim @elorzafe FYI for Auth tracking

@xitanggg I'm using forceAliasAuth=true so that I can sign-in user through username(preferred username) or verified email. My only required attribute is email for sign-up a user. Your code is working for 1st sign-up with email then use same email as signin with Google(but I'm not getting error that ) but when I'm trying fresh new sign in with google it is not working(it is not creating an user entry). my code:  and one thing username can't be email as forceAliasAuth=true.
`const aws = require('aws-sdk');
const { v4: uuidv4 } = require('uuid');
exports.handler = async (event, context, callback) => {
//  ... skip other codes
// If trigger source is external provider
if (event.triggerSource === 'PreSignUp_ExternalProvider') {
	const cognitoProvider = new aws.CognitoIdentityServiceProvider({
		apiVersion: '2016-04-18',
	});

	try {
		// Get user based on email
		const listUserParams = {
			UserPoolId: event.userPoolId,
			AttributesToGet: null, //null returns all attributes
			Filter: `email = \"${event.request.userAttributes.email}\"`,
			Limit: 1,
		};
		const listUsersRes = await cognitoProvider
			.listUsers(listUserParams)
			.promise();

		let destinationAttributeValue;
		// If user not found, create user
		if (listUsersRes.Users.length === 0) {
			console.log('User not found');
			const {
				email = '',

			} = event.request.userAttributes;
			const newPassword = uuidv4(); // or use your own implementation
			const newUserParams = {
				UserPoolId: event.userPoolId,
				Username: event.userName,
				MessageAction: 'SUPPRESS',
				TemporaryPassword: newPassword,
				UserAttributes: [
					{
						Name: 'email',
						Value: email,
					},
					{
						Name: 'email_verified',
						Value: String(!!email), //auto verify email if provided
					},

				],
			};

			const newUser = await cognitoProvider
				.adminCreateUser(newUserParams)
				.promise();

			// Confirm new user
			const setPasswordParams = {
				Password: newPassword,
				UserPoolId: event.userPoolId,
				Username: newUser.User.Username,
				Permanent: true,
			};
			await cognitoProvider.adminSetUserPassword(setPasswordParams).promise();

			destinationAttributeValue = newUser.User.Username;
		}
		// If user found, simply set username
		else {
			console.log('User found');
			destinationAttributeValue = listUsersRes.Users[0].Username;
		}

		// Link User
		console.log('Link user');
		let [sourceProviderName, sourceAttributeValue] = event.userName.split(
			'_'
		);
		sourceProviderName =
			sourceProviderName[0].toUpperCase() + sourceProviderName.slice(1);
		const adminLinkParams = {
			DestinationUser: {
				ProviderAttributeValue: destinationAttributeValue,
				ProviderName: 'Cognito',
			},
			SourceUser: {
				ProviderAttributeName: 'Cognito_Subject',
				ProviderAttributeValue: sourceAttributeValue,
				ProviderName: sourceProviderName,
			},
			UserPoolId: event.userPoolId,
		};
		await cognitoProvider.adminLinkProviderForUser(adminLinkParams).promise();

		// Finish linking, throw error to frontent
		callback(new Error(`LINKED_EXTERNAL_USER_${sourceProviderName}`), event);
	} catch (error) {
		callback(error, event);
	}
}

callback(null, event);

};my permission:{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "VisualEditor0",
"Effect": "Allow",
"Action": [
"logs:CreateLogStream",
"logs:PutLogEvents",
"cognito-idp:AdminInitiateAuth",
"cognito-idp:ListUsers",
"cognito-idp:AdminUpdateUserAttributes",
"cognito-idp:AdminLinkProviderForUser",
"cognito-idp:AdminCreateUser",
"cognito-idp:AdminSetUserPassword"
],
"Resource": [
"arn:aws:logs:us-east-1:xxxxxxxxxxxxxx:log-group:/aws/lambda/Auto_Merge_Account:*",
"arn:aws:cognito-idp:us-east-1:xxxxxxx:userpool/us-east-1xxxxxxxxxxxx"
]
}
]
}`

@ianmartorell @xitanggg this is not working for me when fresh new sign up with google & im using force alias auth and only requried attirbute is email and user can sign up with email & preferred username and second thing I have mapped username in post conformation function when there is fresh signup with with Google It will not trigger post confirmation as we are throwing error.
`if (listUsersRes.Users.length === 0) {
console.log('User not found');
const {
email = '',
} = event.request.userAttributes;
const newPassword = uuidv4(); // or use your own implementation
const newUserParams = {
UserPoolId: event.userPoolId,
Username: email,
MessageAction: 'SUPPRESS',
TemporaryPassword: newPassword,
UserAttributes: [
{
Name: 'email',
Value: email,
},
{
Name: 'email_verified',
Value: String(!!email), //auto verify email if provided
},
				],
			};

			const newUser = await cognitoProvider.adminCreateUser(newUserParams).promise();

			// Confirm new user
			const setPasswordParams = {
				Password: newPassword,
				UserPoolId: event.userPoolId,
				Username: newUser.User.Username,
				Permanent: true,
			};
			await cognitoProvider.adminSetUserPassword(setPasswordParams).promise();

			destinationAttributeValue = newUser.User.Username;
		}`

@xitanggg @ianmartorell @THPubs  specially adminCreateUser showing error: PreSignUp invocation failed due to error TooManyRequestsException. Why I don't know please tell me solution. whether you are facing the same issue or not.

This issue has been open for over 2 years - is there an update on a timeline for getting this fixed? Making the user login twice is not an acceptable workaround

Hi @ianmartorell this would help a lot. Thanks

So basically in my PreSignup template I have this:
{
	"Resources": {
		"LambdaFunction": {
			"Properties": {
				"Handler": "index.handler",
				"MemorySize": 2048,   <-- Add this line
			}
		},
	},
}

Note that although this increases memory usage and it sounds like your functions will be more expensive, they actually run a lot faster because CPU speeds are tied to memory size in lambda functions, and the faster they run the cheaper they are. I haven't run actual benchmarks, but the speed increase was reeeally noticeable in my PostAuthentication hook. I used to have to wait a good couple of seconds after logging in, and now it feels instant.

This worked initially for mitigating the confusing error. Then I added a function call to set the user's email_verified to true AFTER linking the accounts, and no matter how much I increase memory, we're back at
"Invalid SourceUser: Cognito users with a username/password may not be passed in as a SourceUser, only as a DestinationUser"
for linking the accounts.

Three and a half years later, Cognito doesn't yet support this natively... It's unbelievable

would love to thumbs up this issue to vote support for this feature request

Amplify, please add multi social account linking. This would take you few weeks, why has it been 4 years?

Any update on this feature-request?


Restructure Tutorial Image naming

This restructuring is automated so we can rerun if if we need to change the source before we merge this.
This PR changes the following:

Moves icon/button images to shared folder
Names all images which are not coming from Skyline using the format "s-name"
All other images are renamed / renumbered to the format "s-#"

This will make it simpler to output images from tutorial tests with a counter for now. Also we can use the s- prefix to add alt text / anchors in html programmatically
Example:

Will rerun script once #3180 is merged

Looks great. Definitely an improvement on several levels. Please start the s-# with s-1 instead of s-0. These are not indices into an array. I know the # from s-# will not line up with "Figure #", but I still think it is better to have the s-# and Figure # both start with 1.

I have merged PR #3180

Looks great. Definitely an improvement on several levels. Please start the s-# with s-1 instead of s-0. These are not indices into an array. I know the # from s-# will not line up with "Figure #", but I still think it is better to have the s-# and Figure # both start with 1.

Numbering starts at 1 now. This should be ready for merge.


JavaScript in compiled mode MODMS-50

TODO: Dockerfile

@adamdickmeiss Regarding Dockerfile see my comment on the ticket: https://issues.folio.org/browse/MODMS-50?focusedCommentId=131192&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-131192

Closing as work is done in #24


Using CFI js with readium viewer js.

hi,
I have installed n run all the set up for development of CFI. Now I am reading epub files using readium-js-viewer library. I am planning for text highlighting in the reader. So i want to use CFI to store the highlighted text. My problem is I am not getting how to generate CFI for a file. Please let me know how and from where I can start the coding for generating CFI in readium-js-viewer library. Thanks in advance.....

Closed due to inactivity. Please re-open if you would still like this to be answered. We are in the process of improving our documentation. Thanks.


Classes and Instances (class, new)

New types needed:
ClassType - ClassInstance
ObjectType - ObjectInstance
New keywords needed:
static
pub
Example:
class File {
  handle: CFile;
  pub filename: string;

  read(size: uint): array -> {}

  static open(name: string): File -> { ... }
}

Inheritance: prototype
Will have base class as a field of ClassInstance
If multiple inheritance will be a thing, a list of base classes will be stored

Implementation: https://github.com/maxrt101/ff/tree/issue-19-class-support

d6c3a43 - rev1
Done:

Implemented class and new constructs (parsing and compiling).
Classes support fields and methods (non-static).
Todo:
Constructor
Destructor
Static fields and methods
Const fields
Inheritance (TBD)

Merged


Support for centralized configuration and shared variables in separate Tengo scripts

Description:
I'm currently using Tengo scripts for configuration management in my application. I have a central configuration script (base.tengo) that defines global settings like whether certain features (e.g., MySQL, Redis) should be enabled or not. I then have separate environment-specific scripts (dev.tengo and prod.tengo) that use these global settings to set up connection parameters for different environments.
Here's the structure:
config/base.tengo (Defines global settings)
config/dev.tengo (Specific settings for the development environment)
config/prod.tengo (Specific settings for the production environment)
main.go (Runs the configuration updater)
However, I'm facing an issue where I want to control these global settings in the base.tengo script and share them with the environment-specific scripts (dev.tengo, prod.tengo) without having to modify main.go. In other words, I want to achieve centralized configuration management and share these settings among the different Tengo scripts.
Currently, I'm facing difficulties in importing the global settings from base.tengo into dev.tengo and prod.tengo. The import paths seem to be causing issues, and I'm looking for a way to share these settings across different scripts seamlessly.
MyCode:
config/base.tengo
export func() {
    return {
        mysqlEnabled: true
    }
}()

config/dev.tengo
ctl := import("./config/base")

mysql := func() {
    if ctl.mysqlEnabled {
        return {
            host: "dev.mysql.com",
            port: 3306,
            username: "dev_user",
            password: "dev_pass",
            dbname: "dev_db"
        }
    }
    return {}
}()

Is there a recommended approach or any updates planned that would enable centralized configuration management and sharing of variables among separate Tengo scripts? This would greatly improve the maintainability and flexibility of the configuration setup.
Thank you for your time and consideration!

Can you explain what difficulties you're actually facing?


Not working in Kubernetes

App works in docker running in virtual machine. But  when running in Kubernetes (Linux or Windows) it starts, but do not handle calls. PBX reports error: No script configured for URL 'agi://<IP_ADDRESS>:30000/IVR_TEST' (script 'IVR_TEST')

Sounds like a PBX/Asterisk issue?
Not enough information for me to know what your issue is.


Defaults

Redis dev-rel just posted this over at OpenSource.com wondering if you'd be open to a PR so that vanilla local-machine settings are not necessary (looks like they are not now), and the client can work with environment vars instead of coding credentials.

I am aware this isn't ideal if you have multiple applications that are not isolated or multiple sets of credentials in a single monolithic application. I'm quite sure that is a rare edge case.

PR closure should have closed this. My bad for not closing


chore: tidied up timestamps for pair

Lets keep things real simple
• Show everything in UTC (except for FTUX, dont change anything there)
• On hover over all UTC time show a tooltip with localized time (ex. July 13, 2023 at 1:00PM)
• If you want to be fancy, in the tooltip for localized time show Today if before 24hrs

I say we sit on this until at least 3 users complain. Feels low priority compared to other work. @madhuravius

Closing for now, we can leave the branch around for awhile.


Bump maven-plugin-annotations from 3.6.1 to 3.6.2

We reverted this change because it makes problems during the deploy step to Sonatype.


Java API

I'm looking for a Java API for Exceptionless.
It looks like there has been previous interest in supporting a Java API, but there doesn't appear to be any active development of one?

Hello,
My apologies for the extremely long delay in response. We would love to have a Java API and would be willing to work with the community to build one. Would you be interested in helping with this?

i want Java too   ,  and  i will try to build one.

It would be super nice to port our .net one to java. I wonder if a converter could get us most of the way there.

I'm going to close this, we want java support and if someone sends us a pr for it or we have time to add it we will. I'd be more than happy to help put anyone in the right direction.


Aliases not working because jsconfig.json is missing

Version
v2.12.2
Reproduction link
https://github.com/ainochu/nuxt-photo-blog/tree/0253b4411caf183774a4e4b93cb3a47758417099
Steps to reproduce
For repo:

Clone
npm install
npm run dev

Without repo:

Create a new nuxt project from scratch as per https://nuxtjs.org/guide/installation/#starting-from-scratch
Create a data.json file within assets directory
Create index.vue under pages directory
Attempt to load the json file in asyncData using await require('~/assets/data.json')

Run npx nuxt
An error will be raised: "This dependency was not found"
What is expected ?
Everything is fine
What is actually happening?
The project will fail to compile because jsconfig.json is missing!
I think it would be worth mentioning that in https://nuxtjs.org/guide/directory-structure#aliases

This bug report is available on Nuxt community (#c10603)

require doesnt return a promise so adding await isnt needed and may cause an issue.
On a higher level, why are you requiring in asyncData? I would be surprised if this has any (performance) benefit above just using an import and use/return that import in asyncData.

Hi @pimlie!
You are right, require is blocking and will return contents directly, so await is not necessary.
There was a use case for require in asyncData to load different blog entries based on params:
https://github.com/ainochu/nuxt-photo-blog/blob/0253b4411caf183774a4e4b93cb3a47758417099/pages/blog/_blog.vue#L14
Indeed, I've just tested locally and dynamic import works just fine.
export default {
  async asyncData({ params }) {
    return import(`~/assets/content/blog/${params.blog}.json`).then((data) => ({
      blogPost: data.default
    }));
  }
};

Also, I cannot reproduce the problem with ~ alias in my machine, so will once more review the setup with @ainochu
Thanks!


Drop browserify

Summary
Use the UMD distributions of redux and redux-thunk instead of browserifying the CJS source.
This relies on the new transformation feature for app.import available in ember-cli 2.9.0.
Details
The dependencies are added to the vendor tree via treeForVendor which resolves their path and adds the appropriate dist folder containing the UMD files.  Then files are then imported into the project using the AMD transformation flag and given the appropriate package name ("redux" and "redux-thunk").
If the build is for addon development, redux-saga is also added.
redux and redux-thunk are installed and added to the users dependencies via the default blueprint.  ember-redux adds redux and redux-thunk as peerDependencies to maintain control over supported versions.  As an alternative, this could be done as a regular ember-redux dependency, which would mean we could skip the blueprint altogether.  However, peerDependencies gives the user finer control over the precise version of redux and redux-thunk they want to use.
Considerations

Are we ok with having the user continue to explicitly install redux and redux-thunk?  (automated by the default blueprint and enforced by package.json peerDependencies)
We remain Ember 2.0.X compatible, but the user must be using ember-cli >= 2.9

/cc @aaminev @MiguelMadero

@dustinfarris great work here - this immediately speeds up both hot and cold rebuilds for those who don't need ember-browserify for anything else :)
The biggest issue here is that I think we need/should do a v2.0 release if we pull this in. Not because the api has changed but because the "ember install experience" will differ greatly from what we have today and the ember-cli requirement is much more strict.
Thoughts?

The ember install experience is the same if you're using ember-cli >= 2.9.  ember install ember-redux "just works" as it has.  This is breaking for anyone upgrading/installing though who is ember-cli < 2.9.  It will "just break" and I doubt it will be immediately obvious why.
We should include good release notes letting people know about ember-cli and about the break, and also that they can drop ember-browserify if they are not using it for anything else.  We should update the README to indicate that ember-cli >= 2.9 is required going forward.
Unfortunate to bump major on a tooling issue, but agree we should since ember-cli is used by probably 100% of Ember community at this point.  Anyone who has "^1.x.x" in their package.json should be insulated from an ember-cli break.

On Dec 2, 2016, at 9:49 PM, Toran Billups<EMAIL_ADDRESS>wrote:
@dustinfarris https://github.com/dustinfarris great work here - this immediately speeds up both hot and cold rebuilds for those who don't need ember-browserify for anything else :)
The biggest issue here is that I think we need/should do a v2.0 release if we pull this in. Not because the api has changed but because the "ember install experience" will differ greatly from what we have today and the ember-cli requirement is much more strict.
Thoughts?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub https://github.com/toranb/ember-redux/pull/57#issuecomment-264610967, or mute the thread https://github.com/notifications/unsubscribe-auth/ABCWvXcsCx6J-NdT83QbgnEpjyKlT7kqks5rENixgaJpZM4LDEYi.

--
Dustin Farris

Required for the user, yes.  npm will throw errors if they are not satisfied.  This allows us to enforce compatibility, while letting users install the precise version they want so long as it falls within our supported range.
Recent versions of npm do not install peerDependencies for you as a user.  If you were to npm install ember-redux you would not get them automatically.  You have to install them yourself.  However if you ember install ember-redux, the default blueprint will do this for you.
I did not run into any issues with redux-saga other than making sure it is not included in the build if not working on ember-redux directly.

On Dec 3, 2016, at 10:43 AM, Toran Billups<EMAIL_ADDRESS>wrote:
@toranb commented on this pull request.
In package.json https://github.com/toranb/ember-redux/pull/57#pullrequestreview-11281703:

 "ember-cli-babel": "^5.1.7"

},

"peerDependencies": {
Are peerDependencies required? just curious as I often avoid them when using npm 3+

also - did you run into any issues with redux-saga or was adding the npm dep above good enough?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub https://github.com/toranb/ember-redux/pull/57#pullrequestreview-11281703, or mute the thread https://github.com/notifications/unsubscribe-auth/ABCWvflvFpVz-skvc18MjdVvRi6BPazFks5rEbg7gaJpZM4LDEYi.

--
Dustin Farris

It sounds like this is all good except for ember-cli users not up to v2.9.1+
My suggestion is that we pull this in and cut v2.0 promising to maintain both 1x and 2x branches until a non tooling api change occurs next year, in which case we will likely drop support for older versions of ember-cli

It is possible to detect both, the version/presence of browserify as well
as the version of ember-cli by reading project.packages. When I was
thinking of this initially I thought it could be done in a backwards
compatible way with a warning.
On Sun, Dec 4, 2016 at 2:24 PM Toran Billups<EMAIL_ADDRESS>wrote:

It sounds like this is all good except for ember-cli users not up to
v2.9.1+
My suggestion is that we pull this in and cut v2.0 promising to maintain
both 1x and 2x branches until a non tooling api change occurs next year, in
which case we will likely drop support for older versions of ember-cli
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/toranb/ember-redux/pull/57#issuecomment-264728418,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAC5HKuhhq-e3wa_Z48x7hJzv-lKd3LKks5rEyGGgaJpZM4LDEYi
.

This might be a better solution: https://github.com/asakusuma/ember-rollup
Will test and report back.

@dustinfarris and @toranb I'm happy to create new Ember shims for both redux and redux-thunk as an alternative solution to this problem. In doing so the shims will work with any version of Ember and Ember CLI. I've already created the following shims which are being used without issue in projects on various versions of Ember and Ember CLI:

ember-dagre
ember-graphlib
ember-lodash-shim
ember-seamless-immutable-shim
ember-validator-shim
ember-z-schema

I apologize if those repositories are lacking in documentation.

The redux shim is completed: https://github.com/ciena-blueplanet/ember-redux-shim
You can simply add ember-redux-shim to the ember-cli blueprints and consumers will get both the shim as well as redux installed into their node_modules directory. The shim will then magically wire the redux source directly into their Ember stack so they can just do things like import {createStore} from 'redux'. Looks like normal Javascript imports without the extra npm: garbage ember-browserify makes you do. I also took the liberty to remove the error that shows up in the console when using this in a production environment.

The redux-thunk shim is now completed as well: https://github.com/ciena-blueplanet/ember-redux-thunk
Installation
ember install ember-redux-thunk

NOTE: I'm proposing we simply add this Ember dependency to the ember-redux blueprints.

Usage
import ReduxThunk from 'redux-thunk'

I'll work on an alternative PR that uses my shims instead so ya'll can weigh in on what approach makes more sense.

I've proposed an alternative approach using my new shims with #63

@MiguelMadero any chance you've had time to consider alternatives suggested thus far? We've got @sandersky with a shim option (pros/cons) and the approach @dustinfarris has listed here. What are you most worried about regarding total cost of ownership?

@toranb sorry for the late response.

@MiguelMadero do you have apps that wouldn't be able to upgrade if ember-cli v2.9.1+ is required? Also - if we check for browserify and warn the user ... how would this know if they are using ember-browserify for this addon/ or another?

That's not a problem for us, but I think it would be better, if possible, to decouple the two. @sandersky 's solution doesn't require any changes to CLI, which is nice for ppl that aren't ready to update yet, but still want the latest from ember-redux.

@MiguelMadero any chance you've had time to consider alternatives suggested thus far? We've got @sandersky with a shim option (pros/cons) and the approach @dustinfarris has listed here. What are you most worried about regarding total cost of ownership?

First of all thanks to both for the PRs. I think both are great, viable solutions that took good effort and I appreciate it.
The main advantage I see with the shims is that it will be easier for consumers to upgrade. In terms of TCO, long term I think that the shims can be easier to evolve as long as we reduce the bus factor. The solution proposed on this PR will require changes once Ember CLI evolves to include things like tree-shaking and, worst case scenario, it may require additional changes for consumers in the future. With the shims, once CLI supports it, we'll likely get tree-shaking without additional work and once we have a better way to consume npm modules in CLI, we may just drop the shims and consume directly from source without impacting consumers.
One of the drawbacks I see with the shims is that ES Modules were introduced in 3.6 of redux, so this technique won't work with older versions, unless there is another way. That's not an issue for us since we're just starting with the latest, but I'm not sure if that may be a problem for other consumers of ember-redux. What do you think @toranb ?
BTW for redux-sage it was on 0.13.0 and 2.1.0 for redux-thunk
@dustinfarris what do you think? Am I missing something? Do you see other pros/cons with either approach?

I like the shims a lot.
But to make this a little more confusing, I've opened #68 which offers a third option using rollup.  (keeping the conversation in this thread for continuity)  There is a failing test but would like someone more familiar with this middleware test to take a look—it may not really be a failure.

So with 3 alternatives now, my take on pros/cons are:
Option (1) - Transform and import UMD dist
We are lucky that redux/-thunk/-saga embrace supporting as many build solutions as possible by providing something like a separate UMD distribution which they certainly don't have to do.
PROS:

Quick and dirty
Code is simple and easy to understand

CONS:

Requires ember-cli >= 2.9

Option (2) - Install shims
Shims are solid go-to solution in general for situations such as this, and I think dumping the dependency tree in treeForAddon is very clever (bravo, @sandersky!).  If we go this route, it might be worth considering a GitHub ember-redux organization to keep everything together.
Also, we should consider that future versions of redux/-thunk/-saga could do something exotic that requires a babel plugin or some other build tool that we don't use.  This could lead to surprises.  However my impression of the reactjs organization is that they are pretty damn careful with that sort of thing.
PROS:

Shims are a common and well understood concept
(Very) easy to plug and play on the ember-redux side

CONS:

Adds additional layers of responsibility to the project pipeline
Echoing @MiguelMadero re: ES dist for earlier versions deps
Have to be mindful of potential future upstream build incompatibilities

Option (3) - Use rollup
I like rollup, but it takes some getting used to.  Ember ecosystem adoption is there, but not widespread from what I can tell.  The ember-rollup project is a good start, but does not go far enough, so anyone wanting to use rollup is better off doing it themselves with broccoli-rollup (which is solid).
PROS:

Seems to be the direction ember-cli is headed

CONS:

May not be as easy to understand by junior contributors
Again echoing @MiguelMadero re: ES dist for earlier versions deps (although rollup provides workarounds for many cases)

If I had to make a gut call, I'd say go for the shims and put this away.
/cc @toranb

@dustinfarris @MiguelMadero wow you guys really put in some time here! Thank you both !!!
I like the shims and if redux-saga is just for tests we could still include browserify for that build (including saga as we do today). Assuming we adopt this approach it would keep the saga assets (shim) out of the assets for those not using it (correct me if this sounds crazy)

The main reason I like the shim route is as an app developer I can include ember-redux as well as some other project (ie ember-frost-bunsen), with both using the shims. I bring up ember-frost-bunsen because that is a project I maintain that now uses these new shims instead of ember-redux as it was only using ember-redux for access to redux and redux-thunk.

@toranb as long as ember-redux-saga isn't in the blueprint so it won't be included by default, but if someone wants it they can ember install it.

Replaced by #63


Add support for configuring Availability zones

New field is added to configure availability zones in external-ids:ovn-cms-options.
Related-Issue: OSPRH-5008

/lgtm


sched/tls: inline group info in flat mode to improve performance

Summary
sched/tls: inline group info in flat mode to improve performance
inline group info in flat mode to improve the task create/destroy performance
Signed-off-by: chao an<EMAIL_ADDRESS>Impact
N/A
Testing
nsh/sim

Depends on https://github.com/apache/nuttx-apps/pull/2314

Update the PR again to remove the depends with libuv change, ready for review now

Depends on https://github.com/apache/nuttx-apps/pull/2314

@anchao
Since the above PR has been closed,  I think this PR does not depend on any PR.
Is my understanding correct?

Depends on apache/nuttx-apps#2314

@anchao Since the above PR has been closed, I think this PR does not depend on any PR. Is my understanding correct?

@masayuki2009 Yes, https://github.com/apache/nuttx/pull/11805 resolved the compile warning of libuv


update to Xcode 6.3: could not compile and show: SQLite-Bridging.h' file not found

'SQLite-Bridging.h' file not found
#import "SQLite-Bridging.h"

How are you installing SQLite.swift? Are you using the framework as instructed or did you drag the source files into your project? Are you building for OS X or iOS (device or simulator)?

hello，I use SQLite.swift with supporting iOS7, before I update to Xcode6.3, it works well in Xcode 6.2. I created a new project and drag the sourece files in to it. And it also show the error above when compiling.

Sorry,I checked agin and found something wrong I made.
I read Frameworkless Targets section
In your target’s Build Phases, add libsqlite3.dylib to the Link Binary With Libraries build phase.
Copy the SQLite.swift source files (from its SQLite directory) into your Xcode project.
Remove import sqlite3 (and @import sqlite3;) from the SQLite.swift source files that call it.
Add the following lines to your project’s bridging header (a file usually in the form of $(TARGET_NAME)-Bridging-Header.h.
#import <sqlite3.h>
#import "SQLite-Bridging.h"
I remove improt sqlite3 but now there is another error

Hi.I solved the miss error.
I drag fts3_tokenizer.h file into my project. it complied success.

Glad you got it working :+1:


Upgrade python-telegram-bot to 6.1.0

6.1.0

Fully support Bot API 3.0
Add more fine-grained filters for status updates
Bug fixes and other improvements

Tested with the following configuration:
telegram_bot:
  - platform: polling
    api_key: !secret telegram_api
    allowed_chat_ids:
      - !secret telegram_client

notify:
  - platform: telegram
    name: telegram
    chat_id: !secret telegram_client

Message sent with "Call Service"
{"message": "The sun is {% if is_state('sun.sun', 'above_horizon') %}up{% else %}down{% endif %}!"}

Hi @fabaff, watching this PR, I was thinking what Telegram new API calls are of interest to implement in the telegram_bot component, and I saw that the delete_message (which is older than API 3.0) wasn't implemented, so I made a PR with that (#8153)
What changes, regarding the API 3.0, you can think of to improve the telegram_bot component? The send_video or send_video_note services, perhaps?


feat: Support NestJS filter function for subscriptions

NestJS subscriptions' resolvers have a filter and a resolve function in the @Subscription decorator. Currently only the resolve is supported by the YogaDriver for NestJS.
This commit adds support for the filter method. The implementation is similar to NestJS Apollo plugin, but it uses Yoga's own async iterator utils (pipe, filter) instead of Apollo's utils.

This can be achieved with function composition using the filter and pipe operators exported from yoga. I see no need to add this in the API.

Hello!
I suggest reading through https://github.com/dotansimha/graphql-yoga/issues/2978
In short, the subscription decorator has a filter method that is used in other drivers and if you want to switch to yoga you will need to rewrite the code which is not ideal. For my example migrating 200+ subscriptions. Another point is that nest documentation guides you to use filters in decorator which can lead to data leaks because the filter argument is ignored and never called in the yoga driver. This is what happened to me, I did not notice that the filters stopped working and stared pushing all events to frontend

Thank you @gthau for this great PR, it looks awesome! I would kindly ask you to run pnpm changeset and create a new minor release for this feature, thanks in advance.
Also thanks to @bernessco for elaborating the need, very insightful.

Thank you @bernessco  and @enisdenjo!
Always a pleasure collaborating with The Guild.

This is now live in<EMAIL_ADDRESS>and<EMAIL_ADDRESS>Feedback is very welcome!

This is now live in<EMAIL_ADDRESS>and<EMAIL_ADDRESS>Feedback is very welcome!

I tested on my Nest project, updated  with<EMAIL_ADDRESS>removed my custom PatchedYogaDriver (which implemented subscriptionWithFilter), it works as expected.
I can't give feedback about @graphql-yoga/nestjs-federation as I don't use it.


Weird graphical glitch when browsing posts on bsky.app with Chromium 119.0.6045.192

Here is a video of the issue:
https://github.com/bluesky-social/social-app/assets/6194332/4d4b4fd6-0546-4d36-be87-b82bf2746ab0

Related?
https://github.com/bluesky-social/social-app/issues/1593
https://github.com/bluesky-social/social-app/issues/1490
https://github.com/bluesky-social/social-app/issues/1752

I think one or more of those are because of how it displays images. If so, then this issue is related to those.

This has been fixed in the most recent release