The best place for this sort of check looks like it would be
sendingEnabled... but it looks like if we put it there, then we will never retry sending that ping and simply archive it for all time.
Next most likely looks like the property
canSendNow... however, it appears to be most interested in describing whether Firefox is physically able to send now and will happily ask pingsender to try... which I gather isn't the desired outcome.
Next from there is to interject ourselves in
submitPing. As new pings come by and try to be sent we can decide to save them as pending pings (so they'll be retried later) and then bail out in much the way that
canSendNow presently works. We'll just have to do that earlier than the pingsender check (but below the sendingEnabled check. If we're both offline and the user's disabled the Telemetry pref, we still want to drop the ping on the floor after all.). It's not a quick stop, though, as any pending or current pings in the scheduler will remain there, and if the scheduler ticks (like after a timer due to throttling, or near local midnight) they'll try to be sent again. But persisting the current pings down to pending pings or pausing the tick would just be a pain. If we're that worried, a second check in
_doSendTask or nearby will handle it... but that level of complexity is asking for bugs.
Yes, that seems most appropriate. Somewhere around here we could have an early return and a nice comment. And a nice test or four in
toolkit/components/telemetry/tests/unit possibly in