test: add potential failing test for #110 - #115
Conversation
Sorry, something went wrong.
|
@Techn1x is attempting to deploy a commit to the universal-ember Team on Vercel. A member of the Team first needs to authorize it. |
Sorry, something went wrong.
| <template> | ||
| <div {{logText this.testCase.endResult}} /> | ||
| <out>{{this.testCase.endResult}}</out> | ||
| <button type="button" {{on "click" this.setTestCase}}></button> |
There was a problem hiding this comment.
The secret sauce to get the test to fail was using the value in a modifier before using it for something else.
This test passes when either;
- you comment out the div with the modifier, or
- the value is referenced before the modifier (eg adding {{log this.testCase.endResult}} to the line before the div, or
- you use < ember 5.5ember 5.6
Sorry, something went wrong.
There was a problem hiding this comment.
This test passes when either;
- or, my production builds seem to behave OK. I can't verify this here in the test though.
Sorry, something went wrong.
|
so I pulled this down, only to realize that it needs rebased! can you rebase? thanks!! |
Sorry, something went wrong.
|
Whoops! I was operating out of an old fork. Rebased. Feel free to modify / undraft this work how you see fit. I called the test "failing case" for lack of a better name, given I'm not sure what the core problem is that it's testing for |
Sorry, something went wrong.
|
5.5 is ok, but 5.6 isn't -- this matches my expectations of ember-source, because 5.6 had the VM update |
Sorry, something went wrong.
|
I'm still investigating, but my worry is that this is related to either of these two PRs: |
Sorry, something went wrong.
|
Would either of those PRs be expected to exhibit different behaviour between test / prod builds? |
Sorry, something went wrong.
|
I wouldn't expect a difference in behavior, no -- but that doesn't mean something accidentally didn't happen! 🙈 |
Sorry, something went wrong.
|
@NullVoxPopuli hello! just revisiting this after bumping into it again. I'm onto Ember 6.2 now too ✨ Does wycats response here shed some light on this issue at all? It went a bit over my head to be honest 😅 Let me know if I can help at all. The workaround of "add a log statement before using the tracked function in template" is totally fine for my codebase, especially since it works fine in prod builds regardless. Though unfortunate for others who may not be in the know on this, and be confused when things are being weird |
Sorry, something went wrong.
aimed to be a failing test for #110