Background task not cancelling when requested by system

[tcldr]

Describe the bug
As mentioned on our call, here's the warning that I'm regularly getting from the system.

[BackgroundTask] Background task still not ended after expiration handlers were called: <_UIBackgroundTaskInfo: 0x2835fdd40>: taskID = 4, taskName = Called by <AppName>, from $s7Segment0A11DestinationC14UploadTaskInfoV3url4taskAE10Foundation3URLV_So016NSURLSessionDataD0CtcfC, creationTime = 1095354 (elapsed = 27). This app will likely be terminated by the system. Call UIApplication.endBackgroundTask(_:) to avoid this.

I assume this means the app will have to launch cold each time this occurs.

To Reproduce
It seems to happen intermittently.

I believe it usually occurs if I run a build on device, and that put aside the phone with the debugger still running. That message appeared almost 12 mins after the app was launched via a build and run in Xcode.

As mentioned, my current network is a little flakey so it could be related to a low/no network situation, too.

Expected behavior
A clear and concise description of what you expected to happen.

Screenshots
If applicable, add screenshots to help explain your problem.

Platform (please complete the following information):

• Library Version in use: [e.g. 0.0.5]
• Platform being tested: [e.g. iOS]
• Integrations in use: [e.g. Firebase, Amplitude]

Additional context
Add any other context about the problem here.

[bsneed]

Hi @tcldr; I think maybe this could be because the debugger is attached. Is it possible for you to verify? Please reopen this issue if that's not the case.

[Nickforall]

@bsneed Just a heads up that this occurs on a release build without a debugger attached as well. Which results in a state change (app gets killed)

My testflight users are seeing the same behavior

12061	error	01:27:21.951967+0100	dew	Background task still not ended after expiration handlers were called: <private>. This app will likely be terminated by the system. Call UIApplication.endBackgroundTask(_:) to avoid this.
12061	default	01:27:21.972481+0100	dew	Received state update for 12061

[JetForMe]

I see this, too.

[bsneed]

Gonna spend some time today looking into this further. Thanks for the reports!

[bsneed]

I have narrowed it down to the cause. Inside of flush(), we plow through any pending files that need to be sent off and there's no notion of a timeout, which there should be. If there's lots of them, we won't be able to get through them in the time allotted of course. Trying to figure out the best way to correct this.

[bsneed]

@JetForMe @Nickforall are either of you setting flushInterval or flushCount properties to something other than the defaults?

I do see we've set up background tasks, and a completion handler where we call endBackgroundTask. I'm wondering if we're loading up so much network activity that going to suspend all those upload tasks is taking too long.

[Nickforall]

FlushInterval was set to 10, I think i copied this from the example in the docs.

…

On Mon, 24 Jan 2022 at 19:05, Brandon Sneed ***@***.***> wrote: @JetForMe <https://github.com/JetForMe> @Nickforall <https://github.com/Nickforall> are either of you setting flushInterval or flushCount properties to something other than the defaults? I do see we've set up background tasks, and a completion handler where we call endBackgroundTask. I'm wondering if we're loading up so much network activity that going to suspend all those upload tasks is taking too long. — Reply to this email directly, view it on GitHub <#54 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABGBWMWOP6VPCOXZAPWXLZTUXWIIDANCNFSM5C5D2VVQ> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[bsneed]

Thanks @Nickforall ! I think I've got it fixed in the PR above. At least I couldn't reproduce it anymore. Please feel free to have a look if you're so inclined.

[bsneed]

@tcldr see above^. thanks for the original report!