I have a hot-reloading plugin based on Triggered Execution.
I updated to version 1.5.0 and i can't detect when watching mode is stopped.
This log is what i got "[info] Received input event: CancelWatch."
Have you any idea how detect when triggered execution is stopped?
Thanks!
Related
I have a repeated task that runs every 15 minutes.
#app.on_event("startup")
#repeat_every(seconds=60 * 15, wait_first=True)
def myFunction(db=SessionLocal()) -> None:
test(db=db, for_test=False)
It works pretty normal at the beginning. But after some time (Like 5-6 hours) It stops working and never repeats task again. When I check logs in Cloud Run, I see this message;
RuntimeError: coroutine ignored GeneratorExit
Also such logs;
2022-09-29 10:04:04.263 EETTask was destroyed but it is pending!
2022-09-29 10:04:04.263 EETtask: <Task pending name='Task-850' coro=<H2Protocol.send_task() running at /usr/local/lib/python3.9/site-packages/hypercorn/protocol/h2.py:148> wait_for=<Future cancelled> cb=[_gather.<locals>._done_callback() at /usr/local/lib/python3.9/asyncio/tasks.py:767]>
I have to deploy a new revision to make repeated tasks work again. I'd like to know what to do in this situation and why this error occurs. It seems like there is no such problem in localhost.
Should I use Google Scheduler instead of FastApi utils' repeated tasks?
The problem was occuring because of my startup script.
I haven't noticed but i was using --reload tag in production. I can't believe this.
After I edited my startup script for production, everything worked fine.
We are using MongoDB Realm in our app.
The first time the user is connected to the app, the ProgressNotifcation callback is triggered correctly, and it will work and trigger whenever a new download is coming.
Even if no download is pending, the ProgressNotification callback will be triggered (the Progress object pass in the callback will contain values from the last download) at least once(when creating it). I supposed this is due to the fact that we are downloading the first data set of the user.
But after killing the app and launching it again, the ProgressNotification callback is not triggered anymore until new data are received by the app. And from this point, the callback will be called every time we need it.
It seems that now, the framework needs a first download since the app is launch to make ProgressNotification callback to be triggered every time we need it.
This was working in the previous version of Realm (5.X.X). We just finished the migration to Realm 10 and discover this issue.
I am a bit stuck here, do not know if this is an intended change or a bug on my part. But I am pretty sure this was working in the previous version of the SDK.
Can anyone help me with this? Thanks
Note: this is no more working in both mode : .forCurrentlyOutstandingWork and .reportIndefinitely
Example
self.token = syncSession.addProgressNotification(for: .download, mode: .forCurrentlyOutstandingWork) { progress in
.......Some code........ <- this part of the code is not triggered anymore
}
EDIT - 21/12/2020
For clarification, the token returned contains a value and the .invalidate is not being called.
There is no error in the session and any new download is triggering the callback. After an initial download, everything works as expected. This means that when I add a progressNotifcation later on, the callback is triggered immediately with the progress of the previous download. But if there is not an initial download, the callback is never called.
For the scope, this method is actually in the custom publisher that I created and it is not deallocated.
Realm 10.5.0
iOS 14.3
I am working an app on android tv.
We are discussing about the reason why activity go onPause when Google Assistant is active.
We found this problem happened suddenly in one day.
After tracing this problem for many days, we found that Assistant page cover on our app as a activity.
That's the reason why my app go onPause.
But I want to know the reason why it could suddenly become an activity.
Here is my observation of activity.
I use "adb shell dumpsys activity" to check activity status.
Without going to onPause situation
Running activities (most recent first):
Run #0: ActivityRecord{2d9fe0 u0 com.google.android.katniss/com.google.android.apps.tvsearch.app.launch.trampoline.SearchActivityTrampoline t12 f}
Running activities (most recent first):
Run #0: ActivityRecord{32ee7d7 u0 com.sv.n973796_home/.atv.ui.HomeActivity t5}
Running activities (most recent first):
Run #0: ActivityRecord{f0c9842 u0 com.sv.n973796_home/.LauncherMainActivity t3}
Going to onPause situation
Running activities (most recent first):
Run #0: ActivityRecord{bdce69a u0 com.google.android.katniss/com.google.android.apps.tvsearch.results.activity.SearchResultActivity t825}
Running activities (most recent first):
Run #2: ActivityRecord{87c5fd1 u0 com.sv.n973796_home/.common.ui.HomeActivity t817}
Run #1: ActivityRecord{28d1d6c u0 com.sv.n973796_home/.LauncherMainActivity t817}
My questions here:
Is there any document about this changing?(between "com.google.android.apps.tvsearch.app.launch.trampoline.SearchActivityTrampoline" and "com.google.android.apps.tvsearch.results.activity.SearchResultActivity")
Does this problem relate to my SDK version?(sdk version in gradle or SDK manager?)
Is there any way to check the version of com.google.android.katniss? and could I choose it?
There is no specific documentation about this changing. It's due to a change with how ATV Assistant is implemented.
No. It is entirely based on which version of ATV Assistant is on the device.
You can manually check the ATV Assistant version in system settings (Apps -> All Apps -> Show system apps, Google). You may be able to programmatically determine the version on the device by checking package manager (I don't recall if that requires a permission), but you don't want to do that. You can't guarantee that the behavior will be the same in different versions and updates are being regularly released.
I'd ask what specific issue you have with onPause being triggered (or not triggered) and start from there because ATV Assistant isn't the only reason that onPause could be called. For example, if your app handles video playback you would want to stop the player in onPause() in Android 6.0 and earlier and then in onResume() you would check if it was playing when onPause() was invoked and trigger playback again if it was. You shouldn't care about whether onPause() was invoked due to the Assistant coming to the foreground or the OS displaying an alert dialog. In versions of Android after that, you can simply have that logic in onStop/onStart, since the onStop() lifecycle method is guaranteed to be called quickly when the activity is no longer visible.
I am trying to use the RemotePlaybackClient to resume a Chromecast session created by the same Android app. I'm able to use this RPC vs the full Cast SDK to play, pause, resume, seek, and stop playback on the Chromecast device. My current test is in closing the Android app and using the sessionId from the session to try to reload the app and resume control of the playback. Upon closing the Android app, we are not terminating playback or the session, it keeps going.
Here is the code I'm using:
// attempt resume
mRemotePlaybackClient = new RemotePlaybackClient(getApplicationContext(), ccRoute);
// ccRoute is the selected ChromeCast RouteInfo device - same as previous
System.out.println(mRemotePlaybackClient.isSessionManagementSupported()); // true
System.out.println(mRemotePlaybackClient.hasSession()); // false
mRemotePlaybackClient.setSessionId(saved_sessionId); // saved_sessionId is the sessionId saved from the mRemotePlaybackClient.play command in success reply.
System.out.println(mRemotePlaybackClient.hasSession()); // true
mRemotePlaybackClient.startSession(null, ccStart); // callback returns error 0
mRemotePlaybackClient.setStatusCallback(ccSessionStatus); // callback returns error 0
I've asked some others familiar with the RemotePlaybackClient and the Chromecast, including those within Google but did not get an answer. Also, I seem to be seeing some of the same issues #Commonsware is seeing in that some callbacks don't reply at all. In addition, with images, metadata is not returned and the status callback returns an error whereas video returns ok (position info etc).
Really, I'd just like to resume the session for now vs having to wire up the full Cast SDK.
Is there a way to automatically retry Fileupload.upload() opertaion if it fails with IO_Error?
I tried calling upload() again (and it did reach all the way to the web-service)
==> but it did NOT trigger DataEvent.UPLOAD_COMPLETE_DATA when the Retry was completed (i checked with a sniffer that the retry operation did finish successfully)
Thanks for any ideas.