Status Update
No update yet.
Comments
kl...@google.com
Branch: androidx-master-dev
commit b90079595f33f58fece04026a97faa0d243acdb1
Author: Yuichi Araki <yaraki@google.com>
Date: Wed Sep 18 16:55:49 2019
Change the way to detect mismatch between POJO and query
This fixes cursor mismatch warnings with expandProjection.
Bug: 140759491
Test: QueryMethodProcessorTest
Change-Id: I7659002e5e0d1ef60fc1af2a625c0c36da0664d8
M room/compiler/src/main/kotlin/androidx/room/processor/QueryMethodProcessor.kt
M room/compiler/src/main/kotlin/androidx/room/solver/TypeAdapterStore.kt
M room/compiler/src/main/kotlin/androidx/room/solver/query/result/PojoRowAdapter.kt
M room/compiler/src/test/kotlin/androidx/room/processor/QueryMethodProcessorTest.kt
M room/compiler/src/test/kotlin/androidx/room/testing/TestProcessor.kt
ap...@google.com
ap...@google.com
Branch: androidx-master-dev
commit bdde5a1a970ddc9007b28de4aa29d60ffa588f08
Author: Yigit Boyar <yboyar@google.com>
Date: Thu Apr 16 16:47:05 2020
Re-factor how errors are dismissed when query is re-written
This CL changes how we handle errors/warnings if query is
re-written.
There was a bug in expandProjection where we would report warnings
for things that Room already fixes automatically (
The solution to that problem (I7659002e5e0d1ef60fc1af2a625c0c36da0664d8)
solved it by deferring validating of columns until after re-write
decision is made. Unfortunately, this required changing PojoRowAdapter
to have a dummy mapping until it is validating, make it hard to use
as it does have a non-null mapping which is not useful.
This CL partially reverts that change and instead rely on the log
deferring logic we have in Context. This way, we don't need to break
the stability of PojoRowAdapter while still having the ability to
drop warnings that room fixes. This will also play nicer when we
have different query re-writing options that can use more information
about the query results.
Bug: 153387066
Bug: 140759491
Test: existing tests pass
Change-Id: I2ec967c763d33d7a3ff02c1a13c6953b460d1e5f
M room/compiler/src/main/kotlin/androidx/room/log/RLog.kt
M room/compiler/src/main/kotlin/androidx/room/processor/QueryMethodProcessor.kt
M room/compiler/src/main/kotlin/androidx/room/solver/TypeAdapterStore.kt
M room/compiler/src/main/kotlin/androidx/room/solver/query/result/PojoRowAdapter.kt
ap...@google.com
Branch: androidx-main
commit 803a2a7da2b86cf4ac9930a897ec62d9a73b1fda
Author: stevebower <stevebower@google.com>
Date: Thu Dec 01 13:37:43 2022
Remove withFrameNanos workaround now that
Bug: 259134313
Test: ./gradlew :wear:compose:compose-material:connectedCheck --info --daemon
Change-Id: I74a9f3fd67935f468411af75d7d7cf33267f9b5a
M wear/compose/compose-material/src/commonMain/kotlin/androidx/wear/compose/material/ScalingLazyColumn.kt
ba...@gmail.com
Is there a workaround? Currently we use the following.
val scope = rememberCoroutineScope {
// ui test broke without this.
Dispatchers.Main.immediate
}
Otherwise some navigateToXXX callbacks are invoked on a Room dispatcher. Which breaks the NavGraph.
da...@google.com
My tests are not doing their job of catching bugs due to this issue.
It's pretty bad for the test environment to have different behavior to production. It leads to bugs and makes it so that we can't verify behavior in tests properly.
je...@google.com
lp...@google.com
I ran into this in
We actually have existing tests that should catch this category of issue, essentially the problem looks like:
scope.launch { }
...some other method calls
scope.cancel()
Normally the cancel will happen before the launch, so the block will never start executing, but in tests because it is unconfined this was accidentally passing as the launch always started first. Manually adding a yield() inside the launch makes the test start to fail, although that is still slightly different as normally we wouldn't even get to the point where the launch {} takes effect and invokes the block.
is...@gmail.com
I see this issue has had some recent movement with a pending PR for adding the ability to set the dispatcher responsible for coroutines related to composition to the StandardTestDispatcher. I have ported these changes over to a project I'm working on and have seen a significant increase in the stability of my team's end-to-end tests that leverage the Compose Testing APIs. Previously, we were encountering issues that were only "solved" by passing in Dispatchers.Main in our app code for the majority of our utilizations of rememberCoroutineScope and LaunchedEffect. Are the changes in the PR associated with this issue being prioritized, and when can we expect them to move through?
Description
Currently Compose UI tests use an
LaunchedEffect,rememberComposeScope, and even the coroutine running theRecomposeritself).This is inconsistent with how coroutines are dispatched in non-test environments, where we use the main immediate dispatcher. It is also dangerous because unconfined dispatchers can change the order that code will run in sneaky ways.