Feature request: Ability to stop or cancel duration signals without sending

[markbattistella]

Currently TelemetryDeck provides startDurationSignal and stopAndSendDurationSignal. This works for normal flows.

In some apps, users can allow users to control whether telemetry is used or not. So while a duration signal is active. Example:

1. User starts onboarding, setting startDurationSignal("onboarding").
2. User disables telemetry in settings.
3. User finishes onboarding, triggering stopAndSendDurationSignal("onboarding").

At this point, the the setting for using telemetry prevents the stop from sending, because telemetry is disabled.

But since the SDK doesn’t expose a "stop without send", the underlying DurationSignalTracker still holds an open timer. This leaves the SDK with dangling signals and no way to clean them up.

What would be good is a method such as:

@MainActor
public static func stopDurationSignal(_ signalName: String)

// or

@MainActor
public static func cancelDurationSignal(_ signalName: String)

This would:

• Call DurationSignalTracker.shared.stopTracking(signalName)
• Drop the duration data silently (no internalSignal call).

Benefit

• Keeps SDK state consistent when signals should not be sent.
• Matches use cases where telemetry can be turned off mid-session.
• No risk of sending data against user intent.

Possible implementation

@MainActor
public static func stopDurationSignal(_ signalName: String) {
    _ = DurationSignalTracker.shared.stopTracking(signalName)
}

This uses the same internal stopTracking already available in DurationSignalTracker.

[Jeehut]

@markbattistella Thank you for bringing this up and for the PR, it's very much appreciated!

Firstly, I want to point out that no signals should be sending even when there was a started duration signal and then the settings is changed to no longer send signals via the analyticsDisabled set to true – then calling any signal functions, including internal signal should no longer send signals and the "stopAndSend" also should do nothing.

So the user choice should already be respected!

Having that said, I believe it is fair to say even when users have analytics turned on, there might be some duration-tracked events that the user actually cancels out of and never completes, and I think it makes sense that we do introduce a function to stop the duration signal (to clean it up) without sending the signal.

But for this, I clearly prefer the naming "cancelDurationSignal" because that's exactly what we do. There is also a reason why we named it "stopAndSend" in the existing API: Because we want to make very clear that is a) stops the timer and b) sends the signal in one call. When we now introduce "stop" only, then this might be clear to users who are aware of the existence of "stopAndSend" – but developers new to the SDK wouldn't necessarily know that and when discovering the "stop" first, they might think it stops and sends the signal. We want to avoid any confusion like this, and "cancel" clearly communicates what's going on, we're not "stopping the timer" (and therefore ending the signal and sending it potentially) but we're "cancelling the timer" which I think nobody will assume the signal might get sent.

So if you revise your PR accordingly, I'm happy to merge. Thank you again for bringing this up, it makes total sense!

[markbattistella]

Thanks @Jeehut - and I completely agree. I don't remember why in-between writing this issue and then creating the PR why the name changed (probably copy-paste, and forgot). I've renamed it to cancelDurationSignal so it makes it clearer to the user.