Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fix(zone.js): Promise.resolve(subPromise) should return subPromise #53423

Closed
wants to merge 1 commit into from

Conversation

JiaLiPassion
Copy link
Contributor

@JiaLiPassion JiaLiPassion commented Dec 7, 2023

Close #53380

In the original Promise impelmentation, zone.js follow the spec from
https://promisesaplus.com/#point-51.

const p1 = Promise.resolve(1);
const p2 = Promise.resolve(p1);

p1 === p2; // false

in this case, p2 should be the same status with p1 but they are
still different instances.

And for some edge case.

class MyPromise extends Promise {
  constructor(sub) {
    super((res) => res(null));
    this.sub = sub;
  }
  then(onFufilled, onRejected) {
    this.sub.then(onFufilled, onRejected);
  }
}

const p1 = new Promise(setTimeout(res), 100);
const myP = new MyPromise(p1);
const r = await myP;
r === 1; // false

So in the above code, myP is not the same instance with p1,
and since myP is resolved in constructor, so await myP will
just pass without waiting for p1.

And in the current tc39 spec here https://tc39.es/ecma262/multipage/control-abstraction-objects.html#sec-promise-resolve
Promise.resolve(subP) should return subP.

const p1 = Promise.resolve(1);
const p2 = Promise.resolve(p1);

p1 === p2; // true

So the above MyPromise can wait for the p1 correctly.

.github/workflows/ci.yml Outdated Show resolved Hide resolved
@JiaLiPassion JiaLiPassion force-pushed the promise-resolve branch 2 times, most recently from 660838b to d31bdc1 Compare December 7, 2023 14:21
@alan-agius4 alan-agius4 added area: zones target: patch This PR is targeted for the next patch release labels Dec 7, 2023
@ngbot ngbot bot added this to the Backlog milestone Dec 7, 2023
@alan-agius4 alan-agius4 added the action: global presubmit The PR is in need of a google3 global presubmit label Dec 7, 2023
@alan-agius4
Copy link
Contributor

alan-agius4 commented Dec 8, 2023

TGP
TGP deflake

@JiaLiPassion JiaLiPassion force-pushed the promise-resolve branch 2 times, most recently from 3ceb3d4 to a2a89a5 Compare December 11, 2023 01:13
In the original `Promise` impelmentation, zone.js follow the spec from
https://promisesaplus.com/#point-51.

```
const p1 = Promise.resolve(1);
const p2 = Promise.resolve(p1);

p1 === p2; // false
```
in this case, `p2` should be the same status with `p1` but they are
still different instances.

And for some edge case.

```
class MyPromise extends Promise {
  constructor(sub) {
    super((res) => res(null));
    this.sub = sub;
  }
  then(onFufilled, onRejected) {
    this.sub.then(onFufilled, onRejected);
  }
}

const p1 = new Promise(setTimeout(res), 100);
const myP = new MyPromise(p1);
const r = await myP;
r === 1; // false
```

So in the above code, `myP` is not the same instance with `p1`,
and since `myP` is resolved in constructor, so `await myP` will
just pass without waiting for `p1`.

And in the current `tc39` spec here https://tc39.es/ecma262/multipage/control-abstraction-objects.html#sec-promise-resolve
`Promise.resolve(subP)` should return `subP`.

```
const p1 = Promise.resolve(1);
const p2 = Promise.resolve(p1);

p1 === p2; // true
```

So the above `MyPromise` can wait for the `p1` correctly.
@alan-agius4 alan-agius4 added action: review The PR is still awaiting reviews from at least one requested reviewer and removed action: global presubmit The PR is in need of a google3 global presubmit labels Dec 11, 2023
@devversion devversion added action: merge The PR is ready for merge by the caretaker and removed action: review The PR is still awaiting reviews from at least one requested reviewer labels Dec 11, 2023
@alxhub
Copy link
Member

alxhub commented Dec 11, 2023

This PR was merged into the repository by commit 08b0c87.

alxhub pushed a commit that referenced this pull request Dec 11, 2023
…53423)

In the original `Promise` impelmentation, zone.js follow the spec from
https://promisesaplus.com/#point-51.

```
const p1 = Promise.resolve(1);
const p2 = Promise.resolve(p1);

p1 === p2; // false
```
in this case, `p2` should be the same status with `p1` but they are
still different instances.

And for some edge case.

```
class MyPromise extends Promise {
  constructor(sub) {
    super((res) => res(null));
    this.sub = sub;
  }
  then(onFufilled, onRejected) {
    this.sub.then(onFufilled, onRejected);
  }
}

const p1 = new Promise(setTimeout(res), 100);
const myP = new MyPromise(p1);
const r = await myP;
r === 1; // false
```

So in the above code, `myP` is not the same instance with `p1`,
and since `myP` is resolved in constructor, so `await myP` will
just pass without waiting for `p1`.

And in the current `tc39` spec here https://tc39.es/ecma262/multipage/control-abstraction-objects.html#sec-promise-resolve
`Promise.resolve(subP)` should return `subP`.

```
const p1 = Promise.resolve(1);
const p2 = Promise.resolve(p1);

p1 === p2; // true
```

So the above `MyPromise` can wait for the `p1` correctly.

PR Close #53423
@alxhub alxhub closed this in 08b0c87 Dec 11, 2023
@angular-automatic-lock-bot
Copy link

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

This action has been performed automatically by a bot.

@angular-automatic-lock-bot angular-automatic-lock-bot bot locked and limited conversation to collaborators Jan 11, 2024
ChellappanRajan pushed a commit to ChellappanRajan/angular that referenced this pull request Jan 23, 2024
…ngular#53423)

In the original `Promise` impelmentation, zone.js follow the spec from
https://promisesaplus.com/#point-51.

```
const p1 = Promise.resolve(1);
const p2 = Promise.resolve(p1);

p1 === p2; // false
```
in this case, `p2` should be the same status with `p1` but they are
still different instances.

And for some edge case.

```
class MyPromise extends Promise {
  constructor(sub) {
    super((res) => res(null));
    this.sub = sub;
  }
  then(onFufilled, onRejected) {
    this.sub.then(onFufilled, onRejected);
  }
}

const p1 = new Promise(setTimeout(res), 100);
const myP = new MyPromise(p1);
const r = await myP;
r === 1; // false
```

So in the above code, `myP` is not the same instance with `p1`,
and since `myP` is resolved in constructor, so `await myP` will
just pass without waiting for `p1`.

And in the current `tc39` spec here https://tc39.es/ecma262/multipage/control-abstraction-objects.html#sec-promise-resolve
`Promise.resolve(subP)` should return `subP`.

```
const p1 = Promise.resolve(1);
const p2 = Promise.resolve(p1);

p1 === p2; // true
```

So the above `MyPromise` can wait for the `p1` correctly.

PR Close angular#53423
rlmestre pushed a commit to rlmestre/angular that referenced this pull request Jan 26, 2024
…ngular#53423)

In the original `Promise` impelmentation, zone.js follow the spec from
https://promisesaplus.com/#point-51.

```
const p1 = Promise.resolve(1);
const p2 = Promise.resolve(p1);

p1 === p2; // false
```
in this case, `p2` should be the same status with `p1` but they are
still different instances.

And for some edge case.

```
class MyPromise extends Promise {
  constructor(sub) {
    super((res) => res(null));
    this.sub = sub;
  }
  then(onFufilled, onRejected) {
    this.sub.then(onFufilled, onRejected);
  }
}

const p1 = new Promise(setTimeout(res), 100);
const myP = new MyPromise(p1);
const r = await myP;
r === 1; // false
```

So in the above code, `myP` is not the same instance with `p1`,
and since `myP` is resolved in constructor, so `await myP` will
just pass without waiting for `p1`.

And in the current `tc39` spec here https://tc39.es/ecma262/multipage/control-abstraction-objects.html#sec-promise-resolve
`Promise.resolve(subP)` should return `subP`.

```
const p1 = Promise.resolve(1);
const p2 = Promise.resolve(p1);

p1 === p2; // true
```

So the above `MyPromise` can wait for the `p1` correctly.

PR Close angular#53423
danieljancar pushed a commit to danieljancar/angular that referenced this pull request Jan 26, 2024
…ngular#53423)

In the original `Promise` impelmentation, zone.js follow the spec from
https://promisesaplus.com/#point-51.

```
const p1 = Promise.resolve(1);
const p2 = Promise.resolve(p1);

p1 === p2; // false
```
in this case, `p2` should be the same status with `p1` but they are
still different instances.

And for some edge case.

```
class MyPromise extends Promise {
  constructor(sub) {
    super((res) => res(null));
    this.sub = sub;
  }
  then(onFufilled, onRejected) {
    this.sub.then(onFufilled, onRejected);
  }
}

const p1 = new Promise(setTimeout(res), 100);
const myP = new MyPromise(p1);
const r = await myP;
r === 1; // false
```

So in the above code, `myP` is not the same instance with `p1`,
and since `myP` is resolved in constructor, so `await myP` will
just pass without waiting for `p1`.

And in the current `tc39` spec here https://tc39.es/ecma262/multipage/control-abstraction-objects.html#sec-promise-resolve
`Promise.resolve(subP)` should return `subP`.

```
const p1 = Promise.resolve(1);
const p2 = Promise.resolve(p1);

p1 === p2; // true
```

So the above `MyPromise` can wait for the `p1` correctly.

PR Close angular#53423
amilamen pushed a commit to amilamen/angular that referenced this pull request Jan 26, 2024
…ngular#53423)

In the original `Promise` impelmentation, zone.js follow the spec from
https://promisesaplus.com/#point-51.

```
const p1 = Promise.resolve(1);
const p2 = Promise.resolve(p1);

p1 === p2; // false
```
in this case, `p2` should be the same status with `p1` but they are
still different instances.

And for some edge case.

```
class MyPromise extends Promise {
  constructor(sub) {
    super((res) => res(null));
    this.sub = sub;
  }
  then(onFufilled, onRejected) {
    this.sub.then(onFufilled, onRejected);
  }
}

const p1 = new Promise(setTimeout(res), 100);
const myP = new MyPromise(p1);
const r = await myP;
r === 1; // false
```

So in the above code, `myP` is not the same instance with `p1`,
and since `myP` is resolved in constructor, so `await myP` will
just pass without waiting for `p1`.

And in the current `tc39` spec here https://tc39.es/ecma262/multipage/control-abstraction-objects.html#sec-promise-resolve
`Promise.resolve(subP)` should return `subP`.

```
const p1 = Promise.resolve(1);
const p2 = Promise.resolve(p1);

p1 === p2; // true
```

So the above `MyPromise` can wait for the `p1` correctly.

PR Close angular#53423
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
action: merge The PR is ready for merge by the caretaker area: zones target: patch This PR is targeted for the next patch release
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Angular Zones break promises in openai package (return null)
4 participants