You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
GetPostsStateless is not working properly when iterated. For example, look at the following nginx requests below. Notice the size of the payloads all are within a somewhat normal range, until the last request. Notice the size of the payload returned on the last request (10312051). That last request is the equivalent of about 1900 posts.
Basically, every time I page to the 5th or 6 "page" of results, it refuses to respect the NumToFetch param and simply returns thousands of posts 🤷🏾♂️!
I verified the issue is specifically related to the value passed into PostHashHex. If I start a call with a PostHashHex say 300 items deep in the global, the error will happen on the 1st call.
Also, you can see the same issue from a different angle. The screenshot below is the browser console. Notice again the size of the last response payload @ 10.3mb!
The object below is the request payload for every call. Again, depending on the PostHashHex passed in, it does not respect the NumToFetch value.
{PostHashHex: "8425dd56335283ec0a8ff17a7d5b77aee423d19e703881910327075975ed3f47",…}
AddGlobalFeedBool: true
FetchSubcomments: false
GetPostsByDESO: false
GetPostsForFollowFeed: false
GetPostsForGlobalWhitelist: true
MediaRequired: false
NumToFetch: 25
OrderBy: ""
PostContent: ""
PostHashHex: "**8425dd56335283ec0a8ff17a7d5b77aee423d19e703881910327075975ed3f47**"
PostsByDESOMinutesLookback: 0
ReaderPublicKeyBase58Check: "BC1YLgQMDskGR7m7V3uRqh62wFCZsPgVWH5BFHijArSRLJyPCVo9AuR"
StartTstampSecs: null```
Any ideas what's causing this? This seems pretty important, as we need this working to enable a better scrolling experience for users.
The text was updated successfully, but these errors were encountered:
GetPostsStateless is not working properly when iterated. For example, look at the following nginx requests below. Notice the size of the payloads all are within a somewhat normal range, until the last request. Notice the size of the payload returned on the last request (10312051). That last request is the equivalent of about 1900 posts.
Basically, every time I page to the 5th or 6 "page" of results, it refuses to respect the NumToFetch param and simply returns thousands of posts 🤷🏾♂️!
I verified the issue is specifically related to the value passed into PostHashHex. If I start a call with a PostHashHex say 300 items deep in the global, the error will happen on the 1st call.
`nginx | 172.31.14.51 - - [23/May/2022:12:44:10 +0000] "POST /api/v0/get-posts-stateless HTTP/1.1" 200 118044 "-" "Mozilla/5.0
nginx | 172.31.14.51 - - [23/May/2022:12:44:10 +0000] "POST /api/v0/get-posts-stateless HTTP/1.1" 200 145907 "-" "Mozilla/5.0
nginx | 172.31.14.51 - - [23/May/2022:12:44:15 +0000] "POST /api/v0/get-posts-stateless HTTP/1.1" 200 135363 "-" "Mozilla/5.0
nginx | 172.31.14.51 - - [23/May/2022:12:44:20 +0000] "POST /api/v0/get-posts-stateless HTTP/1.1" 200 144301 "-" "Mozilla/5.0
nginx | 172.31.14.51 - - [23/May/2022:12:44:28 +0000] "POST /api/v0/get-posts-stateless HTTP/1.1" 200 150703 "-" "Mozilla/5.0
nginx | 172.31.14.51 - - [23/May/2022:12:44:31 +0000] "POST /api/v0/get-posts-stateless HTTP/1.1" 200 119172 "-" "Mozilla/5.0
nginx | 172.31.14.51 - - [23/May/2022:12:44:34 +0000] "POST /api/v0/get-posts-stateless HTTP/1.1" 200 107212 "-" "Mozilla/5.0
nginx | 172.31.14.51 - - [23/May/2022:12:44:39 +0000] "POST /api/v0/get-posts-stateless HTTP/1.1" 200 4460 "-" "Mozilla/5.0
nginx | 172.31.14.51 - - [23/May/2022:12:44:45 +0000] "POST /api/v0/get-posts-stateless HTTP/1.1" 200 10312051 "-" "Mozilla/5.0
Also, you can see the same issue from a different angle. The screenshot below is the browser console. Notice again the size of the last response payload @ 10.3mb!
The object below is the request payload for every call. Again, depending on the PostHashHex passed in, it does not respect the NumToFetch value.
The text was updated successfully, but these errors were encountered: