Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Post List: Fix excessive media requests #20939

Merged
merged 4 commits into from
Jun 7, 2024

Conversation

zwarm
Copy link
Contributor

@zwarm zwarm commented Jun 4, 2024

Fixes #20905

This PR fixes the excessive calls to fetch media when loading the post list by introducing and managing ongoing fetch requests in PostListFeaturedImageTracker. These changes aim to prevent redundant fetch requests.

Changes include

  • In PostListFeaturedImageTracker Introduced ongoingRequests, to keep track of ongoing image fetch requests and prevent redundant requests.
  • Updated the getFeaturedImageUrl() to check and update the ongoingRequests set appropriately.
  • Updated PostListEventListener.onMediaChanged() to invoke invalidateFeaturedMedia on both success and error. This ensures that the featuredImageMap and ongoingRequests are properly updated whether the media fetch was successful or not.

To Test:

Steps to reproduce the behavior
Preparation:

  1. Create multiple posts (20 or more) and attach a featured image. This can be done quickly by using the WPCOM console and the endpoint rest/v1.1/sites/${siteId}/posts/new.

Existing: Extra requests to the media endpoint for the same featuredImageId

  1. Using "trunk" branch
  2. On the device/emulator, clear storage of the app, or delete and reinstall the app.
  3. Open the app and navigate to the site (the same site that you created the 20+ posts with featured images)
  4. Connect the device/emulator to the Charles proxy (or see below for alternative)
  5. Open the app and go to the Post List screen.
  6. Observe all extra requests to the media endpoint in the Charles proxy.

Fix: Extra requests to the media endpoint are eliminated

  1. Using the app from this PR
  2. On the device/emulator, clear storage of the app, or delete and reinstall the app.
  3. Open the app and navigate to the site (the same site that you created the 20+ posts with featured images)
  4. Connect the device/emulator to the Charles proxy (or see below for alternative)
  5. Open the app and go to the Post list screen.
  6. ✅ Verify all the extra requests for the same media id have been eliminated.
Alternative to using Charles
  • Checkout the branch you will test (trunk for pre-existing test or this branch for the fix test
  • Checkout FluxC (trunk)
  • Use local FluxC to build WP
  • Update GSONRequest.parseNetworkRequest to log info
@Override
    protected Response<T> parseNetworkResponse(NetworkResponse response) {
        logGsonRequest();
        try {
            String json = new String(response.data, HttpHeaderParser.parseCharset(response.headers));
            T res;
            if (mClass == null) {
                res = mGson.fromJson(json, mType);
            } else {
                res = mGson.fromJson(json, mClass);
            }
            return Response.success(res, createCacheEntry(response));
        } catch (UnsupportedEncodingException | JsonSyntaxException e) {
            logRequestPath();
            return Response.error(new ParseError(e));
        }
    }

    private void logGsonRequest() {
        String path = getPath();
        String url = getUrl();

        if (path != null && (path.contains("media"))) {
            if (url != null) {
                Log.i("GsonRequest", "***=> Request URL is: " + url);
            }
        }
    }


Regression Notes

  1. Potential unintended areas of impact
    Multiple media requests continue to be excessive

  2. What I did to test those areas of impact (or what existing automated tests I relied on)
    Manual and unit testing

  3. What automated tests I added (or what prevented me from doing so)
    Existing tests


PR Submission Checklist:

  • I have completed the Regression Notes.
  • I have considered adding accessibility improvements for my changes.
  • I have considered if this change warrants user-facing release notes and have added them to RELEASE-NOTES.txt if necessary.

Testing Checklist (strike-out the not-applying and unnecessary ones): N/A

@zwarm zwarm requested review from fluiddot and AjeshRPai June 4, 2024 23:18
@zwarm zwarm self-assigned this Jun 4, 2024
@dangermattic
Copy link
Collaborator

1 Warning
⚠️ PR is not assigned to a milestone.

Generated by 🚫 Danger

Copy link

sonarcloud bot commented Jun 4, 2024

Quality Gate Passed Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
No data about Coverage
0.0% Duplication on New Code

See analysis details on SonarCloud

@wpmobilebot
Copy link
Contributor

Jetpack📲 You can test the changes from this Pull Request in Jetpack by scanning the QR code below to install the corresponding build.
App NameJetpack Jetpack
FlavorJalapeno
Build TypeDebug
Versionpr20939-0637eec
Commit0637eec
Direct Downloadjetpack-prototype-build-pr20939-0637eec.apk
Note: Google Login is not supported on these builds.

@wpmobilebot
Copy link
Contributor

WordPress📲 You can test the changes from this Pull Request in WordPress by scanning the QR code below to install the corresponding build.
App NameWordPress WordPress
FlavorJalapeno
Build TypeDebug
Versionpr20939-0637eec
Commit0637eec
Direct Downloadwordpress-prototype-build-pr20939-0637eec.apk
Note: Google Login is not supported on these builds.

Copy link

codecov bot commented Jun 4, 2024

Codecov Report

Attention: Patch coverage is 91.66667% with 1 line in your changes missing coverage. Please review.

Project coverage is 40.95%. Comparing base (0e05482) to head (0637eec).
Report is 7 commits behind head on trunk.

Files Patch % Lines
...ordpress/android/ui/posts/PostListEventListener.kt 0.00% 1 Missing ⚠️
Additional details and impacted files
@@            Coverage Diff             @@
##            trunk   #20939      +/-   ##
==========================================
+ Coverage   40.93%   40.95%   +0.01%     
==========================================
  Files        1518     1518              
  Lines       69550    69558       +8     
  Branches    11473    11474       +1     
==========================================
+ Hits        28473    28488      +15     
+ Misses      38491    38486       -5     
+ Partials     2586     2584       -2     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

@zwarm zwarm requested a review from pantstamp June 6, 2024 11:50
Comment on lines +69 to +72
featuredImageIds.forEach {
featuredImageMap.remove(it)
ongoingRequests.remove(it)
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Will this be called when the featured image request is completed? I mention this because I haven't found any other place where the ongoing request is removed.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hey @fluiddot
The places where this funcation gets called is PostListEventListenerfeaturedMediaChanged.
The featuredMediaChanged is called when the media is changed or uploaded. Correct me if I am wrong. @zwarm

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the question, which @AjeshRPai answered before me down below #20939 (comment)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The places where this funcation gets called is PostListEventListener → featuredMediaChanged.
The featuredMediaChanged is called when the media is changed or uploaded. Correct me if I am wrong.

This is correct, previously only success calls were removed from the featureImageMap and in the updated version, both success and errors are removed. We need to make sure we don't have requests hanging around when they shouldn't be.

Copy link
Contributor

@fluiddot fluiddot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I followed the testing instructions and confirmed that only one request is made per featured image. Thanks @zwarm for addressing this issue 🙇 !

I've checked the code and looks good to me, however, I'd defer the approval to an Android developer.

Copy link
Contributor

@AjeshRPai AjeshRPai left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@zwarm

The changes looks good to me. Feel free to merge 👍🏼

Comment on lines +69 to +72
featuredImageIds.forEach {
featuredImageMap.remove(it)
ongoingRequests.remove(it)
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hey @fluiddot
The places where this funcation gets called is PostListEventListenerfeaturedMediaChanged.
The featuredMediaChanged is called when the media is changed or uploaded. Correct me if I am wrong. @zwarm

@zwarm zwarm merged commit e56dcc8 into trunk Jun 7, 2024
21 of 23 checks passed
@zwarm zwarm deleted the issue/20905-fix-excessive-media-requests branch June 7, 2024 15:03
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Excessive Media Requests Delay Critical Post Operations
5 participants