karthikb351 / distrava Goto Github PK

Strava retries webhooks that aren't acknowledged within 2 seconds. Our cold start might take longer, so we should actually reject the webhook if we're receiving it 2 seconds after it was started.

If the Strava webhook request has a timestamp header, we can check if we're within the 2 seconds window, else reject it and strava retry us (and hopefully hit a warm function).

Not sure if there’s an API to download the pictures but will be nice to have a preview posted along with the post

The full polyline for the Strava activity is a really large value in a long activity, which ends up breaking the static maps URL (as the length is too long). We should instead use the summary_polyline value of the activity.

To be added

Check the Finagle-Ctx-com.twitter.finagle.Retries header to see if it's the last retry. In which case we should ignore the deadline since we won't be called again and we should process the request.

The Strava API provides richer information about an activity, some of the information that might be worth adding to the bot's response are:

• Elapsed Time
• Distance
• Total Elevation Gain
• Embeddable Map of the activity

There are many more pieces of information, that are perhaps overkill. But worth considering expanding beyond title, and description, especially since most people use auto-generated titles and no description, so it's harder to distinguish anyway.

Instead of depending on Model.findOne() to error out when not found, use the errorOnEntityNotFound configuration from gstore (detailed here). This will simplify the logic, and allow actual database errors to be handled explicitly.

TBA: list of logic/components to test

GCP's secret manager is easier to store and retrieve config values, we should use https://github.com/google-github-actions/get-secretmanager-secrets to fetch secrets in our actions.

We also need to have a workflow to pull this value in our dev environment (codespaces or otherwise).

We need to acknowledge Strava webhook events within 2 seconds, so we should acknowledge early and push the event on Pub/Sub and handle them asynchronously.

We have a repeated pattern of checking if the access token has expired before every method, this can be potentially be abstracted into a decorator on the method itself.

Currently using console.log for logging results in GCP's logging view showing them in separate lines.

Example:

We should use a standard logging tool that Google's cloud functions supports well.