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
twitter: fully support oversized block lists #764
Comments
my stopgap solution to this is to gracefully handle when we get rate limited and use the partial block list contents that we've fetched so far (06f5987). the cap i ended up with is actually 40k, not 75k, since i memcache block lists, and memcache values are limited to 1MB. |
oof, hit a blocklist last night (vhfmag's) where 40k was still over 1MB. error here; log:
the memcache docs are light on size calculation details, but they do say Any type. If complex, will be pickled. i guess i could pickle the list, measure, and incrementally cut it down until it's under 1MB, but for now i'm just going to drop the cutoff down to 35k. |
Obsolete, Bridgy Twitter is dead. #1410 (comment) |
we recently started fetching and obeying twitter block lists in #473. more implementation details in snarfed/granary#40. we use twitter's
blocks/ids
endpoint (withcount=5000
), which is rate limited to 15 calls per 15m per user. this means that we can only fetch 75k members of a user's block list at one time.there are currently three bridgy twitter users with >75k users on their block lists. one has 149996 total (!); i haven't counted the others. they now hit the rate limit and fail pretty much every poll. we cache block lists, but we don't split and coalesce block list fetches across polls.
those three users' last webmentions from bridgy were 2 mos ago, 3 mos ago, and never, and the solutions to this are awkward at best, so i'm not prioritizing this right now.
The text was updated successfully, but these errors were encountered: