Fixed
Status Update
Comments
su...@google.com <su...@google.com> #2
Project: platform/frameworks/support
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
https://android-review.googlesource.com/1123258
https://goto.google.com/android-sha1/b90079595f33f58fece04026a97faa0d243acdb1
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
al...@gmail.com <al...@gmail.com> #3
al...@gmail.com <al...@gmail.com> #4
Project: platform/frameworks/support
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 ( b/140759491 ).
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
https://android-review.googlesource.com/1288456
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
be...@gmail.com <be...@gmail.com> #6
Same issue here!
The worst thing for me, beyond the crash itself, is that after it happens, there is NO WAY to recover. I removed most of the WorkManager code, but it keeps crashing (since tries to do the jobs, which it can't, on every start).
The worst thing for me, beyond the crash itself, is that after it happens, there is NO WAY to recover. I removed most of the WorkManager code, but it keeps crashing (since tries to do the jobs, which it can't, on every start).
al...@gmail.com <al...@gmail.com> #7
Yeah, you have to clear app data or disable the content provider in your manifest.
be...@gmail.com <be...@gmail.com> #8
I also just filed this: https://issuetracker.google.com/79950952
Either WorkManager is too smart, or there is something wrong. I want to removeAll workers on my onCreate, and re-schedule myself everything later.
By cancelling-enqueuing I got into this snowball that ended with more than 100 jobs.
Either WorkManager is too smart, or there is something wrong. I want to removeAll workers on my onCreate, and re-schedule myself everything later.
By cancelling-enqueuing I got into this snowball that ended with more than 100 jobs.
ti...@gmail.com <ti...@gmail.com> #9
Sorry folks. This is a bug in alpha01. The fix should be a part of alpha02. Hang tight.
ra...@google.com <ra...@google.com>
al...@gmail.com <al...@gmail.com> #10
Do you know when the fix will be available?
su...@google.com <su...@google.com> #11
We're aiming for later this week.
al...@gmail.com <al...@gmail.com> #12
Awesome, I'll get to merge my branch! 😉
ya...@gmail.com <ya...@gmail.com> #13
Hi, may I know,
1) After the end of execution of OneTimeWorkRequest typed worker's doWork(), do we need to cancelAllWorkByTag explicitly to perform "clean up"?
2) After this bug fixed, is there still any hard limit, only how many active job (with different tags) we can schedule on WorkManager?
Thanks.
1) After the end of execution of OneTimeWorkRequest typed worker's doWork(), do we need to cancelAllWorkByTag explicitly to perform "clean up"?
2) After this bug fixed, is there still any hard limit, only how many active job (with different tags) we can schedule on WorkManager?
Thanks.
al...@gmail.com <al...@gmail.com> #14
No, you don't need to perform cleanup and no, there aren't any limits.
su...@google.com <su...@google.com> #15
1. You don't need to perform any cleanup. Completed OneTimeWorkRequests will not re-execute,
2. There is no limit on the number of jobs you can schedule; however, at most 100 will be sent to JobScheduler at a time. The rest will be queued up and sent when appropriate. (That being said, I would advise that you probably don't want to have hundreds of potentially active jobs at any one time.)
2. There is no limit on the number of jobs you can schedule; however, at most 100 will be sent to JobScheduler at a time. The rest will be queued up and sent when appropriate. (That being said, I would advise that you probably don't want to have hundreds of potentially active jobs at any one time.)
ni...@gmail.com <ni...@gmail.com> #16
I still have this issue with 1.0.0-alpha02, like others it seems ( https://github.com/googlecodelabs/android-workmanager/issues/16 ).
As seen on the link, every time I restart my app (using ADB Idea plugin, that kill it then start it again), the numbers of tasks scheduled in JobScheduler increments by the number of periodic tasks scheduled.
I have 4 users that went into the issue and I will use a workaround code I wrote for now.
I see it on Samsung 7.0 devices for now.
As seen on the link, every time I restart my app (using ADB Idea plugin, that kill it then start it again), the numbers of tasks scheduled in JobScheduler increments by the number of periodic tasks scheduled.
I have 4 users that went into the issue and I will use a workaround code I wrote for now.
I see it on Samsung 7.0 devices for now.
ni...@gmail.com <ni...@gmail.com> #17
Here's a sample project that reproduces the issue. I use ADB Idea Plugin with the "ADB Restart App" feature to triggers the issue.
You will see that with each restart, the jobcount from JobScheduler increases by 5, but not the one from WorkManager.
I hope someone will see this message, if I need to make another issue please tell me.
You will see that with each restart, the jobcount from JobScheduler increases by 5, but not the one from WorkManager.
I hope someone will see this message, if I need to make another issue please tell me.
al...@gmail.com <al...@gmail.com> #18
If your issue is specific to periodic work, I'd file a new issue since this one is a little different.
Description
Version used: alpha01
Devices/Android versions reproduced on: >= API 23
There are a few issues here. First of all anytime a job finishes, all jobs that aren't already running are rescheduled. Then, each job generates a new ID which creates an exponential number of jobs for the system or Play Services to manage. Instead, a job should get its ID from the unique job tag or something like that.