How to know if a Worker has failed being triggered/executed by the queue?
I am appending workers in the queue as shown below. However, occasionally a worker won't be triggered. How can I know if a Worker did not get executed so that I can try to re-enqueue it? Maybe using the Operation instance returned by enqueue()? How to use it? If so, is it possible to have a hint of the reason of failure of triggering the Worker?
Note that I do not need to know if the Worker failed (return Result.FAILURE). The case I want to cover is when the Worker is not even called, which happens occasionally.
OneTimeWorkRequest sendMessageWorker = new OneTimeWorkRequest.Builder(SendMessageWorker.class)
.setInputData(data)
.setBackoffCriteria(BackoffPolicy.LINEAR, backOffDelayInMillis, TimeUnit.MILLISECONDS)
.build();
Operation operation = WorkManager.getInstance()
.beginUniqueWork(SendMessageWorker.class.getSimpleName(), ExistingWorkPolicy.APPEND, sendMessageWorker)
.enqueue();
android android-workmanager android-architecture-workmanager asked Nov 14 '18 at 20:49
user2923322user2923322
13018
add a comment |
I am appending workers in the queue as shown below. However, occasionally a worker won't be triggered. How can I know if a Worker did not get executed so that I can try to re-enqueue it? Maybe using the Operation instance returned by enqueue()? How to use it? If so, is it possible to have a hint of the reason of failure of triggering the Worker?
Note that I do not need to know if the Worker failed (return Result.FAILURE). The case I want to cover is when the Worker is not even called, which happens occasionally.
OneTimeWorkRequest sendMessageWorker = new OneTimeWorkRequest.Builder(SendMessageWorker.class)
.setInputData(data)
.setBackoffCriteria(BackoffPolicy.LINEAR, backOffDelayInMillis, TimeUnit.MILLISECONDS)
.build();
Operation operation = WorkManager.getInstance()
.beginUniqueWork(SendMessageWorker.class.getSimpleName(), ExistingWorkPolicy.APPEND, sendMessageWorker)
.enqueue();
asked Nov 14 '18 at 20:49
user2923322user2923322
13018
add a comment |
I am appending workers in the queue as shown below. However, occasionally a worker won't be triggered. How can I know if a Worker did not get executed so that I can try to re-enqueue it? Maybe using the Operation instance returned by enqueue()? How to use it? If so, is it possible to have a hint of the reason of failure of triggering the Worker?
Note that I do not need to know if the Worker failed (return Result.FAILURE). The case I want to cover is when the Worker is not even called, which happens occasionally.
OneTimeWorkRequest sendMessageWorker = new OneTimeWorkRequest.Builder(SendMessageWorker.class)
.setInputData(data)
.setBackoffCriteria(BackoffPolicy.LINEAR, backOffDelayInMillis, TimeUnit.MILLISECONDS)
.build();
Operation operation = WorkManager.getInstance()
.beginUniqueWork(SendMessageWorker.class.getSimpleName(), ExistingWorkPolicy.APPEND, sendMessageWorker)
.enqueue();
asked Nov 14 '18 at 20:49
user2923322user2923322
13018
I am appending workers in the queue as shown below. However, occasionally a worker won't be triggered. How can I know if a Worker did not get executed so that I can try to re-enqueue it? Maybe using the Operation instance returned by enqueue()? How to use it? If so, is it possible to have a hint of the reason of failure of triggering the Worker?
Note that I do not need to know if the Worker failed (return Result.FAILURE). The case I want to cover is when the Worker is not even called, which happens occasionally.
OneTimeWorkRequest sendMessageWorker = new OneTimeWorkRequest.Builder(SendMessageWorker.class)
.setInputData(data)
.setBackoffCriteria(BackoffPolicy.LINEAR, backOffDelayInMillis, TimeUnit.MILLISECONDS)
.build();
Operation operation = WorkManager.getInstance()
.beginUniqueWork(SendMessageWorker.class.getSimpleName(), ExistingWorkPolicy.APPEND, sendMessageWorker)
.enqueue();
asked Nov 14 '18 at 20:49
user2923322user2923322
13018
asked Nov 14 '18 at 20:49
user2923322user2923322
13018
edited Nov 14 '18 at 21:00
user2923322
asked Nov 14 '18 at 20:49
user2923322user2923322
13018
asked Nov 14 '18 at 20:49
user2923322user2923322
13018
asked Nov 14 '18 at 20:49
user2923322user2923322
13018
13018
add a comment |
add a comment |
2 Answers
2
active
oldest
votes
Using ExistingWorkPolicy.APPEND, you´re creating a chain of work.
If you return Result.FAILURE in your Worker (in case of an error), all the chain of Work is cancelled. This maybe the reason why you don´t see your worker running sometimes.
One suggestion is to add a Tag or an Id to your worker and observe the status using a Livedata and the getStatusesByTagLivedata() or getStatusesById().
You can take a look at this talk presented at the Android Developer Summit that covers this and other example.
answered Nov 15 '18 at 5:13
pfmaggipfmaggi
2,0001225
I am sure it is not because of Result.FAILURE, because before returning such a result, I have error logging. Also all the logic of my worker is wrapped by a try/catch and if any error occurs I log and I can always see any error. It really seems that the worker, occasionally, is just not triggered at all by the queue (about 1 time on 100 times). I will watch the talk today! Thank you for the video
– user2923322
Nov 15 '18 at 9:01
add a comment |
You can observe the Worker and get the state of worker by observing using method getStatusByIdLiveData
mWorkManager.getStatusByIdLiveData(yourWorkRequest.id)
.observe(lifeCycleOwner, Observer { workStatus ->
//here you can get the status of work
})
answered Nov 16 '18 at 4:03
VishalVishal
406210
add a comment |
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53308498%2fhow-to-know-if-a-worker-has-failed-being-triggered-executed-by-the-queue%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
Using ExistingWorkPolicy.APPEND, you´re creating a chain of work.
If you return Result.FAILURE in your Worker (in case of an error), all the chain of Work is cancelled. This maybe the reason why you don´t see your worker running sometimes.
One suggestion is to add a Tag or an Id to your worker and observe the status using a Livedata and the getStatusesByTagLivedata() or getStatusesById().
You can take a look at this talk presented at the Android Developer Summit that covers this and other example.
answered Nov 15 '18 at 5:13
pfmaggipfmaggi
2,0001225
I am sure it is not because of Result.FAILURE, because before returning such a result, I have error logging. Also all the logic of my worker is wrapped by a try/catch and if any error occurs I log and I can always see any error. It really seems that the worker, occasionally, is just not triggered at all by the queue (about 1 time on 100 times). I will watch the talk today! Thank you for the video
– user2923322
Nov 15 '18 at 9:01
add a comment |
Using ExistingWorkPolicy.APPEND, you´re creating a chain of work.
If you return Result.FAILURE in your Worker (in case of an error), all the chain of Work is cancelled. This maybe the reason why you don´t see your worker running sometimes.
One suggestion is to add a Tag or an Id to your worker and observe the status using a Livedata and the getStatusesByTagLivedata() or getStatusesById().
You can take a look at this talk presented at the Android Developer Summit that covers this and other example.
answered Nov 15 '18 at 5:13
pfmaggipfmaggi
2,0001225
I am sure it is not because of Result.FAILURE, because before returning such a result, I have error logging. Also all the logic of my worker is wrapped by a try/catch and if any error occurs I log and I can always see any error. It really seems that the worker, occasionally, is just not triggered at all by the queue (about 1 time on 100 times). I will watch the talk today! Thank you for the video
– user2923322
Nov 15 '18 at 9:01
add a comment |
Using ExistingWorkPolicy.APPEND, you´re creating a chain of work.
If you return Result.FAILURE in your Worker (in case of an error), all the chain of Work is cancelled. This maybe the reason why you don´t see your worker running sometimes.
One suggestion is to add a Tag or an Id to your worker and observe the status using a Livedata and the getStatusesByTagLivedata() or getStatusesById().
You can take a look at this talk presented at the Android Developer Summit that covers this and other example.
answered Nov 15 '18 at 5:13
pfmaggipfmaggi
2,0001225
Using ExistingWorkPolicy.APPEND, you´re creating a chain of work.
If you return Result.FAILURE in your Worker (in case of an error), all the chain of Work is cancelled. This maybe the reason why you don´t see your worker running sometimes.
One suggestion is to add a Tag or an Id to your worker and observe the status using a Livedata and the getStatusesByTagLivedata() or getStatusesById().
You can take a look at this talk presented at the Android Developer Summit that covers this and other example.
answered Nov 15 '18 at 5:13
pfmaggipfmaggi
2,0001225
answered Nov 15 '18 at 5:13
pfmaggipfmaggi
2,0001225
answered Nov 15 '18 at 5:13
pfmaggipfmaggi
2,0001225
answered Nov 15 '18 at 5:13
pfmaggipfmaggi
2,0001225
2,0001225
I am sure it is not because of Result.FAILURE, because before returning such a result, I have error logging. Also all the logic of my worker is wrapped by a try/catch and if any error occurs I log and I can always see any error. It really seems that the worker, occasionally, is just not triggered at all by the queue (about 1 time on 100 times). I will watch the talk today! Thank you for the video
– user2923322
Nov 15 '18 at 9:01
add a comment |
I am sure it is not because of Result.FAILURE, because before returning such a result, I have error logging. Also all the logic of my worker is wrapped by a try/catch and if any error occurs I log and I can always see any error. It really seems that the worker, occasionally, is just not triggered at all by the queue (about 1 time on 100 times). I will watch the talk today! Thank you for the video
– user2923322
Nov 15 '18 at 9:01
I am sure it is not because of Result.FAILURE, because before returning such a result, I have error logging. Also all the logic of my worker is wrapped by a try/catch and if any error occurs I log and I can always see any error. It really seems that the worker, occasionally, is just not triggered at all by the queue (about 1 time on 100 times). I will watch the talk today! Thank you for the video
– user2923322
Nov 15 '18 at 9:01
I am sure it is not because of Result.FAILURE, because before returning such a result, I have error logging. Also all the logic of my worker is wrapped by a try/catch and if any error occurs I log and I can always see any error. It really seems that the worker, occasionally, is just not triggered at all by the queue (about 1 time on 100 times). I will watch the talk today! Thank you for the video
– user2923322
Nov 15 '18 at 9:01
add a comment |
You can observe the Worker and get the state of worker by observing using method getStatusByIdLiveData
mWorkManager.getStatusByIdLiveData(yourWorkRequest.id)
.observe(lifeCycleOwner, Observer { workStatus ->
//here you can get the status of work
})
answered Nov 16 '18 at 4:03
VishalVishal
406210
add a comment |
You can observe the Worker and get the state of worker by observing using method getStatusByIdLiveData
mWorkManager.getStatusByIdLiveData(yourWorkRequest.id)
.observe(lifeCycleOwner, Observer { workStatus ->
//here you can get the status of work
})
answered Nov 16 '18 at 4:03
VishalVishal
406210
add a comment |
You can observe the Worker and get the state of worker by observing using method getStatusByIdLiveData
mWorkManager.getStatusByIdLiveData(yourWorkRequest.id)
.observe(lifeCycleOwner, Observer { workStatus ->
//here you can get the status of work
})
answered Nov 16 '18 at 4:03
VishalVishal
406210
You can observe the Worker and get the state of worker by observing using method getStatusByIdLiveData
mWorkManager.getStatusByIdLiveData(yourWorkRequest.id)
.observe(lifeCycleOwner, Observer { workStatus ->
//here you can get the status of work
})
answered Nov 16 '18 at 4:03
VishalVishal
406210
edited Nov 16 '18 at 4:31
answered Nov 16 '18 at 4:03
VishalVishal
406210
answered Nov 16 '18 at 4:03
VishalVishal
406210
answered Nov 16 '18 at 4:03
VishalVishal
406210
406210
add a comment |
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53308498%2fhow-to-know-if-a-worker-has-failed-being-triggered-executed-by-the-queue%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
