Skip to content

feat: update portal-spec-tests and refactor reading from test files#1797

Merged
morph-dev merged 1 commit into
ethereum:masterfrom
morph-dev:header_test_vectors
May 1, 2025
Merged

feat: update portal-spec-tests and refactor reading from test files#1797
morph-dev merged 1 commit into
ethereum:masterfrom
morph-dev:header_test_vectors

Conversation

@morph-dev
Copy link
Copy Markdown
Collaborator

What was wrong?

We were missing test vectors around fork boundaries. These were added to portal-spec-tests in ethereum/portal-spec-tests#49

How was it fixed?

Updated portal-spec-tests submodule, and simplified/refactored some tests in ehtportal-api crate.

To-Do

@morph-dev morph-dev requested a review from KolbyML May 1, 2025 17:15
@morph-dev morph-dev self-assigned this May 1, 2025
Copy link
Copy Markdown
Member

@KolbyML KolbyML left a comment

Choose a reason for hiding this comment

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

Most of the PR looks good, I just have questions on the types we already have defined

Comment on lines +8 to +20
/// A common type used in test files.
#[derive(Debug, Clone, Serialize, Deserialize)]
pub struct ContentItem<K: OverlayContentKey> {
pub content_key: K,
#[serde(rename = "content_value")]
pub raw_content_value: RawContentValue,
}

impl<K: OverlayContentKey> ContentItem<K> {
pub fn content_value<V: ContentValue<TContentKey = K>>(&self) -> Result<V, ContentValueError> {
V::decode(&self.content_key, &self.raw_content_value)
}
}
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Isn't this type already defined in crates/utils/src/testing.rs, shouldn't we only define it once?

Comment on lines +24 to +51

/// Reads json file from a "portal-spec-tests" submodule
pub fn read_json_portal_spec_tests_file<T>(path: impl AsRef<Path>) -> anyhow::Result<T>
where
T: DeserializeOwned,
{
let reader = BufReader::new(File::open(portal_spec_tests_path(path))?);
Ok(serde_json::from_reader(reader)?)
}

/// Reads yaml file from a "portal-spec-tests" submodule
pub fn read_yaml_portal_spec_tests_file<T>(path: impl AsRef<Path>) -> anyhow::Result<T>
where
T: DeserializeOwned,
{
let reader = BufReader::new(File::open(portal_spec_tests_path(path))?);
Ok(serde_yaml::from_reader(reader)?)
}

/// Reads ssz file from a "portal-spec-tests" submodule
pub fn read_ssz_portal_spec_tests_file<T: Decode>(path: impl AsRef<Path>) -> anyhow::Result<T> {
let bytes = read_binary_portal_spec_tests_file(&path)?;
T::from_ssz_bytes(&bytes).map_err(|err| {
anyhow!(
"Error decoding ssz file: {}. Error: {err:?}",
path.as_ref().display()
)
})
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Isn't this code already defined in crates/utils/src/submodules.rs shouldn't we only define it once?

Copy link
Copy Markdown
Member

@KolbyML KolbyML left a comment

Choose a reason for hiding this comment

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

:shipit: looks good. Milos messaged me on discord for context

@morph-dev
Copy link
Copy Markdown
Collaborator Author

:shipit: looks good. Milos messaged me on discord for context

For context for others, these files and logic is duplicated because we don't want to put it in ethportal-api because we publish this crate. And ethportal-api can't depend on crates/utils because of circular dependency. So the setup is:

  • we have module in ethportal-api that is protected by #[cfg(test)] that is used only within that crate
  • we have crates/utils for all other crates

@morph-dev morph-dev merged commit b80d992 into ethereum:master May 1, 2025
14 checks passed
@morph-dev morph-dev deleted the header_test_vectors branch May 1, 2025 18:10
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.

2 participants