I scheduled a task but it doesn't invoke given callback like following code
public function registerSchedule($scheduler) {
\Log::debug('Scheduling task');
$scheduler->call(function(){
\Log::debug('i\'m inside');
})->everyMinute();
}
with above code it will always log "Scheduling task" but not "i'm inside" not sure why it isn't triggering callback function. There is no error thrown in logs. Can anyone please tell me in what cases this might happen? is it possible that other plugins are creating issues for callback?
So far i tried to debug and I saw that Schedule.php of laravel framework has a protected property called events where this callback gets stored but when dueEvents is called events property is empty. So, completely confused on what's happening here.
any help is appreciated. thank you :)
Related
I have some basic code like this:
this.events$
.pipe(
observeOn(asyncScheduler),
...
).subscribe(anotherObservable$);
This works fine in my app, but I am having a funny issue with a unit test. I put a couple of debug consoles like this:
this.events$
.pipe()
.subscribe(console.log.bind(null, 'sanity check inside without async'));
this.events$
.pipe(observeOn(asyncScheduler))
.subscribe(console.log.bind(null, 'sanity check inside with async'));
If I do from(events).subscribe(events$); in my test, the "without async" log fires.
If I do scheduled(events, asyncScheduler).subscribe(events$);, nothing fires.
I can't seem to fake the input to get my pipe on the async scheduler to fire. My test just needs that pipe to fire to see that something was called.
Realized right after posting:
scheduled(events, asyncScheduler).subscribe(events$);
await lastValueFrom(events$)
I have an async ngxs action that throwsError().
I would like the default error handling mechanism to ignore this thrown error because I will be handling it in my code via ofActionErrored(). However, for other actions, default error handling should still take place.
Right now, both the ofActionErrored() and default error handling (via Angular/Ionic) tries to deal with the error.
The alternative I can think of is to dispatch Xxx_SUCCESS and Xxx_ERROR actions from within the initially dispatched action, something I would like to avoid if i can help it.
Advice appreciated.
There is a feature request that raised a similar concern at the NGXS repo. We've discussed in the core team meeting and we'll focus that for the next release. You can provide your feedback there: https://github.com/ngxs/store/issues/1691
You can use ofActionCompleted which as a result can provide the error, if there is one. An example taken from the code I am working on:
this.actions$.pipe(
ofActionCompleted(GetMe)
).subscribe((data) => {
const errorStatus = data.result.error['status'];
if (!data.result.successful && errorStatus === 403) {
this.snackbar.openFromComponent(TranslateSnakeBarComponent, {
data: {message: 'USER_DISABLED'}
});
}
});
I'm actually on swift 2.3.
Inbound Call works great with CallKit. But OutGoing Call ....
I saw the SpeakerBox project, I do the same things.
But it doesn't work.
To start my call, I used
let handle = CXHandle(type: .PhoneNumber, value: "TOTO")
let startCallAction = CXStartCallAction(callUUID: uuid, handle: handle)
startCallAction.video = video
let transaction = CXTransaction()
transaction.addAction(startCallAction)
requestTransaction(transaction)
After, in SpeakerBox Project, this function is called :
func provider(provider: CXProvider, perform action: CXStartCallAction)
But not in my project. Then, when i hangup, i see : "Call failed".
Do you have an idea ?
Be sure you are configuring your CXProvider and setting its delegate properly. If you do not set the CXProvider's delegate property, the delegate will not receive any actions to perform.
Also, if you see a "Call Failed" UI, this may indicate your app is crashing. I'd check for crash logs or run the app in the debugger.
As far as I can see, SpeakerBox demo does not perform the following provider method:
https://developer.apple.com/documentation/callkit/cxprovider/1930701-reportcall
func reportCall(with UUID: UUID,
endedAt dateEnded: Date?,
reason endedReason: CXCallEndedReason)
- (void)reportCallWithUUID:(NSUUID *)UUID endedAtDate:(nullable NSDate
*)dateEnded reason:(CXCallEndedReason)endedReason;
Which leads to the "Call failed" UI screen being displayed - as CallKit was not given a reason why the call has ended, and it seems that "
CXCallEndedReasonFailed" is assumed by default.
Call "reportCall endedAt" before requesting the CXEndCallAction transaction to remove "Call failed" screen.
Have you added the required permissions to your info.plist?
I am using Bitrise to run some Android espresso UI tests, but I cant seem to find a solution for this Perform Exception:
android.support.test.espresso.PerformException: Error performing 'single click' on view 'with id: com.selfcarecatalyst.healthstorylines.adda:id/male'.
at android.support.test.espresso.PerformException$Builder.build(PerformException.java:83)
Im testing a sign up page that has a few fields. If i skip clicking one field, I get the same error on the next click on this form. The relevant code is:
public void clickMale_onInfoPage(){
onView(withId(R.id.male)).perform(click());
}
public void setFirstName_onInfoPage(String name){
onView(withId(R.id.first_name)).perform(typeText(name));
closeSoftKeyboard();
}
setName is called first, and i added a softclosekeyboard thinking this would solve it but it did not :(
This is running through a CI, and sorry but Im a little new and not sure how to get a better error message/stacktrace. Any help would be much appreciated!
You should also try to call closeSoftKeyboard() before performing the click action.
This question already has answers here:
Am I right to ignore the compiler warning for lacking await for this async call?
(3 answers)
Closed 7 years ago.
Below is my code. Compiler gives warning because AddLog is not awaited. I do not want to await this call and want to continue executing next lines. I dont have any concern if the exception is consumed also. Is it fine to ignore the warning?
public async Task Add()
{
this.AddLog( "Add executing" );
// Logic to Add Customer
}
public async Task AddLog( string message )
{
// Write to DB
}
Assuming you truly want to call the AddLog method in a fire-and-forget way, then you have a few options.
If, by design, you want AddLog to always be invoked as a fire-and-forget method, then you could change the signature to not return a Task.
public async void AddLog( string message ) // change Task to void
{
// Write to DB
// WARNING: Make sure that exceptions are handled in here.
}
However, if you do this, you better make sure that exceptions are properly handled from within the AddLog method. If any exception goes unhandled, it will crash your process.
Another option is to change the way you invoke AddLog to clearly state your intent that you don't care about when the Task completes, or about any exceptions that may be raised. You can do this by defining an empty continuation (Well, almost empty. See my edit at the bottom of the post for why it's a good idea to read the Task.Exception property at the very least).
// see EDIT for why the Task.Exception property is read here.
this.AddLog("Add executing").ContinueWith(t => { var observed = t.Exception; });
With either option, unless you are awaiting on other code inside your Add method that you are not showing us, then there is no longer any point in defining your Add method as async. You can simply turn it into a regular synchronous method. Otherwise, you'll then get another warning telling you that This async method lacks 'await' operators and will run synchronously....
public void Add() // no need for "async Task"
{
// see EDIT for why the Task.Exception property is read here.
this.AddLog("Add executing").ContinueWith(t => { var observed = t.Exception; });
// Logic to Add Customer
}
In any case, I wouldn't simply ignore the warning. Much like sometimes we get the warning Use of unassigned local variable 'x' in cases where we know that our code is fine, we typically don't ignore the warning. Instead, we may explicitly initialize the variable to null just to make our intent clear, and make the warning go away. Similarly, you can make the warning go away by making your intentions more explicit to the compiler using one of the above options.
EDIT: Word of caution about unobserved exceptions
I should also mention that even with the ContinueWith option, you may have to be careful about unhandled exceptions that come from your AddLog method.
According to this article, the way unobserved exceptions from tasks are handled has changed between .NET 4.0 and .NET 4.5. So, if you are still running .NET 4.0, or if you forcing .NET 4.0 exception behavior via configuration, you run the risk that unhandled exceptions will crash your process whenever the task gets GC-collected and finalized.
To make sure that this is not a problem, you can adjust the continuation to explicitly observe the exception, if any is present. You don't actually need to do anything with it, you just need to read it. This is one way to do it safely:
this.AddLog("Add executing").ContinueWith(t => { var observed = t.Exception; });
I've updated my earlier examples above to use the safer version of the continuation.
I would make add() non async since it isn't...and then task.run on add log