PlatformsFacebookBackground

CommentsListComponentsPaginationQuery

Domainbackground
Kindquery
doc_id29265821953021786
Path/api/graphql/
SendscommentsAfterCount, commentsAfterCursor, commentsBeforeCount, commentsBeforeCursor, commentsIntentToken, feedLocation, focusCommentID, id, scale, targetDialect, useDefaultActor, __relay_internal__pv__CometUFICommentAutoTranslationTyperelayprovider, __relay_internal__pv__CometUFICommentAvatarStickerAnimatedImagerelayprovider, __relay_internal__pv__CometUFICommentActionLinksRewriteEnabledrelayprovider, __relay_internal__pv__IsWorkUserrelayprovider
Readsnode....useCometUFITopLevelCommentListComponents_paginationFeedback
Called fromuseCometUFITopLevelCommentListComponents_paginationFeedback.graphql
reaev_a2877f95582af5773dfc0f8ab6c1b53eb0081d00bb5a7ead9456cca6c5942d9f

Seen 1 time(s) in 1 run(s).

ActionOur stepTimesStatusTookAfter step startErrors
inspectstep 8: scrollIn dialog "…" 4 x 800px1200688 ms1367 ms—

What it does

Loads the next page of a post's top-level comments (useCometUFITopLevelCommentListComponents_paginationFeedback): the post's feedback id, the same commentsIntentToken as the list, and commentsAfterCursor, the end_cursor of the page before. It fired once, as the post dialog was scrolled after the sort was set to Newest (run 20261020T151100, step 8), and answered the 5 remaining comments with has_next_page: false.

What our machine does with it

The group read (src/facebook/group/read, commentsFromResponse) reads its comments the same way as CommentListComponentsRootQuery's and scrolls the dialog again while has_next_page is true: the list is read through when it is false. On the run, the two pages gave 15 distinct comments of the 16 Facebook counts (the one left is filtered as potential spam, which only "All comments" shows).

What can go wrong

None seen: it answered 200 in 688 ms. If it failed or never fired (the dialog not scrolled to its end), the read has only the pages before it, and the post's comments stay unread past that cursor until the next pass.