Limit daily syncs to 2 per user

I wonder how many users you have that sync more than 2 activities per day. If you’re continuously running into API limits, and cannot batch calls, then you should limit to 2 activities per day. Some runners may be doing things like interval workouts (warmup, laps, cooldown, etc.) a bunch of spamming strava like that.

I’m not suggesting discarding activities, but queuing them for the next day.

e.g. for Quarantine Ultra some folks were doing 1 activity per hour for like 20 hours.

Probably NOT a huge factor, granted, but worth investigating.

I can see this may help the current Strava issues, however how would we cope with the users that upload more than on activity everyday, I’m not sure how many there are, I occasionally upload 2, 3 or 4 activities (To club, warm up, main run, home again/ or Warm up, couple of short races, cooldown) and I run every day, however I probably do enough 1 activity days to even that out.

Maybe ti should be a premium member thing to have more sync each day, or this links nicely with your other idea to only sync activities that are tagged correctly (if you turn the feature on) that way if you hit the two activity a day limit, it forces you to start tagging activities to prioritize the upload.

1 Like

Unfortunately, Strava sends a web hook for each activity. So even if CS only imports two, it will still use up as many API calls as gets recorded by Strava plus the two that will be imported.

Toss onto the problem the fact that apparently Strava has developed a stutter, and sends occasional duplicate web hooks.

So if a user were to do three runs in a day,

Strava would send three web hooks (which each uses an API call)

Then James would use three more API calls to get the information into CS?

I ad read somewhere else that every activity used two API calls but wasn’t sure how, thanks for the explanation!

Essentially half of the 30,000 API allowance are used up by Strava telling CS that users have activities and the other half by CS downloading them?

I’m hopeful the Garmin interface will minimize the Strava bottleneck.

But I do wonder if there is a way to keep non-node collecting activities hidden from CS?

That being said, I do use my Garmin to record my bike rides too.

I’d like to “hide” those, and non-node collecting runs, from CS, so they don’t use any API calls.

Maybe with the Garmin interface, the calls won’t be an issue?

I think, if something like this happened, 2 is a good number.

But what happens if one node collecting run is in the morning, then you do other activities, and then do another node run in the evening? Would it be missed? Or maybe a manual sync, on a rest day?

It’s not a bad idea, I just wonder if it’s feasible.

Yeah, the idea would that on day 1, your “to club” and “warmup” runs would sync. The others would be pushed back. On day 2, your “main run” and “cooldown” runs would sync. any additional runs would be pushed back. On day 3, “home again” syncs, and you run again (“Morning jog”), which also syncs. Now you are all caught up.

So it just evens out the API calls a bit. Also, the main line of reasoning is that lots of little activities, as in your example, are often workouts, races, etc. Not heatmapping. Hence why they could usually be pushed back without annoying delays to progress or lifemap.

But yes @fredrik.coulter’s web hook info suggests it won’t save much. And so code complexity wouldn’t be worth the benefit, I’m sure.

I was just getting ready to head out on an epic node run, and had this thought:

Why not make Strava 100% manual?

Then we tell CityStrides which Strava activity we want processed, and CityStrides doesn’t (need to) get bombarded with calls (I think the term is web hook).

Of course informing all the Strava users on the new procedure would be a pain, but it might also mean accounts that recently went “dark”, would be instantly ignored. I suspect there are accounts still linked, where people have lost interest.

OK, time to fly. Cheers

1 Like

I understand the principle, and I agree the little activities could be pushed back, but at the expense of a delay to the heatmapping, on day 2 or 3 that is pushed back by the 5 on day 1, 2 on day 2 and 1 every other day for example,

Unless you try to prioritize a long run or the first run each day, I cant see how it wont add delays to stuff you do the day after club night or race day, until you catch up which may take days and days.

@ericjrw
I don’t think Strava allow it, James has mentioned elsewhere on the site that (Cant find it at the moment) that you have to do things their way for them to help you, and he needs all the help he can to get an api rate increase, therefore needs to do things by the book. I’ll try and reference this comment with some fact, but not sure what thread it was written on :thinking:

1 Like

@howling0_strava Thank you that info. There is a lot of historical info that is going to take me a while to catch up on, and remember. :slight_smile:

And here I thought I had the solution. Oh well. I did get 34 streets yesterday. Need to see if I can see one’s stats like, i.e. best days, most nodes per mile/K, streets per mile/K, and perhaps worse days too. Most miles/Ks and least nodes/streets.

Cheers, Eric