-
Notifications
You must be signed in to change notification settings - Fork 5
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
feat: set max number of car cids to resolve #24
Conversation
30f3426
to
9970a01
Compare
9970a01
to
1203d40
Compare
src/middleware.js
Outdated
// the sub-requests limit and not serve content anyway | ||
if (carCids.length > Number(env.MAX_CAR_CIDS_TO_RESOLVE)) { | ||
throw new HttpError('number CAR CIDs is too large to resolve', { status: 501 }) | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Move into the while loop above for quicker response?
wrangler.toml
Outdated
@@ -27,6 +27,9 @@ r2_buckets = [ | |||
[env.production.build] | |||
command = "npm run build" | |||
|
|||
[env.production.vars] | |||
MAX_CAR_CIDS_TO_RESOLVE = "250" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's tricky because a DAG might be split across 999 CARs but because of the path you might be able to extract /smol.json
with the last sub-request.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
With our 10MB CAR shards it'll restrict freeway from serving anything that's over 2.5GB
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I understand the disadvantage for these use cases. However, at this point looks like the priority should be to reduce R2 ops and avoid potential error states mentioned in issue (break in mid stream without feedback for user, break after worker run out of sub-requests in general). When we have bigger sub-requests limit and better R2 perf we can increase these.
We can tweak more the number if you feel like there is a better compromise. Thoughts?
Co-authored-by: Alan Shaw <[email protected]>
2225c2b
to
9d4c9ff
Compare
🤖 I have created a release *beep* *boop* --- ## [1.6.0](v1.5.3...v1.6.0) (2023-03-02) ### Features * set max number of car cids to resolve ([#24](#24)) ([94e65ea](94e65ea)) --- This PR was generated with [Release Please](https://github.com/googleapis/release-please). See [documentation](https://github.com/googleapis/release-please#release-please). Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
Sets max number of car CIDs to resolve based on issue and numbers suggested in #22
Later on, once bigger chunks changes is largely propagated, we can consider increasing this. Also, going to create an issue to add logging to
freeway
so that we can log number of car CIDs when we throw this error back so that we can have better visibility on these numbers