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

Add support for POST /eth/v2/beacon/blocks #5214

Merged
merged 4 commits into from
Aug 12, 2023

Conversation

henridf
Copy link
Contributor

@henridf henridf commented Jul 25, 2023

No description provided.

@github-actions
Copy link

github-actions bot commented Jul 26, 2023

Unit Test Results

         6 files   -        3       715 suites   - 362   26m 22s ⏱️ - 13m 6s
  3 723 tests ±       0    3 444 ✔️ ±       0  279 💤 ±  0  0 ±0 
10 568 runs   - 5 306  10 284 ✔️  - 5 285  284 💤  - 21  0 ±0 

Results for commit 3af40e6. ± Comparison against base commit 6a2bac5.

♻️ This comment has been updated with latest results.

debug "Failed to deserialize REST JSON data",
err = exc.formatMsg("<data>"),
data = string.fromBytes(body.data)
return err("Unable to deserialize data")
Copy link
Contributor

Choose a reason for hiding this comment

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

This message is going to be passed to client as stacktrace message with InvalidBlockObjectError error message. So maybe stacktrace message could be more informative? Because currently its just provide logically same message as InvalidBlockObjectError.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Hmm. I replaced this line with

          return err("Unable to deserialize JSON for fork " & version & ": " & exc.msg)

but am getting a compilation error cannot evaluate at compile time: version. Tried various things (including the workaround at https://nim-lang.org/docs/strformat.html#limitations) to no avail.

I must be missing something obvious but... 🤔 any suggestions welcome.

Copy link
Contributor

Choose a reason for hiding this comment

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

You just need to change return value of your function which is currently returns Result[T, cstring] but could return Result[T, string].

Copy link
Contributor Author

Choose a reason for hiding this comment

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

data = string.fromBytes(body.data)
return err("Unable to deserialize data")
except CatchableError:
return err("Unexpected deserialization error")
Copy link
Contributor

Choose a reason for hiding this comment

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

ditto

Copy link
Contributor Author

Choose a reason for hiding this comment

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

t: typedesc[RestPublishedSignedBlockContents],
body: ContentBody,
version: string
): Result[RestPublishedSignedBlockContents, cstring] =
Copy link
Contributor

Choose a reason for hiding this comment

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

I think this function could return ForkedSignedBlock?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

For Deneb we get (and need to return) both the block and blobs:

of ConsensusFork.Deneb: denebData*: DenebSignedBlockContents

Copy link
Contributor

Choose a reason for hiding this comment

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

So maybe you could introduce new type to spec/forks.nim and add some helpers in there?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

If I'm understanding correctly you're suggesting to move

func init*(T: type ForkedSignedBeaconBlock,
to spec/forks.nim?
As RestPublishedSignedBlockContents is only used locally in the REST processing layer, I figured it belonged in rest_types.nim, but happy to move over if you feel otherwise.

@henridf henridf force-pushed the publishblockv2 branch 3 times, most recently from 3864fc1 to 7796df4 Compare July 29, 2023 00:42
@henridf henridf force-pushed the publishblockv2 branch 2 times, most recently from 23c1d0a to 031de3f Compare August 7, 2023 16:19
@henridf
Copy link
Contributor Author

henridf commented Aug 8, 2023

@cheatfate thanks for the comments - i think i addressed them all, lmk if anything remaining

@tersec
Copy link
Contributor

tersec commented Aug 11, 2023

linux-amd64 is failing due to

 /home/runner/work/nimbus-eth2/nimbus-eth2/vendor/nim-sqlite3-abi/sqlite3_abi/sqlite3.c:104975: undefined reference to `__ubsan_handle_type_mismatch_v1'
/usr/bin/ld: /home/runner/work/nimbus-eth2/nimbus-eth2/vendor/nim-sqlite3-abi/sqlite3_abi/sqlite3.c:104974: undefined reference to `__ubsan_handle_type_mismatch_v1'
/usr/bin/ld: /home/runner/work/nimbus-eth2/nimbus-eth2/vendor/nim-sqlite3-abi/sqlite3_abi/sqlite3.c:104974: undefined reference to `__ubsan_handle_add_overflow'
/usr/bin/ld: /home/runner/work/nimbus-eth2/nimbus-eth2/vendor/nim-sqlite3-abi/sqlite3_abi/sqlite3.c:104974: undefined reference to `__ubsan_handle_pointer_overflow'
/usr/bin/ld: /home/runner/work/nimbus-eth2/nimbus-eth2/vendor/nim-sqlite3-abi/sqlite3_abi/sqlite3.c:104974: undefined reference to `__ubsan_handle_type_mismatch_v1'
/usr/bin/ld: /home/runner/work/nimbus-eth2/nimbus-eth2/vendor/nim-sqlite3-abi/sqlite3_abi/sqlite3.c:104974: undefined reference to `__ubsan_handle_pointer_overflow'
/usr/bin/ld: /home/runner/work/nimbus-eth2/nimbus-eth2/vendor/nim-sqlite3-abi/sqlite3_abi/sqlite3.c:104974: undefined reference to `__ubsan_handle_type_mismatch_v1'
/usr/bin/ld: build/libnimbus_lc.a(@m..@s..@svendor@snim-sqlite3-abi@ssqlite3_abi@ssqlite3.c.o): in function `sqlite3ResolveSelfReference':
/home/runner/work/nimbus-eth2/nimbus-eth2/vendor/nim-sqlite3-abi/sqlite3_abi/sqlite3.c:105108: undefined reference to `__ubsan_handle_t

which isn't per-se related to this PR, but was fixed by #5258; updating this branch to latest unstable should fix this.

@henridf
Copy link
Contributor Author

henridf commented Aug 12, 2023

updating this branch to latest unstable should fix this.

done

@tersec tersec enabled auto-merge (squash) August 12, 2023 02:13
@tersec tersec merged commit 9efd26c into status-im:unstable Aug 12, 2023
8 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