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

Support blob and batch fetch APIs #966

Merged
merged 14 commits into from
Dec 10, 2024

Conversation

jianoaix
Copy link
Contributor

@jianoaix jianoaix commented Dec 6, 2024

Why are these changes needed?

Implementing dataapi v2 (#955)

Checks

  • I've made sure the tests are passing. Note that there might be a few flaky tests, in that case, please comment that they are not relevant.
  • I've checked the new test coverage and the coverage percentage didn't drop.
  • Testing Strategy
    • Unit tests
    • Integration tests
    • This PR is not tested :(

@jianoaix jianoaix requested review from pschork and ian-shim December 6, 2024 18:45
"type": "integer"
},
"cumulative_payment": {
"description": "TODO: we are thinking the contract can use uint128 for cumulative payment,\nbut the definition on v2 uses uint64. Double check with team.",
Copy link
Contributor

Choose a reason for hiding this comment

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

Do we really want this in the swagger doc?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

It's the cost of reusing data types in "core", we otherwise have to duplicate it in "dataapi". I may do a manual fix on it to handle this as an exception.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I'm going to leave it for now until all APIs are implemented, otherwise each time we generate docs it will involve this manual edit.

@@ -136,7 +182,7 @@
"200": {
"description": "OK",
"schema": {
"$ref": "#/definitions/dataapi.BlobMetadataResponse"
"$ref": "#/definitions/dataapi.BlobResponse"
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 v2 path is overwriting the v1, which is not desired.

The path naming may happen to need some improvements, i.e.

  • /feed/blobs -> /blob/feed, and /feed/blobs/<blob_key> -> /blob/<blob_key>`
  • /feed/batches -> /batch/feed, and /feed/batch/<batch_header_hash> -> /batch/<batch_header_hash>

This seems to be a more natural ordering. WDYT?

Copy link
Contributor

Choose a reason for hiding this comment

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

Hmm, is the base url not taken into account here?
Anyway, that makes sense to me

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yea maybe adding "v1" / "v2" to the path will avoid this. But it seems more logical to have "/blob/..." or "/batch/..." than organizing around "/feed/...".

"type": "integer"
},
"cumulative_payment": {
"description": "TODO: we are thinking the contract can use uint128 for cumulative payment,\nbut the definition on v2 uses uint64. Double check with team.",
Copy link
Contributor Author

Choose a reason for hiding this comment

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

It's the cost of reusing data types in "core", we otherwise have to duplicate it in "dataapi". I may do a manual fix on it to handle this as an exception.

Copy link
Contributor

@ian-shim ian-shim left a comment

Choose a reason for hiding this comment

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

lgtm

@@ -136,7 +182,7 @@
"200": {
"description": "OK",
"schema": {
"$ref": "#/definitions/dataapi.BlobMetadataResponse"
"$ref": "#/definitions/dataapi.BlobResponse"
Copy link
Contributor

Choose a reason for hiding this comment

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

Hmm, is the base url not taken into account here?
Anyway, that makes sense to me

@jianoaix jianoaix merged commit ccc1e9a into Layr-Labs:master Dec 10, 2024
6 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants