jetpack Social: Poll for share status after reshare

Fixes #

Proposed changes:

Other information:

[ ] Have you written new tests for your changes, if applicable?
[ ] Have you checked the E2E test CI results, and verified that your changes do not break them?
[ ] Have you tested your changes on WordPress.com, if applicable (if so, you'll see a generated comment below with a script to run)?

Jetpack product discussion

Does this pull request change what data or activity we track or use?

Testing instructions:

Go to post editor
Create post and don't share the post to any network either by disabling "Share this post" or disabling all connections.
Keep Network tab open
Now reshare the post
Confirm that the polling for share status starts and finishes when there is new data
Confirm that you can now see "View sharing history" button
Click on it to see the shares
Now reshare again
Confirm that the polling starts and fetches the new posts.
To test the time out, reshare only to Instagram without the post having an image or SIG.
Confirm that the request times out after one minute after resharing only to Instagram without image.

Aug 30 '24 10:08 manzoorwanijk

Are you an Automattician? Please test your changes on all WordPress.com environments to help mitigate accidental explosions.

To test on WoA, go to the Plugins menu on a WordPress.com Simple site. Click on the "Upload" button and follow the upgrade flow to be able to upload, install, and activate the Jetpack Beta plugin. Once the plugin is active, go to Jetpack > Jetpack Beta, select your plugin, and enable the update/social-poll-for-share-status-after-reshare branch.

To test on Simple, run the following command on your sandbox:

bin/jetpack-downloader test jetpack update/social-poll-for-share-status-after-reshare

Interested in more tips and information?

In your local development environment, use the jetpack rsync command to sync your changes to a WoA dev blog.
Read more about our development workflow here: PCYsg-eg0-p2
Figure out when your changes will be shipped to customers here: PCYsg-eg5-p2

Aug 30 '24 10:08 github-actions[bot]

Thank you for your PR!

When contributing to Jetpack, we have a few suggestions that can help us test and review your patch:

:white_check_mark: Include a description of your PR changes.
:white_check_mark: Add a "[Status]" label (In Progress, Needs Team Review, ...).
:white_check_mark: Add testing instructions.
:white_check_mark: Specify whether this PR includes any changes to data or privacy.
:white_check_mark: Add changelog entries to affected projects

This comment will be updated as you work on your PR and make changes. If you think that some of those checks are not needed for your PR, please explain why you think so. Thanks for cooperation :robot:

The e2e test report can be found here. Please note that it can take a few minutes after the e2e tests checks are complete for the report to be available.

Follow this PR Review Process:

Ensure all required checks appearing at the bottom of this PR are passing.
Choose a review path based on your changes:
- A. Team Review: add the "[Status] Needs Team Review" label
  - For most changes, including minor cross-team impacts.
  - Example: Updating a team-specific component or a small change to a shared library.
- B. Crew Review: add the "[Status] Needs Review" label
  - For significant changes to core functionality.
  - Example: Major updates to a shared library or complex features.
- C. Both: Start with Team, then request Crew
  - For complex changes or when you need extra confidence.
  - Example: Refactor affecting multiple systems.
Get at least one approval before merging.

Still unsure? Reach out in #jetpack-developers for guidance!

Aug 30 '24 10:08 github-actions[bot]

When I tested this by sharing to Mastodon, the polling went on even after the share was retrieved. It was polling after timeout 🤔 Any idea why that could be?

Thank you for catching that. It should now be fixed in via eecffc82c2407d57e0cbfc4270857fb2da830cbd

Sep 02 '24 08:09 manzoorwanijk

I didn't the share post during publish. I reshared it, but the polling still continues. The polling should stop when the latest share status is available, right?

Geri also caught that and is now fixed as mentioned above.

Sep 02 '24 09:09 manzoorwanijk

Tests well for the happy cases. I attempted sharing a video, and noticed that we are hammering the endpoint.

Instead of us hitting it every second, shall we poll it every 5 seconds? I suspect this logic will be used in the future on atomic and simple sites as well.

I think we can fix that in a follow up task because that is also the same for post publish panel share status UI.

Sep 02 '24 10:09 manzoorwanijk

Tests well for the happy cases. I attempted sharing a video, and noticed that we are hammering the endpoint.

Instead of us hitting it every second, shall we poll it every 5 seconds? I suspect this logic will be used in the future on atomic and simple sites as well.

IMHO, that is fine. We are not firing any parallel requests, we fire the next one only if the previous one didn't fetch any data we need and also have a timeout of one minute. So, I think it should be fine.

Sep 02 '24 10:09 manzoorwanijk

I agree that we could decrease the polling late from 1sec to 3 or even 5 seconds, it's true that they are not parallel but for wpcom sites with scaling it does make a difference if a lot of sites firing to wpcom every second or every 5 seconds

Sep 02 '24 10:09 gmjuhasz

Even on self-hosted sites, why hammer the endpoint? Publicizing is an async process and most sites have more than 1 connection. We could increase the polling time. Not to mention the moment we bring this to WPCOM/Atomic, we should be wary of the endpoints we hit.

Sep 02 '24 10:09 spsiddarthan

Right now, it doesn't hit every second. It sends another request when the previous one finishes that can be less than or more than a second. We can definitely improve that in another task.

Sep 02 '24 10:09 manzoorwanijk

I tested this another time, I feel we should tread carefully here and phase the polling out into larger intervals.

The same thing already happens in trunk on the post publish panel. Should we fix that first?

Sep 02 '24 11:09 manzoorwanijk

The same thing already happens in trunk on the post publish panel. Should we fix that first?

I thought it was only in this PR. :) I didn't realize it was in trunk already. Do you want to create a task for that, if it's not already there? We should get that fixed as soon as we can.

I need to test the other use cases for this PR, I can have those done in a bit and we can get it merged.

Sep 02 '24 11:09 spsiddarthan

Just found a minor issue or perhaps it's necessary, I will wait for @manzoorwanijk's thoughts.

I couldn't reproduce it on trunk and see it only in this branch.

When you publish a post, but don't share it to any connection, we are calling the share-status endpoint after publish. We need not call it if we are not publicizing, no?

It’s that “View share history” button that fires the request. It happens only if you open Jetpack sidebar before publishing. if you publish directly and disable sharing in the pre-publish panel, it won’t happen.

Sep 04 '24 13:09 manzoorwanijk